Hacker News Reader

Comment by b20000 | Hacker News Reader

b20000

for realtime applications with multiple threads, e.g. audio DSP, how does qt handle all the complexity with async stuff and messaging between threads without locking all over the place and how does it avoid excessive dynamic memory allocations?

View on HN

For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue) to communicate from / to the UI threads. Code more-or-less looks like

    connect(model, &ModelObject::somethingChanged, [=] {
      // knead the data structures used for the UI-side data model into something much simpler 
      // used for the audio engine
      audioQueue.push([... data ...] { update the engine with the new data });
    });

and conversely from the engine to the UI thread ; Qt signals do not cut it as emitting them allocate, if only a few bytes. (Doing it naively with std::function doesn't cut it either - I use this instead to store these functions: https://github.com/jcelerier/smallfunction/blob/master/small... ; also, the audio threads feeds back those functions into the main thread after their execution so that any memory owned by the lambda ends up being freed here and not in the audio thread.)

My own experience is with using QtWidgets in C++ for a multithreaded application that does some disk indexing and database management, the answer is "not that well".

I found that the primitives for threading and message passing between threads didn't work that well for me (both in terms of what they provide and in terms of performance) so I ended up "bypassing" them a bit with my own threading code (that is, still using QThread and QMutex etc. but not using the signals and slots model).

Once I've done that and moved everything off of the main thread, things worked well, so that program is still in QtWidgets with C++ and still in use, but I felt that Qt didn't do a good job of making multithreading easy for me.

That said, I still like continue to use Qt so you can consider this a sort of mild endorsement from me, I guess.

That is what I expected. These frameworks look nice, but were often not created with typical real world scenarios in mind but only work well for very simple data in/out applications where performance doesn't matter.

asking because that has been a major problem with JUCE.

No general framework will magically solve this problem, you need to tread carefully around the audio processing thread whatever you're using.

my point is that there is an opportunity for a framework that solves all these problems out of the box.

you could argue that drawing text is not a problem that a framework should solve. yet they do, so there is no reason that a framework cannot solve the typical problems of audio applications and inter thread communication etc.

Reply on news.ycombinator.com