[AlanHell]

I have seen many forms that claim to have an "optimized" version of foobar for better sound. Or have a "optimized OS" for music playback.
In order to know that the "optimization" is not done via some EQ buried deep-down in the process, I'd like to seek some method to compare the raw PCM of a file and the actual output PCM from the PC.

Since I am not an expert, I want to learn how software optimization is able to affect the digital domain of an DAC via asynchronous transmission?
And why it can make the sound more extend with darker background?
How it is able to reduce jitters without using external clock in synchronous transmission mode (I2S)?
How is it able to reduce USB power interface on the DAC's input?

For now, the only way for me to validate the software is legit is to first hear the sound difference between 2 software. Then make sure the PCM signal output from my foobar is the same as the source material decoded directly from reference decoder. Only when these two are true, I can trust the improvement is done via clean up the system instead of other digital wizardry.(upsamplying, DSD conversion, EQ, etc.)

Any one have good idea how to do it properly?

 

[PurpleAngel]

I like using Foobar2000, with WASAPI installed, for music audio.

 

[AlanHell]

I like using Foobar2000, with WASAPI installed, for music audio.

Me too, I use ASIO instead though.
However, they are many mod exist on different forms. Since I am stuck at home and super bord due to pandemic, I'd like to run some investigations on those "optimized" versions.

 

[Roseval]

It is called null-testing.

A relative simple one is testing for bit perfect output, no DSP is going on.
In this case you have a file, play it.
Record the digital output.
Load original file and recorded file in an editor e.g. Audacity
Time align (should start with exactly the same sample)
Subtract.
If original and recorded file are bit identical, the subtraction should yield a file with nulls only.

Note that this is done in the digital domain.



Often the claims are far more esoteric.
The optimized player produces less jitter, deeper black, etc.
The idea is by reducing electrical “noise” , the DA conversion is less affected hence the veil, the black, the etc.
This has never been proven by any measurement.
As it is about things that might affect the DA conversion, here you have to record the analog out of the DAC.
Comparing 2 analog recordings say one from a normal player, the other from a optimized player is pretty difficult as even the slightest amount of clock drift will yield a different file.
You might try your hand at DeltaWave: https://thewelltemperedcomputer.com/SW/AudioTools/NullTest.htm

Another less complicated way is a blindfold test.
Let somebody play a file using a “normal” media player. Likewise using an audiophile one.
Not knowing what is playing, it is up to you to detect the difference (if any).

 

[AlanHell]

It is called null-testing.

A relative simple one is testing for bit perfect output, no DSP is going on.
In this case you have a file, play it.
Record the digital output.
Load original file and recorded file in an editor e.g. Audacity
Time align (should start with exactly the same sample)
Subtract.
If original and recorded file are bit identical, the subtraction should yield a file with nulls only.

Note that this is done in the digital domain.



Often the claims are far more esoteric.
The optimized player produces less jitter, deeper black, etc.
The idea is by reducing electrical “noise” , the DA conversion is less affected hence the veil, the black, the etc.
This has never been proven by any measurement.
As it is about things that might affect the DA conversion, here you have to record the analog out of the DAC.
Comparing 2 analog recordings say one from a normal player, the other from a optimized player is pretty difficult as even the slightest amount of clock drift will yield a different file.
You might try your hand at DeltaWave: https://thewelltemperedcomputer.com/SW/AudioTools/NullTest.htm

Another less complicated way is a blindfold test.
Let somebody play a file using a “normal” media player. Likewise using an audiophile one.
Not knowing what is playing, it is up to you to detect the difference (if any).

Thanks you very much, this is exactly what I needed.

I will trust the DAC and USB chip designer much more for jitters reduction than believing it can be reliably achieved through software
I do not care about the "optimization" that I can not hear any difference from.
Instead, I want to run the test on the stuff I can hear the difference, and make sure they are result of modifying the PCM output.

 

[sajunky]

This is true that software manipulation have very little to do with jitter. Historically it was more important with high or low speeds synchronous or isochronous adaptive USB transfers, where DAC was receiving clock directly form PC or indirectly through a PLL (better). All modern interface chips use so called isochronous asynchronous USB transfers that completely eliminate PC clock jitter. It is just a matter how jitter is handled internally in a DAC, it can be done very poor.

I use both ASIO and WASAPI without any difference in sound quality. It was the same on Topping D30 with XMOS U208 interface chip and now Audio GD R2R11 with Amanero Combo 384. Absolutely no difference. If you hear differences, you have a different problem.

There is a different reaction to the critical interruption the data stream, it is due to the delays in kernel drivers or low memory (in my case). XMOS generate a half second pause, I don't remember whether is the same in WASAPI push and event modes, as I was using event mode only. Amanero in WASAPI event mode behaves exactly the same as XMOS, but in WASAPI push mode it reacts similar to the older USB chips. It doesn't interrupt stream, but it distort sound with a periodic purr-purr-purr. It takes longer to synchronise, so the event mode works better.

