-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong format on mumble_onAudioInput #6464
Comments
What is the We pass mumble/src/mumble/AudioInput.cpp Line 1095 in 7879992
However, iFramesize is the total length of the passed audio data buffer as illustrated e.g.mumble/src/mumble/AudioInput.cpp Line 1107 in 7879992
Therefore, I think this is a bug on Mumble side where the passed sampleCount is actually the total buffer length (sampleCount * channelCount ). However, I think that Mumble doesn't even support more than a single channel for audio input so if the above is true, I'd have to dig a bit further to see where the downmixing to mono happens 🤔
Some things I noticed in your code:
You must not free the audio data - it is still used by Mumble itself. Functionally, this just does nothing as the plugin backend does some checking and only deletes objects that it knows have to be deleted. Thus, this call will always return
This is functionally equivalent to simply iterating over the |
Hi Robert, You are right, that is exactly the case, channelCount is being passed by mumble as 2, however I've done a quick test now and if I assume there is only one channel (with 480 samples) and save it as mono audio, now I get the audio correctly saved. Thanks a lot! Also, thank you for your other comments about my code. |
…llback In the mumble_onAudioInput callback that plugins can use, the sampleCount parameter was actually wrong for all cases in which the input had more than a single channel. Instead of the sample count per channel, the total sample count (across all channels) was passed along. Fixes #6464
In the mumble_onAudioInput callback that plugins can use, the sampleCount parameter was actually wrong for all cases in which the input had more than a single channel. Instead of the sample count per channel, the total sample count (across all channels) was passed along. Fixes #6464 (cherry picked from commit e48dd5c)
Description
Acording to the documentation, in the mumble_onAudioInput callback I should get 16 bit PCM audio, but no matter how I save it I don't manage to get the right sound. I'm accumulating 100 calls (480 samples at 48000), which is a second, and I always get the second half of each group of samples (480) as random/unassigned values:
Focusing on 10ms, 480 samples:
Seems that the first part is "ok" but the second one is just random values.
Maybe I'm doing something wrong, see my code below.
Steps to reproduce
Write a mumble plugin, try to save the audio on the mumble_onAudioInput callback.
Mumble version
1.5.634
Mumble component
Client
OS
Windows
Reproducible?
Yes
Additional information
This is my code for all this:
However if I save just 480 samples I get the same. I tried to use libraries to save the wav file, same result. I saved just the PCM data without wav header and loaded it on Audacity as signed 16 bit PCM, interleaved audio at 48k, same result.
Relevant log output
No response
Screenshots
No response
The text was updated successfully, but these errors were encountered: