Re: Query devices in a non-blocking fashion

[Paul Davis <paul@linuxaudiosystems.com>]

>I don't agree. The control API (usually) is for things that don't affect
>the way data is transferred between the card the the computer. 

it is *now*. i was just imagining a different conception of what it
could be used for.

>								Sample rate,
>format, etc. are used to configure the hardware at the driver level, but
>from the point of view of the application they are attributes of the
>substream. The application has to take them into account. It can't just
>open the PCM device and play/record something without knowing the
>format. 

if the app can't do that, it should first configure the device. no
question about that. the question is: what API do you use to do it? i
was just imagining that the PCM interface doesn't do any of it. this
would then decouple one from the other - you could interrogate
configuration possibilities independently of accessing the PCM device
itself, as arve suggests also.

>									   So
>you'll end up always using two different APIs to do the same things you now
>can do with only one.

i was imagining removing the capability from the PCM API.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/