Difference between WiFi and Ethernet

AndyB said:
For airplay speeds see the Youtube video 'Apple Airplay's Audiophile Easter Egg'.
Click to expand...
Just a thought, are you confusing using a cable from an iPhone, say, into a DAC as Ethernet, compared to using WiFi without any cables?
 
From everything written above, I’m really now interested in who this Bob Dylan is??? Prince? Cut this knot, I won’t be able to sleep!
 
Brantome said:
Well, you still haven’t explained where you get the notion that wired or wireless figures in your quoted evidence…🤷🏻‍♂️
Click to expand...
If I have an alac file of cd quality on my laptop, I can send it to my wiim amp either using an ethernet cable, or via wi-fi. If I send via wi-fi, airplay may compress the file.
 
AndyB said:
If I have an alac file of cd quality on my laptop, I can send it to my wiim amp either using an ethernet cable, or via wi-fi. If I send via wi-fi, airplay may compress the file.
Click to expand...
If your laptop is connected via Ethernet and your Amp is connected via WiFi, do you send the stream via WiFi or via Ethernet?
 
Steve Woodhouse said:
It’s easy to be persuaded that a digital signal passing over power line will inevitably be corrupted.

But if your instincts were correct, then every time someone turned something on that’s really noisy, like a vacuum cleaner or microwave oven your music would become unlistenable.

People transfer terabytes of data over power line and the end product is bit-for-bit identical with the source.
Click to expand...
Agreed...depending on where you are in the physical and software stack.

But, let's look a real world example from one of my Linux servers (same operating system as WiiM boxes) rather than hand-waving.

Receive errors do occur even on what we would think of as pristine environments. Those 13 packet drops (RX-DRP column) out of 62.25 million received packets (RX-OK column) are real and obviously measurable. Its cabling is completely wired 1Gbps Ethernet but still has some bumps because of physics.

1719002077644.png

Did it cause a non-recoverable software problem? -- probably not. If it was a packet in an audio stream, it would have been a dropped bit of the audio stream since the packet was dropped by the operating system well before the audio application received it. Any single packet would just be a intantaneous glitch in the audio (a few milliseconds) which you'd barely notice. Audio doesn't get re-sent since it's a continous stream -- what would you do with a late arriving bit of out-of-sequence audio? We get packet drops on cell phone calls all the time and everyone just powers through them except when they occur in large bunches. Somewhere deep inside your WiiM box, these same packet errors are logged.

Anyway, pulling out of the rabbit hole 🤓
 
hoohoohoo said:
Agreed...depending on where you are in the physical and software stack.

But, let's look a real world example from one of my Linux servers (same operating system as WiiM boxes) rather than hand-waving.

Receive errors do occur even on what we would think of as pristine environments. Those 13 packet drops (RX-DRP column) out of 62.25 million received packets (RX-OK column) are real and obviously measurable. Its cabling is completely wired 1Gbps Ethernet but still has some bumps because of physics.

View attachment 8273

Did it cause a non-recoverable software problem? -- probably not. If it was a packet in an audio stream, it would have been a dropped bit of the audio stream since the packet was dropped by the operating system well before the audio application received it. Any single packet would just be a intantaneous glitch in the audio (a few milliseconds) which you'd barely notice. Audio doesn't get re-sent since it's a continous stream -- what would you do with a late arriving bit of out-of-sequence audio? We get packet drops on cell phone calls all the time and everyone just powers through them except when they occur in large bunches. Somewhere deep inside your WiiM box, these same packet errors are logged.

Anyway, pulling out of the rabbit hole 🤓
Click to expand...
Audio streaming is buffered so is that really true?
 
onlyoneme said:
If your laptop is connected via Ethernet and your Amp is connected via WiFi, do you send the stream via WiFi or via Ethernet?
Click to expand...
If the ethernet is disconnected, transfer can take place by wi-fi. If ethernet is connected the amp either automatically opts for transfer by ethernet or it can be selected manually.
 
AndyB said:
If the ethernet is disconnected, transfer can take place by wi-fi. If ethernet is connected the amp either automatically opts for transfer by ethernet or it can be selected manually.
Click to expand...
This is not an answer to the question. :)

Sticking to how, why and when AirPlay 2 uses lossy compression is still not relevant to this discussion. This is about Wi-Fi vs. Ethernet.

Just forget AirPlay and imagine Google Chromecast instead.
 
Last edited:
slartibartfast said:
Audio streaming is buffered so is that really true?
Click to expand...
Good question @slartibartfast. Apologies for the long response, but hopefully the context helps frame how the pieces fit together.

