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

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.

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.

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)

Yeah hence I mention the WAN. Generally some link along your WAN route is oversaturated, on a shitty ISP it's probably the link to your local ISP itself. I presumed audiophile switches would be popular for real-time streaming solutions, but I still don't understand the appeal.

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

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.

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.