Unsolved 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()) { 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
-
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 :)