In any case it is a serious disturbance of data stream, you don't need an audiophile ear to recognise that something goes wrong. In such case you should test DPC latency and eliminate problem at the OS level. Preloading source to RAM may help as a last resort. It is done in Foobar by a plugin. Other software improvements in Foobar won't work, it is assuming Foobar is configured properly for bit-perfect transfers.

Configuring bit-perfect in Foobar is essential. There are three "foo-out" bit-perfect addons: ASIO, WASAPI Exclusive mode and KS (use it on XP if there is no ASIO driver). WASAPI Share mode add-on is not bit-perfect. Install and use at least one of three above, do not use default DS oputput. It also means - no DSP nor post-processing add-ons. Typically volume control in Foobar is handled by USB commands in a DAC - if a DAC support such feature. It is bit-perfect from the transport perspective. However R2R11 has no digital volume control (there is in a preamp), so fixing volume in Foobar at 100% is recommended. It is not critical, as Foobar do it properly in floating point, loses are minimal.

I personally do not follow strictly bit-perfect configuration, doing some resampling with SoX on the occasion, but my standard configuration is bit-perfect.

As for the Windows configuration, ASIO is a low level hack to the Windows, it doesn't need any further action. WASAPI is a Windows interface and the Exclusive mode needs to be enabled in a sound control panel. Also remember to give an application priority in the same place.

USB has a potential for the best audio quality. S/PDIF has always an inherent jitter, even more on optical. However it is a direct galvanic connection, so the internal operation of a DAC can be disturbed by ground loops. You can fight it two ways. Remove ground loops or insert USB isolators. The first can be difficult to fix, the second is expensive and will introduce inherent jitter, but it is a matter for a different topic.

 

[AlanHell]

This is true that software manipulation have very little to do with jitter. Historically it was more important with high or low speeds synchronous or isochronous adaptive USB transfers, where DAC was receiving clock directly form PC or indirectly through a PLL (better). All modern interface chips use so called isochronous asynchronous USB transfers that completely eliminate PC clock jitter. It is just a matter how jitter is handled internally in a DAC, it can be done very poor.

I use both ASIO and WASAPI without any difference in sound quality. It was the same on Topping D30 with XMOS U208 interface chip and now Audio GD R2R11 with Amanero Combo 384. Absolutely no difference. If you hear differences, you have a different problem.

There is a different reaction to the critical interruption the data stream, it is due to the delays in kernel drivers or low memory (in my case). XMOS generate a half second pause, I don't remember whether is the same in WASAPI push and event modes, as I was using event mode only. Amanero in WASAPI event mode behaves exactly the same as XMOS, but in WASAPI push mode it reacts similar to the older USB chips. It doesn't interrupt stream, but it distort sound with a periodic purr-purr-purr. It takes longer to synchronise, so the event mode works better.

In any case it is a serious disturbance of data stream, you don't need an audiophile ear to recognise that something goes wrong. In such case you should test DPC latency and eliminate problem at the OS level. Preloading source to RAM may help as a last resort. It is done in Foobar by a plugin. Other software improvements in Foobar won't work, it is assuming Foobar is configured properly for bit-perfect transfers.

Configuring bit-perfect in Foobar is essential. There are three "foo-out" bit-perfect addons: ASIO, WASAPI Exclusive mode and KS (use it on XP if there is no ASIO driver). WASAPI Share mode add-on is not bit-perfect. Install and use at least one of three above, do not use default DS oputput. It also means - no DSP nor post-processing add-ons. Typically volume control in Foobar is handled by USB commands in a DAC - if a DAC support such feature. It is bit-perfect from the transport perspective. However R2R11 has no digital volume control (there is in a preamp), so fixing volume in Foobar at 100% is recommended. It is not critical, as Foobar do it properly in floating point, loses are minimal.

I personally do not follow strictly bit-perfect configuration, doing some resampling with SoX on the occasion, but my standard configuration is bit-perfect.

As for the Windows configuration, ASIO is a low level hack to the Windows, it doesn't need any further action. WASAPI is a Windows interface and the Exclusive mode needs to be enabled in a sound control panel. Also remember to give an application priority in the same place.

USB has a potential for the best audio quality. S/PDIF has always an inherent jitter, even more on optical. However it is a direct galvanic connection, so the internal operation of a DAC can be disturbed by ground loops. You can fight it two ways. Remove ground loops or insert USB isolators. The first can be difficult to fix, the second is expensive and will introduce inherent jitter, but it is a matter for a different topic.

We share the exact understanding.
Hence I am very skeptical about those foobar optimizations and people claim been able to hear sound differences among difference versions.
Either their DAC is really bad, or their PC is super slow. I have not been able to tell the difference among different software under bit perfect playback situations. I normally leave up-sampling to my DAC as it always does it internally anyway. I will only try software upsampling if I have R2R DACs~