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
