Wireless vs Ethernet. Any sound quality differences?

[firedog]

I agree in theory there should be no difference.

When I was using a Duet and had only standard 16/44.1 files I used wireless and was perfectly happy.

On the Touch I've switched to wired. Main reason is that there were problems on my system with some skips and too much (re)buffering, mainly with hi-res files.

Since switching to wired about 99% of these problems have disappeared.

YMMV - on my setup it made a difference.

As far as sound quality, I "think" I hear a minor improvement with wired, but I may be imagining it. I'm not really interested in serious testing the respective SQs, as I'm staying with the wired for the reasons mentioned above. As a result I've also used the software mods to turn the wireless module off.

Is it not true that the wireless module can produce noise that could slightly degrade the SQ?

[mlsstl]

I agree in theory there should be no difference.

[snip]

On the Touch I've switched to wired. Main reason is that there were problems on my system with some skips and too much (re)buffering, mainly with hi-res files.

Since switching to wired about 99% of these problems have disappeared.

YMMV - on my setup it made a difference.

As far as sound quality, I "think" I hear a minor improvement with wired, but I may be imagining it....

The skipping and buffering problems are exactly what one would expect with a poor wireless connection.

Does anyone remember the old game of moving the rabbit ears on a TV set for the best reception? A few inches one way or the other could make a big difference in picture quality.

A wireless computer signal is still a radio wave. I had a very poor connection when I installed a Squeezebox Radio in the kitchen. After looking at the situation, I realized I had a washer/dryer sitting in the direct path between the router and the radio. Moving the router down two shelves solved the problem - the signal now ran under the washer/dryer.

As for the sound quality difference, I realize that some have come up with theories (i.e., when on, the wireless module contaminates the analog line section, etc.) but I try to follow Occum's Razor on such things. Subjective influences in humans, conscious and unconscious, are very well documented and in constant operation in our brains. I'd vote for that as the most likely to account for your perception, but then it's also OK. Whatever works to enhance your enjoyment of music is fine in my book.

[Phil Leigh]

Is it not true that the wireless module can produce noise that could slightly degrade the SQ?

Case not proven, as they would say in Scotland. It's a fine theory with no proof...

[Waldo Pepper]

A design flaw (IMO it's a flaw) in the Squeezebox architecture is that the buffer is only for the current track. At the start of a new track, all the players start refilling their buffers from scratch, so the system is more vulnerable to network trouble when a new song starts.

Not convinced about this. Marillion tracks on "Misplaced Childhood" 1 & 2 seem together timewise perfectly on the Touch just as they do on the CD.

Same with Roger Waters stuff.

[Phil Leigh]

Not convinced about this. Marillion tracks on "Misplaced Childhood" 1 & 2 seem together timewise perfectly on the Touch just as they do on the CD.

Same with Roger Waters stuff.

All tracks play gaplessly because...as AndyG said
"Not quite, the next track begins buffering 10 seconds before the current track ends."

[JJZolx]

All tracks play gaplessly because...as AndyG said
"Not quite, the next track begins buffering 10 seconds before the current track ends."

And also this is how crossfade between tracks is possible.

[JohnSwenson]

And also why skipping while in the middle of a song can cause problems. When going to the next song in a playlisy it is prefetched so there is already data in the local buffer when the previous song ends, when you push the skip button there is no prefetch, you have to sit and wait while the server opens the file and sends a buffers worth of data to the player.

John S.

[JJZolx]

And also why skipping while in the middle of a song can cause problems. When going to the next song in a playlisy it is prefetched so there is already data in the local buffer when the previous song ends, when you push the skip button there is no prefetch, you have to sit and wait while the server opens the file and sends a buffers worth of data to the player.

What exactly is the problem?

Pressing the skip button will skip to the next song, which may or may not be partially in the buffer. If the start isn't in the buffer then you wait while it _begins_ to fill the buffer sufficiently to allow playback. Skipping twice or more in quick succession guarantees that you'll wait. Depends on your network speed, but on mine the wait is never more than 1-2 seconds.

Is that what you're calling a problem?

[JohnSwenson]

My understanding of this is that when skipping, the full large buffer is not filled up all the way right at the beginning, primarily to cut down on the time the user has to wait before music starts playing. Unfortunately this also means that its possible for that small buffer to run out of data before the next buffer gets filled up, thus causing the infamous stuttering. This is more probable if 24/96 files are being played or TinySBS is being used or if using a not so great Wifi connection.

This also why I think you hear some people talking about things work fine except for the first song out of a playlist. That first song doesn't have a prefetch and is probably using the "short buffer" right at the beginning, thus increasing the probability of getting a stutter.

John S.

[JJZolx]

My understanding of this is that when skipping, the full large buffer is not filled up all the way right at the beginning, primarily to cut down on the time the user has to wait before music starts playing. Unfortunately this also means that its possible for that small buffer to run out of data before the next buffer gets filled up, thus causing the infamous stuttering. This is more probable if 24/96 files are being played or TinySBS is being used or if using a not so great Wifi connection.

This also why I think you hear some people talking about things work fine except for the first song out of a playlist. That first song doesn't have a prefetch and is probably using the "short buffer" right at the beginning, thus increasing the probability of getting a stutter.

Ah, right. Is this pre-buffering set to a fixed amount in the code, or is it a pref somewhere? You're right, starting playback after prebuffering 3 seconds of 24/96 FLAC on a marginal wireless network is totally different than prebuffering 3 seconds of a 128 kbps Mp3 on a 100 Mbps wired network.

I know that in most streaming video players this is a configurable setting, as setting it too low means you get the stuttering you speak of. I don't know that I've seen such a setting for Squeezebox Server.