[alsa-devel] "Resource temporarily unavailable" while reading although poll returns POLLIN event
Raymond Yau
superquad.vortex2 at gmail.com
Tue Apr 27 02:35:08 CEST 2010
2010/4/26 Stefan Schoenleitner <dev.c0debabe at gmail.com>
> :
>
> In my tests I first used the "default" device which uses the PA plugin.
>
The test clearly showed that poll() returns with POLLIN even though far
>
less than avail_min frames are available for reading.
> Hence I suspect that there is a *bug* somewhere in the pulseaudio code
> (either the plugin or the daemon).
>
> In order to show that my code is working fine and the erroneous poll
> behavior does not occur when PA is not used, I also tested with the "hw"
> device.
> The result, as mentioned, it that the POLLIN event is correctly returned
> after at least avail_min frames are available.
>
> In short:
>
> * test with "default" uses PA: erroneus poll() behavior, BUG
> * test with "hw" does *not* use PA: everything works fine
>
>
http://0pointer.de/blog/projects/guide-to-sound-apis.html
Most likely , the PA developer will tell you
Do *not* touch buffering/period metrics unless you have specific latency
needs. Develop defensively, handling correctly the case when the backend
cannot fulfill your buffering metrics requests. Be aware that the buffering
metrics of the playback buffer only indirectly influence the overall latency
in many cases. i.e. setting the buffer size to a fixed value might actually
result in practical latencies that are much higher.
Do *not* assume that the time when a PCM stream can receive new data is
strictly dependant on the sampling and buffering parameters and the
resulting average throughput. Always make sure to supply new audio data to
the device when it asks for it by signalling "writability" on the fd. (And
similarly for capturing)
>
> > Do you mean that you suspect the problem is related to alsa-pulse plugin
> or
> > PA server ?
>
> Yes.
>
> cheers,
> Stefan
>
More information about the Alsa-devel
mailing list