Re: opening alsa pcm device for input/output on specific channels

[Paul Davis <pbd@op.net>]

>> personally, i don't like either of them very much, which is partly why
>> i wrote JACK.
>
>ok. you are now using: ALSA kernel -> ALSA lib -> JACK.

thats the current config, except that we now have

      solaris audio -> JACK

as well. and we use very, very little of alsa-lib with JACK unless the
user asks to by using a non-"hw" PCM device name.

>that's not too different from: kernel driver -> EASI or ASIO plugin -> JACK
>i think the difference between ALSA and EASI/ASIO is that the latter have
>device dependant code in both user space and kernel. i think this is a
>cleaner solution. 

there has been talk here about device dependent code going into
alsa-lib. also with ALSA and applications like JACK that use features
not yet abstracted into the ALSA API (e.g. hardware monitoring), we
have device dependent code in user space too.

>	   i have not yet looked into ASIO much, but perhaps porting it would
>make sense also. both EASI and ASIO plugins could use the same low level
>kernel driver. is there a reason why this has not been done. licensing
>perhaps?

when abramo and i have talked about this (just a little bit), we felt
quite sure you could implement ASIO (and thus *probably* EASI) on top
of alsa-lib.

>do you agree that having a device specific user space plugin has advantages
>over a generic kernel driver interface?

actually, no i don't. i prefer to see features that are truly
"cross-interface" be abstracted into the API, and those cards that
support them provide them via the generic kernel driver
interface. however, in the end it doesn't make a lot of difference as
long as the application has no clue what's going on. 

i've thrown down the gauntlet with JACK's design by saying that i
think that the vast, overwhelming majority of audio apps should have
no clue whether they are even running with access to an actual h/w
audio interface. providing device specific features doesn't seem very
important to me. this is stuff that is handled by the control API and
alsactl/amixer right now. it would be better if we had a graphical
application to supplement them, but thats the only place i care about
device specific stuff as a rule.

--p


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm