On Sun, 07 Dec 2003 14:19:28 -0500 Paul Davis <[EMAIL PROTECTED]> wrote:
i personally am heading towards believing that we made a design decision that was wrong here. i now tend to think that the PCM interface should not be involved with configuring the hardware at all, and that this should be left to the control API. when you open the PCM device, you get whatever is currently configured. if that's not what you want, you open the control API first, configure the device, then open the PCM device. i think this would be much much simpler for most application programmers (not as simple as JACK, but ...) and it would also mirror what happens in the windows world to some extent, where control applets are used to change aspects of the card config.
still, its pretty much too late for that.
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. 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. So
you'll end up always using two different APIs to do the same things you now
can do with only one.
Wether its done via the control or pcm interface, it'd be good to have a loose coupling between configuration and streams, so one could could access configuration space without locking a stream don't you think? I mean, with ASIO, from what I can see there is no problem obtaining info about devices in the system even if they might be in use. Shouldn't we at least aim for the same flexibility with ALSA?
Regards
Arve Knudsen
------------------------------------------------------- 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/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
