[ChymeraXYZ]

Yeah, no because "streaming" is just transferring a chunks that can then be played. You are not sending bits from the network card straight to the audio out. Even if you have a certain % packet loss, there is 0 impact on the playback as long as the next chunk arrives before the previous one has finished.

[eurasiantiger]

Read this.

https://en.wikipedia.org/wiki/AES3

[imtringued]

That is a protocol specifically designed to accept input from audio devices like microphones, etc and output directly to audio devices like speakers.

To do the same with ethernet you would have to use an industrial ethernet implementation of which I know at least three and they are all incompatible with each other and even then you would most likely benefit from an audio focused implementation.

All of this is much harder than just buying a better switch and claiming it improves the sound. Your audio playback device and speaker would have to support the same implementation of industrial internet.

[m463]

You know, streaming isn't really just getting bits across the wire intact.

For one thing, timing is important. A simple example would be getting video in sync with audio. You could go deeper and manage timing for speakers side to side or front to back. It would get lots harder if a microphone was introduced - then latency would be a big big deal.

These sorts of things are probably why bluetooth isn't used as much with a/v systems.

(lol, here I am arguing the merits of an audiophile network switch)

[com2kid]

> 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.

[brokenmachine]

>You could go deeper and manage timing for speakers side to side or front to back

Audio data frames are interleaved, ie RLRLRL. There's no point managing timing of network packets because after going over the network, all the data goes into a buffer at the other end before being played.

[fsh]

The timing is determined by the sample clock of the DAC. The network switch has zero influence on it. If the system has multiple DACs and/or ADCs, their clocks can usually be synchronized via BNC cables.

[berniedurfee]

But it’s all buffered at a bunch of different places though, right? There must be a stream buffer before the DA to compensate for any upstream latency, no?