At Mon, 27 Oct 2003 13:11:58 +0100, Andreas Mohr wrote: > > Hello Takashi, > > On Mon, Oct 27, 2003 at 01:01:37PM +0100, Takashi Iwai wrote: > > At Sat, 25 Oct 2003 22:02:21 +0200, > > Andreas Mohr wrote: > > > Or, as a short summary: > > > The application is perfectly well aware of how many bytes there are left > > > to read (from calling SNDCTL_DSP_GETISPACE) and then does a read() with > > > this amount of bytes, however since the ALSA OSS layer attempts to read > > > this byte amount in blocks of runtime->oss.period_bytes bytes from the sound > > > device, we ARTIFICIALLY cause a -EAGAIN to be returned due to insufficient > > > available data, thus potentially confusing many OSS applications. > > > > > > Now what to do here? > > > > this problem is a bit touch, because the ALSA OSS layer does the > > sample-rate conversion, etc. > > when the sample rate is converted between 44.1kHz and 48kHz, some > > round error may happen and it will be accumulated. hence, the size > > will be different between two cases: reading a whole period once and > > reading a period by multiple calls. > > > > i'll take a more deeper look... > Ah, thanks! (also for the explanation given above) > > Given that 1.0 is approaching, it'd certainly be useful to get such a > problem fixed ;-)
i come to believe that it's a bug, too. as you wrote, the fix is easy except for the rare problem what i mentioned above. in that case (e.g. the sample-rate conversion between 44.1 and 48khz required), you'll still get -EAGAIN occasionally. but normally, it seems ok. the attached is the patch to fix the original problem. to take back to the old behavior (always reading a whole period), you can write "whole-frag" command to the proc file. anyway, i'll try a bit more to solve the problem above. Takashi
oss-capture-fix.dif
Description: Binary data
