Most QT resources seem to want me to use higher-level classes like
QMediaPlayer or QSoundEffect to point at extant files or possibly a
QAudioBuffer which is already filled with a QByteArray. There’s really
not much out there about synthesizing audio and playing it straight
through a QAudioDevice.
The latter may operate in push mode or pull mode; the docs will tell you as
much. What may be less obvious is how those modes are chosen. It’s simply
your choice of overloaded method:
QIODevice QAudioOutput::start(); // push mode
void QAudioOutput::start(QIODevice *dev); // pull mode
Looking over the pre-made classes that implement QIODevice, I notice that
they love to tell you when data is ready to read but not when data may be
written. And in both modes, the QAudioOutput is doing the reading and
your application needs to know, somehow, when it should write.
So, I implemented my own QIODevice around my own buffer type. The class
actually holds a pair of buffers, one being written by the generator thread
and one being read by QAudioOutput. When both are finished, the buffers are
swapped. Whenever the output calls read, I format data from the app’s
buffer into bytes, directly into the output pointer.
And actually, nobody calls write. The generator can be connected directly to
the app buffer, which provides its own append() method that consumes
(potentially many) snd_sample_ts.
There are a pair of signals and slots each side uses to communicate about
their shared buffer:
class SndIO : public QIODevice {
Q_OBJECT
...
public slots:
void writeComplete(SndBuf *buf);
signals:
void readyWrite(SndBuf *buf);
void emptied();
void underrun();
}
class SndThread : public QObject {
Q_OBJECT
...
public slots:
void start(SndBuf *buf);
signals:
void finished(SndBuf *buf);
}
The main thread then connects SndIO::readyWrite to SndThread::start and
SndThread::finished to SndIO::writeComplete. The SndBuf itself isn’t used
simultaneously by multiple threads, because the IO won’t touch it until the
Thread has signaled that it has finished filling it.
This produces a four-state system, starting with “both buffers empty” before
the main thread wires the objects and initiates the first fill on the IO.
1. empty/empty
2. empty/filling
3. draining/filling
4. draining/full
When state 2 emits finished, state 3 begins; emission of emptied there returns
to state 2, otherwise, finished happens again and state 4 is entered. From
state 4, the only move is back to state 3 when the emptied signal is emitted.
After the initialization period (once state 3 has been entered for the first
time), it’s possible for state 2 to receive another read from the
QAudioOutput; this emits the underrun signal without changing state.
This is a actually a slightly-more-complex version of the producer/consumer
problem. Instead of a single producer and consumer directly communicating,
there is an intervening QIODevice carrying data across threads, consuming
the generator’s output, then marshaling and producing it for the output to
consume.
I’m also effectively using signals and slots to let the event loop block the
producer when it gets too far ahead. When that happens, no “produce more”
signal is delivered until the output can catch up.
All that said, this setup compiles but I haven’t finished wrapping a test
program around it yet.
