Win 7 Optimisations

[mhaas]

Soundcheck,
you are avoiding the topic of this thread and still haven't given any reasons why server OS and cables between the server and the player would influence the SQ.
If, say, a flac file is downloaded from the other end of the world over the Internet directly to the player and then played, it would be preposterous to say that the type of the OS on the remote server and the conditions/type of the cabling, routers, switches etc on the path between the player and the remote server determine the SQ when the file is played. And streaming over TCP is similar to this non real-time "downloading a file".

[evdplancke]

"I know one thing, that I know nothing" (Ancient Greek: ἓν οἶδα ὅτι οὐδὲν οἶδα hèn oîda hóti oudèn oîda) said Socrates about Genuine Wisdom (see also http://en.wikipedia.org/wiki/I_know_that_I_know_nothing)

Don't want to judge who is wiser in this thread though I have my own opinion.

Bit perfect signal reconstruction before buffering is no doubt as far as TCP/IP takes care of it. But who can claim he has the knowledge to answer the following questions?

1) Why does some Ethernet cables have different throughput? Is this not related to the noise they are carrying on? What happens to this noise when it reaches the Touch? Can't he interfere in any way with the perfectly reconstucted signal in the signal path between the input buffer and the digital output?

2) Doesn't packet loss and retransmission, packet jitter, packet size, round trip delay,... cause CPU load that can in turn potentially cause interferences with the perfectly reconstucted signal in the same signal path?

The one who can give perfect and scientific answers to these questions can wisely claim that bit perfect data means perfect signal output. The others, if they think they are wise, should rather keep quiet... or experiment to see if they can find some factual evidence to sustain their claims.

Now I guess you can judge by yourself who I think is wiser

[soundcheck]

Boys.

It's weekend. Do me a favour.


I assume all you guys who hang around here are running a W7 server.
I also assume that you all got a pretty high quality stereo at home.
I also assume that you all run a Touch (hopefully not in the bathroom, otherwise you wouldn't hang around in the audiophile section).

3*Yes??? Ok. Now you go ahead.

Server:
1. Install TCPOptimizer with optimum settings (free of charge)
2. Install and Run Fidelizer (free of charge)

Touch:
1. Install my Toolbox. (Free of charge)

and listen. It's that easy.


I can't do more for you than that.


Enjoy.

[Jeff Flowerday]

Boys.

It's weekend. Do me a favour.


I assume all you guys who hang around here are running a W7 server.
I also assume that you all got a pretty high quality stereo at home.
I also assume that you all run a Touch (hopefully not in the bathroom, otherwise you wouldn't hang around in the audiophile section).

3*Yes??? Ok. Now you go ahead.

Server:
1. Install TCPOptimizer with optimum settings (free of charge)
2. Install and Run Fidelizer (free of charge)

Touch:
1. Install my Toolbox. (Free of charge)

and listen. It's that easy.


I can't do more for you than that.


Enjoy.

Been there done that. No difference in sound quality.

In fact I also did the complete opposite. I've worked the crap out of my server, with network copies and video data conversions. Again no difference in sound quality.

I can hear the difference between default priorities and your TT 3.0 priorities clear as day.

I'm running a wireless bridge to isolate the 5 other computers on my network from my touch.

[superbonham]

Boys.

It's weekend. Do me a favour.

[...]

Server:
1. Install TCPOptimizer with optimum settings (free of charge)
2. Install and Run Fidelizer (free of charge)

Touch:
1. Install my Toolbox. (Free of charge)

and listen. It's that easy.

I can't do more for you than that.

Enjoy.

I also have some suggestions to improve the audio quality:

1. Play some music on your squeezebox (does not have to be a Touch)
2. Get completely naked
3. Do a headstand
4. Balance two kiwis (fruits) on your bare feet (one each) - make sure that they are ripe but not too squishy
5. Enjoy the very audible improvement of the music reproduction

Cheers

superbonham

[Jeff Flowerday]

"I know one thing, that I know nothing" (Ancient Greek: ἓν οἶδα ὅτι οὐδὲν οἶδα hèn oîda hóti oudèn oîda) said Socrates about Genuine Wisdom (see also http://en.wikipedia.org/wiki/I_know_that_I_know_nothing)

Don't want to judge who is wiser in this thread though I have my own opinion.

Bit perfect signal reconstruction before buffering is no doubt as far as TCP/IP takes care of it. But who can claim he has the knowledge to answer the following questions?

1) Why does some Ethernet cables have different throughput? Is this not related to the noise they are carrying on? What happens to this noise when it reaches the Touch? Can't he interfere in any way with the perfectly reconstucted signal in the signal path between the input buffer and the digital output?

2) Doesn't packet loss and retransmission, packet jitter, packet size, round trip delay,... cause CPU load that can in turn potentially cause interferences with the perfectly reconstucted signal in the same signal path?

The one who can give perfect and scientific answers to these questions can wisely claim that bit perfect data means perfect signal output. The others, if they think they are wise, should rather keep quiet... or experiment to see if they can find some factual evidence to sustain their claims.

Now I guess you can judge by yourself who I think is wiser

You don't need scientific answers, just unplug the damn cable. By doing so you eliminate the possibility of 1) noise being injected, and 2) load on the CPU and ethernet hardware dealing with messed up TCP/IP transimssions, the data buffer is already full and past the ethernet and protocol stage, all the touch has to do is pass it on to it's dac or out to an external dac.

SBGK has clearly indicated that he hears no difference when unplugging the cable, yet the change of one priority on the server makes a big difference. So both point 1 and 2 are ruled out by SBGK's golden ears.

Personally unplugging the cable has no change in audio quality for myself either.

[chill]

I can't do more for you than that.

Oh. What about an answer to the question that might move this discussion along then?

So, in a blind test, do you think you'd be able to hear an improvement in the last 30 seconds of a track?

and I suppose that question should end "after pulling the ethernet cable out".


EDIT: ... or as Jeff puts it "just unplug the damn cable"!

[adamdea]

"I know one thing, that I know nothing" (Ancient Greek: ἓν οἶδα ὅτι οὐδὲν οἶδα hèn oîda hóti oudèn oîda) said Socrates about Genuine Wisdom (see also http://en.wikipedia.org/wiki/I_know_that_I_know_nothing)

Don't want to judge who is wiser in this thread though I have my own opinion.

Bit perfect signal reconstruction before buffering is no doubt as far as TCP/IP takes care of it. But who can claim he has the knowledge to answer the following questions?

1) Why does some Ethernet cables have different throughput? Is this not related to the noise they are carrying on? What happens to this noise when it reaches the Touch? Can't he interfere in any way with the perfectly reconstucted signal in the signal path between the input buffer and the digital output?

2) Doesn't packet loss and retransmission, packet jitter, packet size, round trip delay,... cause CPU load that can in turn potentially cause interferences with the perfectly reconstucted signal in the same signal path?

