|
|
|
|
|
by com2kid
1194 days ago
|
|
> For one thing, timing is important. So long as the amount of audio sent in a packet is larger than how long it takes the next packet to get there, you'll be transfering audio data faster than it is playing, making minor fluctuations in timing between packets irrelevant. Bluetooth isn't used because BT audio transmission is lossy, audio gets recompressed. Newer BT standards have good quality compression, but you are still recompressing the audio. BT isn't meant to be a high bandwidth protocol. BT's latency around audio is because 99% of BT implementations suck. Latency can be as low as 50ms or so, but it is often in the 100s or even 200s of ms. |
|
Even major fluctuations. Not talking about the quality here (but the received quality is identical to what is being sent), but just think about Netflix & Co, Imagine if they had to maintain an "ideal network, with no packet loss and constant ping" to your device or otherwise audio and video would be out of sync?
There are protocols that shuffle more or less raw audio streams over the network (Dante for example). In that case yes, you do things to make sure the variables are within a certain range by (usually) segregating the traffic etc, but even then if the timing is off the playback will stop until the stream is reestablished properly. Theoretically it's the same as with any other media stream, just much more sensitive to fluctuations as it is real time (i.e. delay so low you are unable to hear it).