[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: [linux-audio-dev] Behaviour of write() in blocking/non-blocking mode
From: Greg Ward (gward_AT_python.net)
Date: Thu Nov 28 2002 - 04:13:31 EET

Hi all --

I'm making my first forays into OSS DSP programming with an eye to
improving the standard linuxaudiodev module included with Python. (And,
of course, to using that module for my own ends!)

I'm rather confused by the semantics of write() in blocking and
non-blocking mode. Specifically, in the default mode (blocking, no
SNDCTL_DSP_NONBLOCK ioctl() call), it appears that write() will happily
write the entire buffer passed to it, and not return until almost all of
the data has been played. (I assume the last dribble is in a
lower-level [hardware?] buffer, so when write() returns there's still a
little bit of sound to be heard.)

However, in non-blocking mode, write() plays roughly 64k or 128k
(depending on the hardware device used) and returns immediately. This
is more like what I was expecting -- I guess the behaviour in blocking
mode is a bit surprising. Is it supposed to be like this? More
importantly, can I *rely* on write() in blocking mode always consuming
the entire buffer passed to it?

BTW, this is with Linux 2.4.20-rc1; the two audio devices are a
SoundBlaster Live using the OSS emu10k1 driver, and a Stereo-Link
external USB audio device using, you guessed it, the USB audio driver.

Thanks --

        Greg 

-- 
Greg Ward <gward_AT_python.net>                         http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!

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

This archive was generated by hypermail 2b28 : Thu Nov 28 2002 - 04:18:28 EET