Hey, It is definitely taking to much time, enough to cause buffer drops in this situation.
I have changed to a callback calling mechanism and the problem is now fixed. I now have this in mind when I program sensitive parts of my apps. Regards, Nuno > On 22 Apr 2016, at 17:34, Alejandro Exojo <s...@badopi.org> wrote: > > El Friday 22 April 2016, Nuno Santos escribió: >> Then I made an experiment. Arpeggiator was using a signal to send the >> noteOn to the audio render engine. I decided to call the function directly >> on the synth render engine. Guess what, the problem disappears. >> >> Is the signal/slot mechanism tied to the event loop? How much does it take >> for a signal/slot to be called? It might not be significant on a desktop >> computer but it certainly is on a ARM device specially in this kind of >> performance sensitive contexts. > > This paragraph in the documentation (same link Benjamin sent) is also pretty > enlightening: > >> Compared to callbacks, signals and slots are slightly slower because of the >> increased flexibility they provide, although the difference for real >> applications is insignificant. In general, emitting a signal that is >> connected to some slots, is approximately ten times slower than calling >> the receivers directly, with non-virtual function calls. This is the >> overhead required to locate the connection object, to safely iterate over >> all connections (i.e. checking that subsequent receivers have not been >> destroyed during the emission), and to marshall any parameters in a >> generic fashion. While ten non-virtual function calls may sound like a >> lot, it's much less overhead than any new or delete operation, for >> example. As soon as you perform a string, vector or list operation that >> behind the scene requires new or delete, the signals and slots overhead is >> only responsible for a very small proportion of the complete function call >> costs. The same is true whenever you do a system call in a slot; or >> indirectly call more than ten functions. The simplicity and flexibility of >> the signals and slots mechanism is well worth the overhead, which your >> users won't even notice. > > That was probably written long ago. I've read people mentioning that it might > be that signal emission would be slower nowadays. > > Also, what type are you passing in the signal? The value is copied, so if > it's > expensive to copy, that might be a factor as well. I believe that is one of > the reasons why APIs like QIODevice don't send the received data through the > signal, but just the notification of the presence of new data. Later on you > have to retrieve it. > > -- > Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 > http://barnacity.net/ | http://disperso.net > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
