pymumble
pymumble copied to clipboard
Add UDP Media Support
Hello,
This library is great, however I get occasional hitching in the audio when using it. I suspect this is due to the use of TCP for the audio stream. UDP is much better at handling imperfect networking conditions for media streams, it would be worthwhile to implement this and use it by default, with only fallback to TCP as the Mumble client does.
Hi. It is a topic I've try a lot. There are a specific branch for UDP testing. I didn't manage to make it work for now. Most of the time, my bot are in the same server as my murmur, so I don't have any issue with that.
Currently, mumble uses an outdated encryption algorithm called AES-OCB2 for UDP transmission. We can not find a python library that is usable to perform this encryption. This is the primary reason why the development of UDP transmission of many mumble libraries has stalled.
There's a plan in mumble's roadmap regarding adding new ciphers and new protocols in https://github.com/mumble-voip/mumble/issues/3918, https://github.com/mumble-voip/mumble/pull/4238, and https://github.com/mumble-voip/mumble/pull/4299, but I think based on my observation, we can't expect new ciphers to be added in mumble 1.4.0.
Hello azlux, you have any plans to implement UDP with pymumble? Its a nice library to used on same device with the murmur server. But on external device from server the Audio is broken
But still good work! Thumbs up
A big change is comming into the mumble dev branch, mumble will have voice over protobuff, it will be easier for us to implement the UDP protocol
this sounds good maybe this lib has udp support this year?
any updates on this?
Good question @VSuc If pymumble will support UDP it will be so nice. I hope that @azlux find a solution
I think #82 actually provided a usable OCB2 implementation, but I haven't tested it yet. There was one pure python implementation of OCB2 in the past and we tested it in 2020. The result was very poor (too slow to keep up with the audio stream and the CPU was at 100%). #82 used pycryptodome so there is a chance it can run much faster. But I doubt how much CPU it will eat up... At this moment, just keeping the audio stream running consumes a significant fraction of CPU.