I’m using TCP to transmit audio packets to my ESP32 device.
On GCD, I receive packets of ~5k bytes and it all works fine, but on Fly.io, the packets are ~1kB. More packets seem to slow things down and the voice that is played has ‘clicks’ or ‘cracks’ in it, if not blanks. I traced it down to the speaker buffer getting empty.
Can anyone tell me if I can setup the MTU in my python code somehow? or in the fly.toml?
Thanks
Hi there,
A Fly machine is just a Linux VM; you can install ip and use that to change the MTU.
That said - it probably won’t help much if you change the MTU in your machine’s interface, as there are a few other hops along the path to any client that probably have a lower MTU for other reasons, and even the ones that are under our control can’t be user-changed (nor can we tune it on request - actually the current values have been carefully tuned as required by our network and stack so it’s not just a knob we can tweak). Larger packets will get fragmented at those hops anyway.
Cheers,
One thing to note here is that usually one can’t really expect an MTU of anything over 1500 when transmitted over the internet. I don’t know how it worked on other cloud platforms for you, but the moment anything goes over the internet, 1500 is the best you can hope for.
I’d suggest looking at what exactly is causing the audio cracks – TCP is just a data stream and the underlying MTU shouldn’t have that much of an effect on its throughput unless we’re talking about very high bandwidth here. TCP also has no concept of “packets” to speak of and forwarding nodes (like our fly-proxy) are free to buffer data however they see fit, which means that the sender also cannot expect data buffers to arrive exactly as they were written (i.e. “packets” can be split, or merged together, or arrive with different pacing). If your application is sensitive to this kind of changes in the data stream, UDP is likely a better choice.