Re: [linux-audio-dev] Behaviour of write() in blocking/non-blocking mode

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Behaviour of write() in blocking/non-blocking mode
From: guenter geiger (geiger_AT_xdv.org)
Date: Fri Nov 29 2002 - 17:55:39 EET


On Thu, 28 Nov 2002, Greg Ward wrote:

> On 27 November 2002, rm said:
> > if you can help it, you might look at alsa (alsa-project.org) and jack
> > (jackit.sf.net) which is built on alsa. both are much nicer than OSS,
> > and make life much easier.
>
> Yeah, I've dabbled with ALSA in the past -- mainly because I had a
> machine at work with non-standard audio hardware that was only supported
> by ALSA. Don't tell my boss, but I spent half a day figuring out ALSA,
> patching and rebuilding my kernel, building the utilities, and rebooting
> just so I could listen to music on that machine. Ahh, those were the
> days...
>
> However, I want to make sure that the Python linuxaudiodev works
> out-of-the-box for 90% of Linux users, which I guess means it has to
> stick to the OSS API. (For now.)
>
> > with respect to audio, i don't think there are defined semantics.
>
> *sigh* I was afraid that's what the answer would be. Oh well.

You can rely on the fact that blocking write will write the whole
buffer to the sound device. (Unless something bad happens).
For non-blocking mode, you can rely that the call will return immediatly
instead of waiting to be able to write the rest of the buffer.

So non-blocking may not comsume the whole buffer, but it is useful
because you can do other things while waiting for the audio to be
played.

These are the semantics, if this doen't hold, then its a bug in the
driver.

Guenter


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Nov 29 2002 - 18:00:04 EET