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

[eurasiantiger]

No, it’s more — AES67 is a network audio routing protocol using Ethernet frames. Some variations such as Dante can use normal RJ-45 Ethernet gear.

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

[ChymeraXYZ]

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

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

[vinay_ys]

192khz/32bit audio track is 6.144Mbps. Assuming smallest data packet, at 64 bytes data per packet that's 12kpps. Any switch that has more bandwidth per port, more total non-blocking switching and forwarding rate that the sum of each port in use will suffice. These days, you would definitely go for gigabit non-blocking switches which have <1ns inter-packet gap and way too much bandwidth and forwarding rate than what your PCM stream needs.

[com2kid]

> 192khz

Please don't. You'll make Nyquist sad. https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

On its way to your speakers, a audio file sampled at 192khz will ideally be identical to a recording done at 44.1khz, except over sampling can introduce audio artifacts that degrade audio quality so you can end up with worse audio.

So, please, don't unnecessarily over sample.

[Karrot_Kream]

If you're talking about a general WAN, there's no guarantee that jitter on your route may not violate 12kpps, and it's quite common on most oversubscribed ISPs to stutter receiving 6.144Mbps due to occasional high latency causing a missed packet window (oversimplifying here because there are audio receive buffers as well.) Over a LAN this would only happen if you're pushing your switch to the limit.

Should you buy an audiophile network switch? God no.

[vidarh]

But this only matters either if you don't have enough bandwidth to compensate and a buffer, or for whatever reason can't buffer much (e.g. it's live and two-way)

[fizzynut]

The larger the buffer size, the larger the latency. This is mostly irrelevant for playing an audio file, but in some cases a long chain of buffers in the OS before it leaves to the speaker can be an issue for music.

The main place you will see this issue is playing audio in something like a video game due to an action like pressing a button, firing a weapon, etc then it can be very noticeable if you're buffering too much audio because it wont sync to what you're seeing and the game will feel laggy even if it's running at a high frame rate.

[imtringued]

I can encode video in real time and send it a hundred kilometers with lower latency than Bluetooth can send 192kbps of data to my ear.

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

[m463]

What if you have multiple dacs (and other types of conversions)?

Excepting subs, it seems many speaker systems are hardwired together downstream from the dac, but there should be a good way to have multiple independent speakers networked together that could be time consistent. and audio <-> video consistent with whatever display you have.

and bnc cables.... would be another whole network.

[scoutt]

Sorry but you keep talking about timing. With network speeds nowadays, the audio files get completely or almost completely buffered in the PC from whatever source you are reading it (NAS for example), and then played. Same with video (even when it doesn't buffer the entire video). And video/audio frames are interleaved.

Is not that every packet is "output" as soon as it arrives to the PC.

Or I didn't understand what are you saying.

[m463]

As an example, let's say you're playing a video.

A playback device creates a stream of audio and video data that is consistent and together. But if there's a network involved, say you have stereo wifi speakers, then the video and audio streams are separated. Maybe the playback device sends the data to the display using hdmi, and that device sends data over the network to the speakers. Now there are two delays - one for decoding and presenting video, and a second separate one for transmitting and then decoding audio. The second one is variable depending on the network.

[scoutt]

These are old and solvable problems (audio sync). For example I'm using HDMI ARC to output the audio of my TV, and the TV has a menu to coordinate video/audio (by inserting a delay). In my case I don't need it.

But it's delay, and not integrity of the data being played back. If the network sucks and there are retransmissions, your data might still be integrous without loses (depending on the protocol).

It also happens for musicians on stage. They play and after some delay they hear their own sound back. So they use monitors to hear themselves and the rest of the band.

While in lockdown people gathered together to play music with special software. That tells you something about how this problem is well known and how it can be solved in every situation.

[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?