[pulseaudio-discuss] should prebuf always be greater than minreq ?

[Raymond Yau]

>
> 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
>
>
> in pulseaudio 5 (debian experimental, that is .0-12) :
> src/pulsecore/protocol-native.c fix_playback_buffer_attr ,I now  set
> prebuf to at least minreq (at the end of the function for now).
>
> Even alsaplayer (where I was not able to set a high enough buffer, even
> in code without extensive rewrite) works with this change.
>
> Mind PULSE_LATENCY_MSEC=60 also workaround the issue, though it looks
> like it only does so as it forces the prebuf to tlength (which is always
> higher than minreq).

http://freedesktop.org/software/pulseaudio/doxygen/structpa__buffer__attr.html

Depends on sound card can report update position
DMA_RESIDUE_GRANULARITY_BURST or DMA_RESIDUE_GRANULARITY_SEGMENT?

It look like the theortical minimum value of minreq is dma brust size or
period size of the sink

The theortical minimum value of prebuf is fifo size or two periods of the
sink

The practical values should be much higher if pulseaudio can switch audio
stream to different sink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20141010/81bfab01/attachment.html>