QAudioOutput start() takes too much time

  • 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()) {
        std::chrono::high_resolution_clock::time_point before = std::chrono::high_resolution_clock::now();
        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

  • 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 :)

Log in to reply