> > 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>
