Fidelizer & SBT.. Why should it work?

[Audio Bling]

I recently installed Fidelizer on my Win7 server PC (LMS installed) and I hear a definite improvement in SQ. I am thinking that this should not be the case as the SBT buffers incoming data. One assumes that the data itself is not affected by Fidelizer. So what's going on?

Please note: I am not interested in hearing from the “LOL, you can’t possibly be hearing a difference” chorus. Post elsewhere if that is your (only) response.. Rather, I am interested in thoughts as to why Fidelizer (or any server OS optimisation) could help SQ on the SBT..

Two possibilities (to start):

1. Without Fidelizer, the unoptimised server is working “harder” than otherwise and is generating more RFI/EMI that is being transmitted to the SBT. The SBT is an “aerial” that picks up RFI/EMI and this negatively effects SQ.

2. With Fidelizer, the optimised server is better able to attend to the SBT’s buffer requests. It keeps the SBT in a “happier” state so that it is able to do its core work (audio processing) with fewer / more uniform CPU cycles which positively effects SQ.

Note: I am not in a position to test these possibilities. I don’t necessarily think they are the “answer” but offer them nonetheless.. I am curious to know what others may have to contribute. The idea that the LMS server is somehow able to impact the SBT runs counter to the “three-box” design philosophy that is considered optimal for PC music playback. The idea being that the player PC (in this case the SBT) is relieved of as much “heavy lifting” as possible and merely attends to serving the DAC to which it is attached. But if the server PC has an impact on SQ (as it seems to) then one may fairly ask: What’s the point; why not revert to a two-box architecture: Player PC & DAC?

Regards,

Win7 (64bit) > (ethernet) SBT > DAC >..

[SuperQ]

The answer is: Expectation Bias

[SBGK]

The answer is: Expectation Bias

to quote soundcheck - 'everything affects the sound'

fidelizer sets the system timer to 15 ms

fidelizer adjusts non essential processes to low priority

does some other things

so basically it is optimising windows so there is less contention for resources when running lms and less noise

the difference between non fidelizer and fidelizer extreme mode should be apparent, even to SuperQ's ears

[chill]

The answer is: Expectation Bias

SuperQ - you're not allowed to say this. The OP has made it clear that you're only allowed to post conjecture that reinforces his expectations. I'm surprised he let you get away with this.

[Mnyb]

SuperQ - you're not allowed to say this. The OP has made it clear that you're only allowed to post conjecture that reinforces his expectations. I'm surprised he let you get away with this.

OP says .

"Please note: I am not interested in hearing from the “LOL, you can’t possibly be hearing a difference” chorus. Post elsewhere if that is your (only) response.. Rather, I am interested in thoughts as to why Fidelizer (or any server OS optimisation) could help SQ on the SBT.."

Of course he can hear a difference nobody doubts that ,it is just that it does not happen in the realm of data acoustic or electricity . As these server tweaks does not change anything at the Touch end it still buffers the same data the signal remains the same .

You can always hear differences , SuperQ just suggested the most plausible mechanism that makes fidelizer do that for squeezeboxes ( it may very well work for some issues in pc playback on that I have no opinion ) , so it actually answered the question ? Without LoL

[chill]

You can always hear differences , SuperQ just suggested the most plausible mechanism that makes fidelizer do that for squeezeboxes ( it may very well work for some issues in pc playback on that I have no opinion ) , so it actually answered the question ? Without LoL

You make a good point. I stand corrected.

So do you think the OP is interested in the THE simple test that will demonstrate that SuperQ's suggested mechanism is the correct one? You know, the 'just pull the plug' test.

[JohnSwenson]

You make a good point. I stand corrected.

So do you think the OP is interested in the THE simple test that will demonstrate that SuperQ's suggested mechanism is the correct one? You know, the 'just pull the plug' test.

But that test is not necessarily defintive, it only tells you if the processing on the Touch is the issue. There are other possible paths from server to ears such as EMI radiated from server, noise injected on power mains etc. Something which is changing the whole operating environment of the server COULD be changing something which gets transfered through one of these indirect paths, even when audio data is not actively being transmitted to the Touch. Now if you unplugged the the Touch from the ethernet AND unplugged the power form the server at the same time, THEN you would have a more convincing test.

John S.

[SBGK]

But that test is not necessarily defintive, it only tells you if the processing on the Touch is the issue. There are other possible paths from server to ears such as EMI radiated from server, noise injected on power mains etc. Something which is changing the whole operating environment of the server COULD be changing something which gets transfered through one of these indirect paths, even when audio data is not actively being transmitted to the Touch. Now if you unplugged the the Touch from the ethernet AND unplugged the power form the server at the same time, THEN you would have a more convincing test.

John S.

with my large buffer settings I can get several minutes playback of 16/44.1 stored on the touch after the music has loaded via the ethernet. So I can switch off the laptop and disconnect the ethernet while the music is still playing - the sound doesn't change when I do this, it does change if I use fidelizer, that is good enough proof for me that fidelizer works.

[Triode]

with my large buffer settings I can get several minutes playback of 16/44.1 stored on the touch after the music has loaded via the ethernet. So I can switch off the laptop and disconnect the ethernet while the music is still playing - the sound doesn't change when I do this, it does change if I use fidelizer, that is good enough proof for me that fidelizer works.

That's impressive - as you can get say 3 seconds worth of buffering from the tunable alsa buffer (usb interface), 10 seconds from the output buffer and then the main buffer (pre decoding) is 3 Mbytes in size. Several minutes would only work if you are listening to very compressed music?

[Mnyb]

with my large buffer settings I can get several minutes playback of 16/44.1 stored on the touch after the music has loaded via the ethernet. So I can switch off the laptop and disconnect the ethernet while the music is still playing - the sound doesn't change when I do this, it does change if I use fidelizer, that is good enough proof for me that fidelizer works.

That's impressive - as you can get say 3 seconds worth of buffering from the tunable alsa buffer (usb interface), 10 seconds from the output buffer and then the main buffer (pre decoding) is 3 Mbytes in size. Several minutes would only work if you are listening to very compressed music?

The practical buffer time seems to be 30s on an unmodded unit with 16/44.1 music

But if one can hear a difference in already buffered data on the player side , that actually leaves two explanations .

Expectation bias and that fidelizer is broken and corrupts data ?