[pulseaudio-discuss] Best Case Latency

[David Henningsson]

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.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic