opening alsa pcm device for input/output on specific channels

opening alsa pcm device for input/output on specific channels

[Martijn Sipkema]

I again sent an email to alsa-devel using the wrong account. I think
it is all outlook's fault...

--martijn

----- Original Message ----- 
From: "Martijn Sipkema" <m.j.w.sipkema@student.tudelft.nl>
To: <alsa-devel@alsa-project.org>
Sent: Wednesday, June 05, 2002 7:50 PM
Subject: opening alsa pcm device for input/output on specific channels


> is it possible to open a alsa pcm device for input or output on
> not only a certain number of channels but using a channel mask?
> e.g. output on channels 1, 2, 5 & 6? i don't seem to find this
> in the docs.
> 
> thanks,
> 
> --martijn
> 
> 
> 


_______________________________________________________________

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

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

[Paul Davis]

you do it using ~/.asoundrc to define a PCM device that has the
channel characteristics you want.

next, you'll be asking how. that's the part i can't help you with. the
archives have some examples, and there are several people on the list who
can tell you.

>I again sent an email to alsa-devel using the wrong account. I think
>it is all outlook's fault...

nearly everything is outlook's fault ... :)

--p

>--martijn
>
>----- Original Message ----- 
>From: "Martijn Sipkema" <m.j.w.sipkema@student.tudelft.nl>
>To: <alsa-devel@alsa-project.org>
>Sent: Wednesday, June 05, 2002 7:50 PM
>Subject: opening alsa pcm device for input/output on specific channels
>
>
>> is it possible to open a alsa pcm device for input or output on
>> not only a certain number of channels but using a channel mask?
>> e.g. output on channels 1, 2, 5 & 6? i don't seem to find this
>> in the docs.
>> 
>> thanks,
>> 
>> --martijn
>> 
>> 
>> 
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel
>

_______________________________________________________________

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

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

[Martijn Sipkema]

> you do it using ~/.asoundrc to define a PCM device that has the
> channel characteristics you want.
>
> next, you'll be asking how. that's the part i can't help you with. the
> archives have some examples, and there are several people on the list who
> can tell you.

aha, so the idea is that an application can only open a device with a number
of channels and the user uses the configuration file to map channels? there
is no way for an aaplication to open a device for output on specific
channels
, perhaps using a channel mask as in EASI?

--martijn




_______________________________________________________________

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

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

[Paul Davis]

>> you do it using ~/.asoundrc to define a PCM device that has the
>> channel characteristics you want.
>>
>> next, you'll be asking how. that's the part i can't help you with. the
>> archives have some examples, and there are several people on the list who
>> can tell you.
>
>aha, so the idea is that an application can only open a device with a number
>of channels and the user uses the configuration file to map channels? there
>is no way for an aaplication to open a device for output on specific
>channels
>, perhaps using a channel mask as in EASI?

correct. i know you love EASI, but its definitely not the paradigm in
use by ALSA, at least not currently.

--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

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

[Martijn Sipkema]

> correct. i know you love EASI

is it that obvious? :)

perhaps if more people like it, it would make sense porting
it to linux...

--martijn









_______________________________________________________________

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

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

[Paul Davis]

>> correct. i know you love EASI
>
>is it that obvious? :)
>
>perhaps if more people like it, it would make sense porting
>it to linux...

much less sense than porting ASIO, i'm afraid. there are very few
programs for win/macos that use EASI, but lots that use ASIO, and an
ASIO layer would make porting the audio side of such programs much
easier. 

personally, i don't like either of them very much, which is partly why
i wrote JACK. 

--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

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

[Martijn Sipkema]

> >> correct. i know you love EASI
> >
> >is it that obvious? :)
> >
> >perhaps if more people like it, it would make sense porting
> >it to linux...
>
> much less sense than porting ASIO, i'm afraid. there are very few
> programs for win/macos that use EASI, but lots that use ASIO, and an
> ASIO layer would make porting the audio side of such programs much
> easier.
>
> 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.
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. 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?

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

--martijn





_______________________________________________________________

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

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

[Paul Davis]

>> 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