On 2014-10-08 05:07, Alban Browaeys wrote:
Should prebuf always be greater or equal than minreq ?
I face an issue on an ARM board (cortex A9, odroid with a debian install
upon it ).
That is with a low requested buffer_size from the application,
native-protocol fix_playback_buffer_attr up all the fields except prebuf
(as it is not -1 but a value computed from the initial buffer size)
Affected applications are alsaplayer, moc, also aplay if fiddling with
the buffer size to lower the default (after investigation I could
workaround the issue with a up of the buffer size in its code).
Still the logs when I get underruns that are piling up, never recovered
properly and sound is weird, it shows : prebuf=2048 minreq=17628 and
tlength=52896
If you have a very low prebuf, you're likely to get an underrun in the
beginning, because the sink would very quickly eat the first few
prebuf-ed samples and then underrun.
After the underrun, you feed it with very few new samples (because you
have so low prebuf), so the underrun happens again. And again. And again.
So this looks like a case of just "too low prebuf". It does not seem to
have anything to do with minreq.
But potentially, minreq affects the period size of the buffer, and on
some cards this also affects DMA transfer sizes and pointer updates. So
it's not impossible that on some hardware (e g that would feed the
hardware one period at a time), having prebuf < minreq is a bad idea.
But I don't think this holds across all hardware, especially tsched mode
should be able to cope with small prebufs, as long as the prebuf is big
enough not to underrun before the application supplies more data.
// David
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
