[pulseaudio-discuss] Best Case Latency

[Tanu Kaskinen]

On Thu, 2013-10-17 at 14:04 +0200, David Henningsson wrote:
> Sorry for jumping right in without having read the complete thread, but
> anyway...
> 
> On 10/07/2013 11:23 AM, Patrick Shirkey wrote:
> > On Mon, October 7, 2013 7:41 pm, Tanu Kaskinen wrote:
> >> Ok, so this happens when the native protocol tries to send a block of
> >> audio from the jack source thread to the main thread. My guess is that
> >> the main thread is not getting enough CPU time to deal with all the
> >> incoming audio (it's not RT scheduled).
> >>
> >> This could very well cause growing latency. If the jack source pushes
> >> audio blocks to the message queue faster than the main thread reads
> >> those blocks, then that message queue becomes a significant (and
> >> constantly growing?) audio buffer.
> 
> Constantly growing does not sound right - over time, there should be
> enough CPU to run all threads (RT and non-RT), if not, we're too short
> of CPU in total, which is not a priority problem.
> 
> >> What to do? I don't know. Currently there's no upper limit for how long
> >> the message queue can grow (so this is effectively also a memory leak
> >> problem), and no way to query the queue length. 
> 
> In practice, when starting a recording stream to an app and that app
> hangs, you quite soon start to get either "Pool full" or "Failed to push
> data into queue" errors. I don't remember which one of these it was, and
> I haven't investigated why, but I don't think we memory leak infinitely.

IIRC, "Pool full" is printed when trying to allocate a memblock, and the
whole memory pool has been consumed, but in that case malloc() is used
as a fallback. "Failed to push data into queue" is printed when
pa_memblockq_push() fails.

The growing buffer that I'm talking about is neither the memory pool nor
a memblockq, it's the asyncmsgq from the jack source thread and the main
thread. The jack source generates messages at a rate that the main
thread is not able to handle.

-- 
Tanu