Subject: Re: [linux-audio-dev] soundfonts and csound
From: Josh Green (jgreen_AT_users.sourceforge.net)
Date: Thu Sep 21 2000 - 09:02:59 EEST
Scott McNab wrote:
<cut>
>
> I played about a bit with ALSA patch loading when writing the Trident synth
> driver and the mikmod alsa-seq driver. There is basic support for instrument
> loading, but it is still very incomplete and is not at all well documented.
>
> Currently there is very primitive support for loading simple wave instruments
> on Trident and GUS cards (suitable for playing .mod files), Interwave patches
> on GUS cards, and OPL3 FM instruments for cards with an FM chip. Obviously,
> the EMU8k and EMU10k drivers support soundfonts, but only through OSS emulation.
>
> Instrument patch loading works by first checking the capabilities of the synth
> device to see if it supports instrument loading, and then sending an appropriate SND_SEQ_EVENT_INSTR_PUT event to bind instrument data to a specified bank/program
> number. It is then up to the receiver of this event (soundcard driver/user-space
> soft synth) to then react and parse this event appropriately.
>
> Patches can be loaded so they are persistent and accessible across clients (so
> you can load a piano sound as program 0 and play it from a second application)
> or they can be private to that particular application (so loading a machine-gun
> sound effect as program 0 will not affect another application playing a piano
> tune!).
>
> There are numerous other events defined in asequencer.h which presumably would
> support complete instrument loading, querying and patch editing, but afaik most
> of this is still undefined and unimplemented. I think this general type of
> API is quite usable though and I'd like to see it get properly defined so people
> can start using it.
>
> > ALSA ALSA ALSA.. I think that is the way to go. We could do some sort of
> > cross between these options. Like perhaps developing ALSA sequencer support
> > for csound and then some hack to on demand load the patches until an ALSA
> > solution comes around. Anyone else have any thoughts on this?? I suppose I
> > could post my "what is the status of patch loading in ALSA?" question again
> > on alsa-devel. But I didn't get a response the first time, and I hate to nag
> > programmers who are hard at work doing the basics.
>
> Its been a few months now since the topic was last discussed so it might not
> hurt to try raising it again. Takashi seems to be the one now in charge of
> sequencer stuff although I think most of the existing instrument loading support
> was Jarsoslav's work.
>
> Even if the API is not implemented at the driver level yet, having the events
> defined properly would at least let people play with it in userspace (eg. with
> smurf and timidity). Support in the kernel drivers could be added later with the
> instrument loading/editing tools already existing.
>
> Scott
Thanks for the information. I took a brief look at some of the patch related stuff. Looks like ALSA is currently missing a generic sound font patch loading
interface. I posted a message to alsa-devel concerning this. It seems like that would be the best way to go. The current OSS AWE compatible patch loading uses AWE
specific parameters which restricts the values below sound font specification and also doesn't really make sense for other wavetable devices (software etc). Not that
it should be changed, as it does perform a valid purpose. Generic sound font patch loading, using sound font units, would be the most generic and could be used for
all sorts of wavetable devices. If I do attempt something of this sort I'll look to the Trident driver for help.. Thanks again..
Josh
This archive was generated by hypermail 2b28 : Thu Sep 21 2000 - 09:57:41 EEST