Subject: Re: [linux-audio-dev] Still I cannot understand why...
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Sat Dec 15 2001 - 22:58:24 EET
On Sat, 15 Dec 2001, Paul Davis wrote:
> ALSA poll interface is (necessarily) a bit complex. but it would still
> be a huge step to have applications move to this model rather than the
> block-on-read/write one that so many do these days.
Or is it? I think the read/write interface suits well for implementing
wait()-then-operate(). With a blocking read() application says, "wait
until next hw-interrupt, then copy data to my buffer area". With write(),
"wait until next hw-interrupt, copy data from my buffer area". So it's
just as good as using poll/select.
The biggest difference is probably the ability to wait on multiple device
handles, but if we have a syncronously working system, waiting on one
device is enough (--> blocking call on other devices will never actually
block unless an error has occured). And from reading your recent messages
on alsa-devel about the trident driver, polling on multiple handles
doesn't seem completely carefree either. ;)
> I don't care about the details of the API. I don't care if its JACK,
> PortAudio, CSL ALSA, OSS, or whatever. What I care about is that the
> API supports, nurtures and sustains program design that in turn
> facilitates a synchronous execution system. PortAudio is the only
This is a very good point, and one that makes me lean towards JACK.
> some of the gstreamer folks seem interested in adding a JACK I/O
> module, which would render that part of things mute.
Hmm, could gstreamer be used as the lower-priority frontend server? Does
it support dynamic client registration?
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Sat Dec 15 2001 - 22:57:15 EET