Closed s3m1s0n1c closed 5 years ago
Sonic, many code improvements and new features were introduced by Suvir Kumar in December and January. Please try to build again? Some troubleshooting recommendations: • Make sure your Linux audio system is working. Test speaker and microphone? Are you using Raspberry Pi BCM2835 internal sound or USB sound card? Check ALSA config file to ensure mic and speaker are configured OK? Try "speaker-test" and "arecord". Ensure microphone is “captured” (with alsamixer). • Before building talkkonnect, edit default “talkkonnect.xml” file to enable/ disable features you want in talkkonnect. This is also where you set connection info for your Mumble server. • It is very important that your physical GPIO wiring match with GPIO’s numbers specified in the XML config file. You can use any available GPIO pins you want, just make sure they are physically connected with buttons, led's or LCD and they do not conflict with each other or anything else. GPIO numbers in XML are BCM numbers. • Are you using a breadboard? Loose "Dupont" wires can create noise and lead to a crash sometimes. • You can build and run talkkonnect with target board option “PC” - no GPIO connections are needed. Try target board option “PC” in the “talkkonnect.xml”, as a sort of a “safe mode” to troubleshoot your build? You can then command talkkonnect with just the function keys. Press “Del” key for key definitions. • talkkonnect is muting speaker on the PTT (F8) press to minimize audio interference and feedback. This is working with amixer. Make sure alsa-utils are installed? Muting can also use "pactl" from pulseaudio utils, but this is not required. Talkkonnect runs very well with just ALSA. Depending on the sound card you use, output device can be named differently (Speaker, Headphone, Master or anything else). Check your exact output device name with "amixer", "aplay" or "alsamixer" and enter it in “talkkonnect.xml” for speaker muting to work. I hope some of these steps will help fix your build? Happy "talkkonnecting". Regards, zrdimetc.
Hi Sonic, sorry for the slow reply. Go get the latest code and then in the directory /home/mumble/gocode/src/github.com/talkkonnect/gumble/gumble there should be a file called audio.go try to change the settings in that file and recompile and see if it works. I have never tested on low bandwidth server, thank you for your kind feedback.
@talkkonnect I finally figured it out..
Comment out the following lines in client.go
Line 13 - "github.com/talkkonnect/gumble/gumbleutil" Line 214 - b.Config.Attach(gumbleutil.AutoBitrate)
Would be cool if Talkkonnect worked on both Low and High Bandwidth Mumble servers.
Thanks Sonic
Actually this isn't really a work around as it just forces Full bandwidth on a not full bandwidth server and ends up being very garble audio.
Any idea?
Sonic, As Suvir from talkkonnect said, you need to edit audio.go file. File location is /home/talkkonnect/gocode/src/github.com/talkkonnect/gumble/gumble if you installed talKKonnect as talkonnect user, or /home/mumble/gocode/src/github.com/talkkonnect/gumble/gumble if you installed talKKonnect as mumble user. ... const ( // AudioMaximumSampleRate is the maximum audio sample rate (in hertz) for // incoming and outgoing audio. AudioMaximumSampleRate = 48000
// AudioSampleRate is the audio sample rate (in hertz) for incoming and // outgoing audio. AudioSampleRate = 8000
// AudioDefaultIntervalMS is the default interval in milliseconds that audio // packets are sent at. AudioDefaultIntervalMS = 60
// AudioDefaultInterval is the default interval that audio packets are sent // at. AudioDefaultInterval = AudioDefaultIntervalMS * time.Millisecond
// AudioDefaultFrameSize is the number of audio frames that should be sent in // a AudioDefaultInterval window. AudioDefaultFrameSize = (AudioSampleRate * AudioDefaultIntervalMS) / 1000
// AudioMaximumFrameSize is the maximum audio frame size from another user // that will be processed. AudioMaximumFrameSize = AudioMaximumSampleRate / 1000 * 60
// AudioDefaultDataBytes is the default number of bytes that an audio frame // can use. AudioDefaultDataBytes = 40
// AudioChannels is the number of audio channels that are contained in an // audio stream. AudioChannels = 1 )
Audio sampling rate is set to 8000 Hz in this code. With the time interval set to 60 ms, talKKonnect will take 15-16 kBps of network bandwidth. Audio sampling rate wont affect your network bandwidth much, but it will affect CPU utilization. With 8000 Hz sampling, the CPU utilization on Raspberry Pi will be 15%. If you use 48000 Hz sampling, CPU use will increase to over 50 %. A good compromise between audio quality, network bandwidth utilization and CPU usage is 16000 Hz sampling and 60 ms timing.
Network bandwidth will be further decreased by extending the timing (less packet overhead). In this code timing is set to 60 ms. Next, try the timing of 80, 100, 120 ms and recompile talKKonnect after each change. At the same time, watch your resulting bandwidth with tools like "iftop" or "bmon"? Test with other talKKonnect clients or other Mumble clients, if such encoding results with workable audio? With high timing (120 ms) you will be able to drop network bandwidth utilization to 8-10 kilobytes per second. Dont use timing over 120 ms. Hope this helps. Regards, zrdimetc
Yeah I did change the option in audio.py but not to the settings that you suggested. This does work.. The other work around was to use dchote's gumble and gumbleutil
Thanks for the help :)
We noticed that audio encoded at lower sample rates from 48 kHz (24, 16, 12, 8), when using longer time intervals than 10 ms (20, 40, 60...), from the clients using gumble libraries, like talkiepi and talkkonnect does not work well with Plumble - and to a smaller extent, official Mumble client. What works perfectly is 48 kHz sound using 10 ms time. As soon as you start using longer time intervals for sound, audio is breaking up in Plumble - and to a smaller level - official Mumble. But at the same time audio is decoded near perfectly by other gumble-like clients with any sample rates / times. So for gumble to gumble communication any audio sampling rate / time intervals work, no issues. We think this problem is related to jitter buffering in Plumble. Gumble is also using auto bit rate option, based on server maximum bitrate (bitrate.go in gumbleutil). Unless a workaround can be found in Gumble or a jitter buffer/ decoding improved in Plumble (or official Mumble), communication between them and talkkonnect/ talkiepi with lower audio sampling rates and when using longer than 10 ms times (20, 40, 60 ms) will not work very well. On the other hand, 48 kHz sound with 10 ms works nearly perfect between talkkonnect/ talkiepi and any Plumble/ official Mumble clients. As soon as the time interval is extended over 10 ms, audio will start breaking up in Plumble/ official Mumble.
The breaking up between talKKonnect or talkiepi when using a lower than 48 kHz audio sampling (24, 16, 12 or 8) to talk to Plumble is caused by Jumble AudioHandler where SAMPLE_RATE is hard coded to 48 kHz. When the clients based on Gumble, like talKKonnect or talkiepi talk to each other, there are no issues with breaking up on any Opus supported audio sample rate. Decoding works near perfectly whether the clients use the same audio sampling rate or different. Breaking up between Gumble based clients and Plumble, when Gumble audio sampling rate is set lower than 48 kHz is caused by Plumble.
Hey guys,
Love this project.. Thank you for the time you have put into it..
I am having issues with transmitting to mumble on low bandwidth servers. The server I am using is 18kb/s and the program crashes when I hit F8 to transmit.
See Error Below
Talkkonnect does work on servers that have no bandwidth throttling
Any idea's how to get it working on low bandwidth mumble servers?
Thanks Sonic