@patent said in Why QAudioInput::bytesReady() always returns 5120 bytes:

Is it possible to somehow change the amount of data read by the microphone?

No, you have to split it in smaller chunks by yourself.
And UDP can transfer up to 64k but it should not be bigger than the MTU (~1500 bytes depending on the OS and the network architecture)

@eyllanesc, so is there any other way to extract the exact name of the default audio input file? Am I right, that the first element of the returned value of QAudioDeviceInfo::availableDevices(QAudio::AudioInput) is the DeviceInfo of the default audio input device?

I fixed my problem:

with a qDebug of lenght I have:

data.length() lenght 136 2730 740 1364 1326 1366 414 1364 208 1366 458 1364

As you can see they are not the same so, with this code, my problem is fixed:

void Window::processAudioFrame(QByteArray data){ const short* result = (short *)data.constData(); for (int i=0; i < data.length()/2; i ++ ){ ui->soundView->pushSoundLevel(result[i]); } }

After a few months of searching for an definitive answer to this topic, I've reached the conclusion that my original assumption would be correct. This page describes how to determine the midpoint of a standard PCM audio signal:

https://gist.github.com/endolith/e8597a58bcd11a6462f33fa8eb75c43d

For example an 8-bit signed PCM signal has these ranges:

Min: -128
Max: 128
Midpoint: 0

As to why the signal I'm getting from my soundcard sits at -128 when there is no sound, I'm going to assume that this is related to a driver problem or could be that this particular piece of hardware does not follow the PCM standard.

Converting to the logarithmic scale in my understanding is not related to this issue because you should be able to normalize the signal in time-domain even though eventually you will most likely need to convert it to the log scale if you are doing anything in the frequency domain (e.g. FFT).

If anyone has any input, please feel free to add it.

Hi,

See the documentation of bufferSize, you may not get what you requested because setting e.g. a too small buffer size might trigger overflow problem.

Hi and welcome to devnet,

QAudioInput returns a pointer to a QIODevice that will provide the audio data. Connect the readyRead signal from that QIODevice object to a slot of your class, there you can read the audio data received and make what you want with it.

Hope it helps

You then know how the data are arranged in your array as well as there range and the number of millisecond worth of them.

I am such an idiot... maxSize is in bytes and I have divided it by 16... now it works.

Hi and welcome to devnet,

You have an example on how to use QAudioProbe in the detailed documentation of the class. As for measuring the level of a silent user, it's a completely other topic, you'll have to take into account the noise of the environment of the user.

I'd say probably, but right now I don't know what might be interfering here to trigger that message.

I just created an empty project to test some stuff. The following code

QAudioDeviceInfo info = QAudioDeviceInfo::defaultInputDevice(); // Empty string as output qDebug() << "Default input device" << info.deviceName(); // 0 as output qDebug() << QAudioDeviceInfo::availableDevices(QAudio::AudioInput).size(); // 0 as output qDebug() << QAudioDeviceInfo::availableDevices(QAudio::AudioOutput).size();

prints an empty string as input device, 0 available devices on WinRT. 'multimedia' is added as Qt module.
What could be wrong? A missing plugin (dll not deployed automatically)? Or is WinRT not supported (yet)?

Best
Wickie