-
Notifications
You must be signed in to change notification settings - Fork 54
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
Getting choppy sound. #44
Comments
This is likely because gumble currently does not have a jitter buffer. One was worked on (#34), but I haven't had the bandwidth to review. |
hi @monirz how to fixing this issue? |
Regarding the “choppy sound” from Gumble, some users were referring to... What works perfectly between Gumble and Plumble/ official Mumble - is 48 kHz sound with 10 ms frame size. But as soon as the longer time intervals are used in Gumble for encoding sound, the resulting audio is breaking up in Plumble - and to a smaller level - official Mumble client. At the same, time, audio encoded with Mumble clients based on Gumble (talkiepi, talkkonnect) and when using any supported audio sample rates (48, 24, 16, 12, 8 kHz) and frame sizes (10, 20, 40, 60 ms) can be decoded near perfectly by all other Gumble based clients. No issues between Gumble clients on any audio sample rates or frame sizes. For just Gumble to Gumble communication any audio sampling rates / frame sizes seem to work with no issues. But not with Plumble / official Mumble – in the direction from Gumble to them. The problem could be related to jitter buffering in Plumble/ Mumble. Gumble is using AutoBitrate formula, based on server maximum bitrate (bitrate.go in gumbleutil). Plumble/ official Mumble seem to have a problem decoding bytes from Gumble produced audio frames (as defined in bitrate.go dataBytes formula) when the frames are longer than 10 ms. Unless a workaround can be found in Gumble or a jitter buffer improved in Plumble (or official Mumble), communication between them and Mumble clients based on Gumble, with lower audio sampling rates and when using longer than 10 ms frames (20, 40, 60 ms) will continue not to work very well. On the other hand, 48 kHz sound with 10 ms works near perfectly between Gumble-like clients and Plumble/ official Mumble clients. But as soon as the time interval is extended over 10 ms, audio from Gumble will start breaking up in Plumble/ official Mumble. Is there anything that can be done for making Gumble more compatible with Plumble/ official Mumble when it comes to working with longer frames (20, 40, 60 ms) for low bandwidth applications? Or should a fix be sought on Plumble/ official Mumble client side? |
Is this correct? Mumble only supports one sample rate: 48,000 Hz.
The error very well could be in gumble's bitrate calculation. If gumble is sending more audio data per-second than is permitted by the server, the server will drop audio packets, which would result in choppy sound.
I find it interesting that you're not experiencing any issues receiving audio in gumble clients. I thought there was a stronger need for a jitter buffer for gumble, so I'm surprised you haven't seen that in your testing. |
Thank you for a quick answer. First off, big thanks and congratulations on creating Gumble, such a fantastic project deserving a lot more credit. |
Hi Tim, |
Hi all, I'm also experiencing the described problem with my local setup: zrdimetc, you suggested, that the problem is on Plumble side, but I it looks like this is questioned by streaps who says, that opus is using 48kHz independent from the sample rate of the in-feeding audio stream. (on gitlab It seems that the discussion got stuck here and I am very sad about the fact, that I'm just a user having a problem but not the skills for contributing in a more constructive way. Thanks and best regards |
Hi Torsten, if your only issue is making talkiepi audio work smoothly with Plumble/ Mumla, then I suggest you use audio.go from Gumble. Just replace talkiepi audio.go and recompile. Your problem will be solved. Did you try talKKonnect? Regards. |
Hi zrdimetc, thanks for your reply. I managed to recompiled talkiepi as described by you, but it looks like this is not a solution which works in my setup.
If you have a spontaneous idea why this happens, please let me know. I fear it can have multiple reasons because of the specific setup (talkiepi with Pi Zero +ReSpeaker 2-Mic HAT) and I suggest, that a long search for the bug would be a bit off topic here. Especially because my linux and programming skills are rather poor. I didn't try talkKonnect, yet. It looks promising, but I suggest it needs a lot more customization to serve my needs than an "of the shelf" talkiepi. Nevertheless thanks for your support! |
Hi Torsten, I can only suggest that Raspberry Pi Zero is just not such a good platform for building talkiepi, or other Gumble based projects. Neither is Re-Speaker 2-Mic Hat a good part pick. It may sound like a good idea at first, but both pieces of hardware have serious shortcomings for working with Gumble. That is if you want your build to work with Plumble or Mumla too? Re-Speaker kernel driver is missing some rate converters. This is why you get the errors. You need to use |
@zrdimetc, I disagree with you: I just built two house intercoms on RPiZ+ReSpeaker, and both are working pretty fine (btw, I did small refactor of takiepi code for proper work with GPIO, and added pin controlling events for incoming audio stream - my wife asked especially for this feature 'cause our oldest daughter usually playing Nintendo Switch in headphones, but now she will be able to see colorful LED strip animations when mom called her from kitchen too 😉) I also set sample rate for talkiepi to 24000 samples per second. As for Plumble Android client: free version I've installed from play store, has settings, and you can adjust audio settings too, including sample rate and and buffer size. After playing for a little with audio settings, I got an affordable, non-choppy sound quality. To give RPiZ some "rest", I moved mumble server (murmur) to my Windows-based home server but initially it worked on the same RPiZ 😉 Here are my assemblies: I reused non-properly worked (a lot of noise and radio interference) analog intercom cases I've purchased on eBay (but seller issued a full refund). |
Very good @sensboston. Maybe you can offer Torsten a practical advice, if not here then in talkiepi github or site? He needs to know how to solve the rate converter problem with Re-speaker hat and compile OpenAl without Neon support in Debian 10 because these issues were a show-stopper? And then he can follow your example to adjust audio quality? As far as the audio quality, I didn’t say you can not use talkiepi audio sample rate of 16000 or tweak to 24000 like you did. Supported rates are 8000, 12000, 16000, 24000, 48000. Use any. Tried them all. For short voice transmissions, it really doesn’t matter if audio jumps and breaks sometimes. A voice message will be passed. It’s just unpleasant to listen sometimes. To spot a problem you need to stream music with gumble ffmpeg or play a continuous audio test tone, let’s say 1 kHz sine wave and while ensuring your network is near lossless, the audio will evidently be breaking up in a direction to Plumble. If you run continuous audio stream for some time you will surely notice. Some people will also easily notice quality issues with voice. Most builders won’t mind. Between gumble forks you can use any settings you like without audio quality issues. But there are dozens of issues raised by talkiepi builders about “choppy sound”. Every time the builders reported the same issue. Talkiepi audio quality with Plumble. Why was it breaking? This is why it was raised here as well, to try to understand the logic behind Gumble audio encoding / decoding, OpenAl role and how it may affect working with other Mumble clients or Gumble forks, so that Gumble creator can assess if anything needed to be adjusted in Gumble? For the reported issue, not really. That particular issue is not Gumble’s fault. Gumble creator did a fantastic job like a true genius! I tested audio quality of Gumble forks for quite a few hours, for over two years. Suvir Kumar made considerable changes in his gumble/talkiepi fork talkkonnect resulting with amazing improvements as far as the audio quality, functionalities and stability of code. Maybe some of his changes could be accepted by the creator or Gumble? As far as the adjustments in Plumble for audio sample rate, app slider function is only adjusting the rate for encoding/ transmitting. Again, it doesn’t matter for Plumble talking to Plumble. Issue has always been Gumble fork talking to Plumble, once the audio sample rate in Gumble is set bellow 48000. I think Gumble creator could close this issue if nobody else has more relevant findings to contribute to the “choppy sound” issue or try to suggest it's a Gumble issue? It's good the question was asked, but the "choppy sound" it's not Gumble's fault. Practical build issues for Gumble forks are probably best addressed at the fork’s sites, if everybody agree? |
I don't think so: it looks like he did very same as I (I fixed only talkiepi-s "weak" GPIO part, by completely removing github.com/dchote/gpio and re-using github.com/stianeikeland/go-rpio; I'm ready to issue a PR but looks like @dchote haven't appeared here for a long time). I did nothing special (about audio quality) but of course I've tested short phrases only (haven't streamed music of course). Might be, some audio glitches still exist but I don't really care 😜 You said:
and
I disagree with both statements; what's the only reason I left my comment. RPi Z + talkiepi works just fine on 48Ks/s but that sample rate is too much for the voice, 16K or 24K (he-he, we're all humans 😉) is enough. By the way, initially, when I found audio glitches (choppy sound) by testing my first RPi intercom from Android phone, I thought it's talkiepi code/algorithm issue(s) - because I already found & fixed issues with GPIO. But after reading your comments (above in this thread), I understand, issue source is much deeper/complicated than simple bugs or incorrect implementation. But it's irrelevant for me now; my inhouse intercom works just fine and I finished this project by creating sdcard images from both devices (just in case). |
Hello, we are using Gumble for voice chat in murmur server, everything is working fine except the sound quality is so choppy that it's hard to continue the conversation. And that's a big problem. As I saw some issues and discussion on that, I tried using
AutoBitrate
for adjusting bitrate from the server. The server's bitrate is set to 96 KiB/s. I tried changing different AudioInterval and at 60ms it makes it little better but it's not that good as usable. Any suggestion on that for improving the sound quality?Thank you!
The text was updated successfully, but these errors were encountered: