QAudioInput :: byteReady () and QIODevice :: read (), giving a different number of bytes

I have a doubt with the following code snippet ...

const qint64 bytesReady = m_audioInput->bytesReady(); const qint64 bytesSpace = m_buffer.size() - m_dataLength; const qint64 bytesToRead = qMin(bytesReady, bytesSpace); const qint64 bytesRead = m_audioInputIODevice->read(m_buffer.data() + m_dataLength, bytesToRead); 

The bytesReady () method gives me a certain number of bytes and skips that number of bytes in the read () QIODevice, which will return me the number of bytes read.

The problem is that bytesRead is not equal to bytesToRead. And I get a fixed number of bytes from the reading method ie 320, 640, 960, 1280, etc., And it depends on byteToRead.

+6
source share
2 answers

There is no direct relationship between QAudioInput::bytesReady() and the QIODevice on which it writes its samples.

QAudioInput supports an internal I / O device (system dependent) to an audio system that is an analog read-only QIODevice . When you call bytesReady , it returns the number of bytes available for reading, the analog value of QIODevice::bytesAvailable() . Those who do not have not yet written to the output of QIODevice , so when you do m_audioInputIODevice->read immediately after it, without event processing, you actually get samples that were written earlier, and not those that are still in the sound buffer.

This plus IODevice buffering, explains why numbers can be different, and I don’t see a way to synchronize them.

Actually, you should do:

 const qint64 bytesRead = m_audioInputIODevice->read(m_buffer.data() + m_dataLength, bytesSpace); 

to get everything that is available in IODevice, up to your available buffer space.

+7
source

Even better:

Use ->readAll() , which returns QByteArray "qba"

... then use sz=qba.size() , which will tell you that you are GOT (may be null)

... then do something with it using sz and qba.data();

... it seems without errors, unlike most of QAudioInput , which is incredibly violated, for example, an arbitrary limit of the sampling rate of 48000 under Windows, but not OSX, the pull mode uses the foreground stream, so it will be constantly broken into any real situation, bytesReady() doesn't make sense ... Worse. Qt. Routine. Evar!

+2
source

Source: https://habr.com/ru/post/910479/


All Articles