If third party Mumble clients use other than 48 kHz sound, Plumble / Mumla is breaking up
Daniel, thank you for a great effort to bring Plumble back to life as a much improved "Mumla". There is an issue I would like to report. If Plumble and now Mumla are receiving Opus frames from other popular third party Mumble clients like talkiepi or talKKonnect which are based on Gumble and where the audio, if required, can be encoded with lower than 48 kHz sampling rate (24, 16, 12, 8), then Plumble and consequently Mumla audio will be breaking up very badly. Why would the users want to use different audio sampling rate and packet or frame sizes? To lower the CPU usage for instance. Or conserve the bandwidth. Audio input sample rate and packet size can be adjusted with a slider in Plumble/ Mumla, but currently they can not cope very well with the incoming audio where different from 48 kHz audio sampling is used. This seems to be related to "locking" of the audio sampling rate SAMPLE_RATE = 48000 and FRAME_SIZE = SAMPLE_RATE/100 in AudioHandler.java. AudioHandler file plays a role in both encoding and decoding of audio, together with AudioInput.java, AudioOutput.java and AudioOutputSpeech.java. As a workaround it would be great if Audio Sample Rate slider can be used for changing both the input and output audio sampling rate / frame size or if another slider for output can be introduced? If a SAMPLE_RATE in AudioHandler is changed to a value used for encoding the the audio on the side of third party client (24, 16, 12 or 8 kHz), then there are no issues with audio breaking up in Plumble / Mumla anymore. This is not an issue on the Gumble side. Audio between Gumble based clients is flawless with any supported audio sampling rates. There is a jitter buffer in AudioOutput. I am not sure if jitter buffer math was contributing anything to the problem. Thank you for considering a possible fix to this issue. A fix would allow users of Gumble based Mumble clients to talk to Mumla while conserving the bandwidth. Or make such clients perform much better on Raspberry Pi Zero by lowering the CPU usage (encode audio with a lower audio sampling rate).