2010/4/26 Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx> > : > > 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 > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
