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
