29 Nov
2002
29 Nov
'02
noon
On Thu, 28 Nov 2002, Greg Ward wrote:
On 27 November 2002, rm said:
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
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.