QAudioOutput start() takes too much time

Gauthier

Hello,

I'm working on a audio app that aims raspberry pi and mobile phones.
It consists of 8 audio channels loading samples and allowing to play live or using internal sequencer.

Each channel has its own QAudioOutput and store sample in QByteArray / QBuffer in a way that when I need to play a sample I just need to do this :

if (m_buffer.isOpen()) {
        m_buffer.close();
    }

    m_buffer.setData(m_noteBuffer[value]);
    m_buffer.open(QIODevice::ReadOnly);

    std::chrono::high_resolution_clock::time_point before = std::chrono::high_resolution_clock::now();
    m_audioOutput->start(&m_buffer);
    qDebug() << "Play " << m_index << ": " << std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::high_resolution_clock::now() - before).count();

m_buffer is a QBuffer
m_noteBuffer is an array of QByteArray containing various pitched versions of my sample.

As you can see I measured the time needed to call QAudioOutput start and I took between 500 - 1000 microseconds on my powerfull dev PC.

When I play multiple channels at the same time on Android for example, I can clearly hear that they are not perfectly sync (on Dev PC no problem as 1ms is ok but QAudiuoOutput start is probably much longer on Android).

I already put each channels in separated threads and use signal ans slots to parallelize this part but It didn't helped a lot.
I think that the problem is the time consumed by QAudioOutput start.

I tried to avoid using start by just calling seek(0) on the buffer and call resume on QAudioOutput but even if the time consumed is really lower (20-80 microseconds), the resulting audio has more latency :/

Is there a way to reduce time consummed by QaudioOutput start ?
Any idea on another way to do this ?

Thanks for you help

Gauthier

Some more info about the latency problem. I just measured the time taken by the QAudioOutput start on my android phone.
Time varies from ~650 micro-seconds at best, to more than 5000 micro-seconds for the same played sample in the exact same conditions.

I think this confirm what I was thinking.
Such a time variation (near 1 to 10 ratio) is probably due to Android, maybe some battery life optimisations or something like that.

I'm now searching for Android manifest config that could reduce the problem.

Any suggestion would be welcome :)