The buffering that you're thinking about is a receive-side function where packets are being marshalled and put into the proper sequence or order (there's a sequence number in the RTP header of the audio datagram to do this). The burstiness from the transmit side is smoothed out to remove the jitter from the variances in the inter-packet arrival times. The receive side buffer will then de-queue the packets to the audio player function. The buffer is normally some percentage full and this helps the streaming audio to be continuous without noticeable delays, shudders, or pops.

I think what people are confusing is 'reliability of delivery' and thinking that audio streams are always reliable like a file transfer. A file transfer that @Steve Woodhouse raised doesn't have any timing constraints on it like audio does. With audio, the packets have to arrive quickly or the buffer that was mentioned above can end up with no packets in it. So, a file transfer has the luxury of time and can use more reliable delivery (hey, did you get my message? No, then I'll resend it) where audio is often sent more like a fire-and-forget (hey, I just sent a message and hope that you got it).

One can absolutely build a 2-way reliable delivery of audio but you have to make assumptions about the network while respecting the need to be timely. Here, we could compare a 1-hop delivery on a LAN vs the multihop delivery over the public internet. To the user, reliable delivery can come at the cost of continuous audio which would make them hit the return item button on Amazon. These are choices that the designer of the 2 sides of an audio application makes because someone's mom can't make that choice. So, servers like Plex or Emby or LMS can use reliable delivery on your 1-hop broadcast LAN. But when you're building a massive internet service, the cost of building and operating a service to manage and operate 2-way reliable communications with tens of thousands of music players at scale is non-trivial. I've been leaning more into this internet service item than the LAN in my comments.

When the audio is put into the receive-side buffer, if it never actually got there, there's a tiny gap (a few milliseconds) in the audio stream. If you're at the edge of radio range with WiFi, for example, then there would definitely be instances where the packet (or more likely, several packets in a row) just doesn't get there as there are limits even on what is considered 'reliable delivery'. (Hey did you get my message? Silence because the receiver can't hear the sender. When they move too far away, even if the receiver is saying I didn't get your message, the sender can't hear the intended receiver's response)

If you have more questions, please ask away.
 
hoohoohoo said:
Good question @slartibartfast. Apologies for the long response, but hopefully the context helps frame how the pieces fit together.

The buffering that you're thinking about is a receive-side function where packets are being marshalled and put into the proper sequence or order (there's a sequence number in the RTP header of the audio datagram to do this). The burstiness from the transmit side is smoothed out to remove the jitter from the variances in the inter-packet arrival times. The receive side buffer will then de-queue the packets to the audio player function. The buffer is normally some percentage full and this helps the streaming audio to be continuous without noticeable delays, shudders, or pops.

I think what people are confusing is 'reliability of delivery' and thinking that audio streams are always reliable like a file transfer. A file transfer that @Steve Woodhouse raised doesn't have any timing constraints on it like audio does. With audio, the packets have to arrive quickly or the buffer that was mentioned above can end up with no packets in it. So, a file transfer has the luxury of time and can use more reliable delivery (hey, did you get my message? No, then I'll resend it) where audio is often sent more like a fire-and-forget (hey, I just sent a message and hope that you got it).

One can absolutely build a 2-way reliable delivery of audio but you have to make assumptions about the network while respecting the need to be timely. Here, we could compare a 1-hop delivery on a LAN vs the multihop delivery over the public internet. To the user, reliable delivery can come at the cost of continuous audio which would make them hit the return item button on Amazon. These are choices that the designer of the 2 sides of an audio application makes because someone's mom can't make that choice. So, servers like Plex or Emby or LMS can use reliable delivery on your 1-hop broadcast LAN. But when you're building a massive internet service, the cost of building and operating a service to manage and operate 2-way reliable communications with tens of thousands of music players at scale is non-trivial. I've been leaning more into this internet service item than the LAN in my comments.

When the audio is put into the receive-side buffer, if it never actually got there, there's a tiny gap (a few milliseconds) in the audio stream. If you're at the edge of radio range with WiFi, for example, then there would definitely be instances where the packet (or more likely, several packets in a row) just doesn't get there as there are limits even on what is considered 'reliable delivery' because the receiver can't hear the sender. When they move too far away, even if the receiver is saying I didn't get your message, the sender can't hear the intended receiver's response)

If you have more questions, please ask away.
Click to expand...

Excellent post.

But if one packet isn’t arriving with an average connection, then regular packets must be going AWOL with a poor connection, and multiples with a bad connection. Presumably several packets together as the quality waxed and wains.

