9 ms·

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 lo

by b20000 5y ago

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?

b20000 5y ago
asking because that has been a major problem with JUCE.
- Ycros 5y ago
  No general framework will magically solve this problem, you need to tread carefully around the audio processing thread whatever you're using.
  - b20000 5y ago
    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.
Adverblessly 5y ago
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.
- b20000 5y ago
  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.
jcelerier 5y ago
For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue 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/smallfun/include/smallfun.hpp 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.)

by b20000 5y ago

b20000 5y ago

asking because that has been a major problem with JUCE.

Ycros 5y ago
No general framework will magically solve this problem, you need to tread carefully around the audio processing thread whatever you're using.
- b20000 5y ago
  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.

Adverblessly 5y ago

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.

b20000 5y ago
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.

jcelerier 5y ago

For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue 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/smallfun/include/smallfun.hpp 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.)