At Sat, 25 Oct 2003 22:02:21 +0200, Andreas Mohr wrote: > > Hi all, > > RAT (Robust Audio Tool, http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/) > shows quite miserable behaviour on ALSA/OSS (current CVS): > > [EMAIL PROTECTED]:/home/andi$ rat 193.8.230.138/2074 > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > audio_read: Resource temporarily unavailable > . > . > . > [EMAIL PROTECTED]:/home/andi$ > > I've been analyzing the reason for about 1.5 hours now, > and I guess I know what the problem is, but I'm uncertain as to how it should > be fixed (I could probably fix it, but I REALLY want to leave it to much more > experienced people since I'm afraid that code is VERY easy to break...). > > Our SNDCTL_DSP_GETISPACE implementation in alsa-driver/acore/oss/pcm_oss.c > calls snd_pcm_oss_get_space(), which returns the number of bytes available > to read (e.g. 224). > > RAT then does a read() with exactly this amount of bytes. > > The read() causes alsa-kernel/core/oss/pcm_oss.c/snd_pcm_oss_read() > to be called, with this amount of bytes passed. > > This now calls snd_pcm_oss_read1(), with the bytes set to the same amount > again. > > For some stupid reason, _read1() now ALWAYS calls into snd_pcm_oss_read2() > with an amount of runtime->oss.period_bytes bytes to be read, which happens > to be 256. > > With a blocking read, this would probably be no problem, since we just wait > until we have enough data in the buffer, however with a non-blocking read, > snd_pcm_lib_read(), which gets called by snd_pcm_oss_read3() that's being > called by snd_pcm_oss_read2(), simply returns -EAGAIN since it cannot handle > the much too large request. > > > 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... Takashi ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
