[Interest] is it ok to push audio on a background thread, not a timer?

[Konstantin Shegunov]

On Wed, May 20, 2020 at 2:13 AM David M. Cotter <dave at kjams.com> wrote:

> is it possible i'm just using QThread wrong?  and it HAPPENS to work fine
> on mac but fails on windows?
>
> is this blogger really revealing the ONE TRUE NATURE of QThread:
>
> https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/
> ?
>

The one true nature? Probably not, but the rather the habitual way of
threading an event driven piece of code (like some sort of QObject
controller class, a socket or w/e). One can derive from QThread, obviously,
for an imperative piece of code (like numbercrunching), however in case
you're going to use a worker object that's just not quite necessary (i.e.
just use composition). I've seen people derive from QThread, and initialize
objects in the run() method, and then call exec(), but as far as opinions
go, mine is that this is a poor choice of approach (correct if it may be).

Concretely, touching QAudioDeviceInfo::availableDevices() from a thread is
probably a race condition, as the function isn't marked as thread-safe. If
you really need to use its result, I'd say you'd need to pull the info
while you're in the main thread (say in your constructor) and then delegate
it on. However, a thing, which's worrying somewhat, is
that QAudioOutput's methods aren't marked as reentrant (unlike QObject's)
so unless that's a miss in the documentation you're not going to be able to
use it from a separate thread at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20200520/98177e44/attachment.html>