Whilst you’d certainly not miss one (a few milliseconds, as you say), you’d surely hear several together.

But we never hear this, even people who have the worst connections.

And as Brantome has said, this would exhibit itself by a literal gap in the music, not in a change in frequency response, noise, distortion, soundstage, etc.

By the way, there’s one slight inaccuracy in your otherwise excellent post. Yes indeed, streamed music is listened to ‘live’ as it were. Whilst a word doc’s transfer can be repeated, etc., until it’s right, if you’re listening to streamed music it can’t be. There’s no luxury of time.

But here’s the thing. When streamed music being listened to live is also simultaneously stored (so not like just transferring the file), these issues never show up, apart from with abysmal connections which quite clearly keep dropping out for large portions of seconds.

I’ve seen a few tests of streamed music, and as long as the file is good enough to play, it’s identical to what was transmitted.
 
What’s missing from this discussion is redundancy and forward error correction. Actual listening tests using these protocols indicate that most people find music listenable with 10 percent packet drop, the real life packet loss number is probably lower than 0.0001 percent.

Silence is not the only available option to deal with packet loss. A protocol with redundancy can fill in those couple of milliseconds with the correct music, but maybe lower bit rate.

A system with forward error correction may be able to to reconstruct a perfect stream.

But failure is going to be noticeable as stuttering or dropout, not as distortion.
 
Well it is about a year now with my Wiim Pro Plus. Im extremely happy with this little device. It scales beautifly with simple linear power supply and couple of furutech power cords in my system. But to take advantage of that and actually hear that scalling with upgrading power cords and power supply I would strongly advice to switch to ethernet connection as it simply sounds clearer and more transparent and upgrade ethernet cable. In my case it is Supra. Ohhh and one more thing... quite important to. Good quality switch between router and streamer powered with some cheap linear power supply. I got D-link dgs 108. Cheers!
 
Steve Woodhouse said:
Excellent post.

But if one packet isn’t arriving with an average connection, then regular packets must be going AWOL with a poor connection, and multiples with a bad connection. Presumably several packets together as the quality waxed and wains.

Whilst you’d certainly not miss one (a few milliseconds, as you say), you’d surely hear several together.

But we never hear this, even people who have the worst connections.

And as Brantome has said, this would exhibit itself by a literal gap in the music, not in a change in frequency response, noise, distortion, soundstage, etc.

By the way, there’s one slight inaccuracy in your otherwise excellent post. Yes indeed, streamed music is listened to ‘live’ as it were. Whilst a word doc’s transfer can be repeated, etc., until it’s right, if you’re listening to streamed music it can’t be. There’s no luxury of time.

But here’s the thing. When streamed music being listened to live is also simultaneously stored (so not like just transferring the file), these issues never show up, apart from with abysmal connections which quite clearly keep dropping out for large portions of seconds.

I’ve seen a few tests of streamed music, and as long as the file is good enough to play, it’s identical to what was transmitted.
Click to expand...
@Steve Woodhouse Thanks for the kind words. You're absolutely right here. When we model a communications connection, it tends to stay in one state (i.e. on/working or off/broken) for a period of time. If you're out of WiFi range, you're not missing just one packet, you're missing a whole bunch all in a row. And as Brantome said, it is a literal gap where all those milliseconds accumulate into a very noticable gap. The math is a Markov chain (https://en.wikipedia.org/wiki/Markov_chain) --> "it is a process for which predictions can be made regarding future outcomes based solely on its present state and—most importantly—such predictions are just as good as the ones that could be made knowing the process's full history".

About time though, time is relative. For audio streams, we're talking about milliseconds of time and keeping a constant stream where for a file, if it takes 5 seconds or 10 seconds longer to deliver a gigabyte file, nobody cares. But, yeah, if it was going to take 10 minutes or 1 hour to transfer 1 gigabyte, say, my credit card is popping out to get a better solution :)
 
You must log in or register to reply here.

Similar threads

S
Issue with ultra just stopping mid song.
Replies
5
Views
390
monaco28
M
R
  • Article
difference between wiim pro and pro plus while streaming
Replies
18
Views
7K
Mr Ee
Mr Ee
H
Clicks and pops Wiim pro (Fixed: RF interference)
Replies
8
Views
1K
Musician
M
L
One week experience - Review (updated after a month)
2
Replies
24
Views
2K
simbun
S
P
Wiim Ultra instability
2 3
Replies
52
Views
3K
Zphvrq
Z
Back
Top