[pulseaudio-discuss] Best Case Latency

[Tanu Kaskinen]

On Thu, 2013-10-17 at 14:56 +0200, David Henningsson wrote:
> On 10/17/2013 02:46 PM, Tanu Kaskinen wrote:
> > 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.
> > 
> 
> Okay, you're probably right. The asyncmsgq is not infinite in size
> either, you'll instead get some "q overrun, queuing locally" after a
> while, but that will still consume memory. However, my point remains: if
> the main thread will never get back to zero queue length after something
> happens in the system, we have a general shortage of CPU that
> reprioritising threads will not be able to fix.

Yes, sure, I don't think anyone suggested reprioritizing the threads. I
mentioned one possible way to deal with this (right after the point
where you cut the quotation): if the queue length reaches some upper
limit, kill the stream that is connected to the jack source.

-- 
Tanu