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