The one who can give perfect and scientific answers to these questions can wisely claim that bit perfect data means perfect signal output. The others, if they think they are wise, should rather keep quiet... or experiment to see if they can find some factual evidence to sustain their claims.

Now I guess you can judge by yourself who I think is wiser

As a matter of fact mate i think most of us were able to predict from the outset that you were about to do.
You are basically asking people to prove that unicorns don't exist, and indicating on top that you will only be satisfied by evidence from people who have seen (first hand)unicorns not existing.

Your implication is that people who believe in unicorns are wiser than those who don't. In fact the really wise people are the ones who spend their weekends building unicorn stables in case one drops in.

[Mnyb]

SBGK has clearly indicated that he hears no difference when unplugging the cable, yet the change of one priority on the server makes a big difference.

Apparently no problem claiming two mutually exclusive ideas at the same time .
And avoiding to see the logical conclusion this data provides.

Both these claims can not be true one must be false .

unplugging the cable is null test proving that the network/server providing ip packets has no influence over sq qed .

On the other hand anyone claiming that data in the buffer sound different depending on how it got there should apply to employment at TAS

[pski]

1) Why does some Ethernet cables have different throughput? Is this not related to the noise they are carrying on? What happens to this noise when it reaches the Touch? Can't he interfere in any way with the perfectly reconstucted signal in the signal path between the input buffer and the digital output?

Different cables have different ratings because they vary in materials and construction. High thru-put cables are not straight wires. They have very intricate loop-backs. This is done to allow smaller wires to carry high frequency signals without extensive cross-talk. Just take one apart to verify this. TCP/IP used to go only 10Mbs. As faster speeds were codified, wires had to get better. A Cat 4 cable may be able to carry 100Mbs a short distance but at longer distances physics steps in and retry rates limit thru-put. To carry TCP/IP at the highest speeds (and the distances set out in the specifications,) more carefully designed cable is necessary. "Noise" is an analog term. Since the derived data is digital, "noise" on the line is irrelevant. See #2.

2) Doesn't packet loss and retransmission, packet jitter, packet size, round trip delay,... cause CPU load that can in turn potentially cause interferences with the perfectly reconstucted signal in the same signal path?

No. Parity testing/reconstruction/request for retransmit operations are done in the NIC (network interface card.) The CPU doesn't know anything about it. When your O/S displays packet statistics, it has just asked the network card how things are going.

The one who can give perfect and scientific answers to these questions can wisely claim that bit perfect data means perfect signal output. The others, if they think they are wise, should rather keep quiet... or experiment to see if they can find some factual evidence to sustain their claims.

So, yes, bit perfect data does means the data that left the one end is the exact data received at the other.

p