If the audio playback programs are coded correctly, this does nothing. If the music is playing and is continuous, it doesn't matter how the data comes to you. Here's why.
CD player motors can be horrible for audio quality, but it's still digital. Why? It's because the 1s and 0s get buffered into RAM, which will smooth it out. Once it's in RAM, it's solid state. In terms of audio streaming software, if the RAM buffer is large enough, then it doesn't matter if the packets come in at a sporadic pace. If the source audio is streamed faster than the playback pace, which is very easy to do, if your connection is stable, you can write the software to where there's no lag once it starts playing.
You can probably make a really precise CD player motor, but the reality is that the motor has to compete with the likes of 256 megabytes of RAM, and that RAM would probably be much cheaper than a precise CD player motor. I suppose I digressed there, but still, if you can store 1/3 of the CD into RAM, then you can have a really crappy motor as long as it's fast enough
If you have a program coded like I mentioned, if your connection is stable enough, then this Ethernet switch won't do anything, especially if have a large RAM buffer. Also, streaming often uses compression, so that shrinks the needed RAM buffer. 100 megs of RAM is enough for around a 4 minute FLAC file at 24/96. Most audio formats also have built-in checksumming