[WindowsX]

  Then why do the analog measurements not reflect this?

 
Which measurements? I haven't seen any 'good' analog measurements yet. Don Hills said it's possible to detect with good equipment but I haven't confirmed it myself nor I see anyone doing it with Fidelizer right now.
 
If you mean my previous RMAA post, it's evaluation from pure software recording so of course analog metrics won't detect any of that. RMAA isn't capable of measuring digital signal. That's why I tested on DiffMaker which is capable of doing digital audio measurements in pure software environment.
 
Regards,
Windows X

 

[nick_charles]

   
Which measurements? I haven't seen any 'good' analog measurements yet. Don Hills said it's possible to detect with good equipment but I haven't confirmed it myself nor I see anyone doing it with Fidelizer right now.
 

 
These are the specs on my current DAC and ADC (I upgraded from the Behringer) - would you consider this level of performance adequate to capture the effect of the software ?
 
ADC
SNR 110db
THD+Noise 0.0001%
 
DAC
THD+N 0.0004%
SNR 125db
 
I have a couple of i7 based PCs I could run the output from the USB DAC at 24/96 into the ADC at the same bit rate and depth - I can run a 10 test run to establish the degradation from the chain before going any further ?

 

[Harry Manback]

I also have an audio interface capable of 192@24.

I will give an unbiased test as well. It has ASIO drivers. I will record output from my odac and o2 amp to compare to the original files.

 

[WindowsX]

If you're sure that AD/DA device you're going to perform the test is better than Lynx Hilo, I'd be interested to hear the result. Here's Lynx Hilo's Ad/DA tech specs.
 
LINE IN A/D PERFORMANCE
THD+N -114dB @1kHz, -1dBFS, 20kHz filter
Dynamic Range 121 dB, A-weighted, -60dBFS signal method
Frequency Resp. ± 0.01 dB, 20 – 20kHz
Crosstalk -140 dB maximum @ 1kHz, -1dBFS signal
LINE OUT D/A PERFORMANCE
THD+N -109dB @1kHz, -1dBFS, 20kHz filter
Dynamic Range 121 dB, A- weighted, -60dBFS signal method
Frequency Resp. ± 0.02 dB, 20 – 20kHz
Crosstalk -135 dB maximum @ 1kHz, -1dBFS signal
 
It's not like doing with lower level of AD/DA won't matter. It's just my personal preference so feel free to test as you like. I'm not that conceited enough to judge or label people's work without giving it a try myself. Please be sure to optimize the playback/recording with lowest possible stable latency too.
 
Regards,
Windows X

 

[Don Hills]

... Please be sure to optimize the playback/recording with lowest possible stable latency too.

 
Why is this important?

 

[WindowsX]

   
Why is this important?

 
To reduce the range of latency jitter variations. As you can see from my experiment, even pure software environment can get worse correlation depth, let alone real hardware.
 
Regards,
Windows X

 

[Don Hills]

To reduce the range of latency jitter variations. ...
 

 
How does reducing the latency reduce the range of latency jitter variations? I would have thought that increasing latency (larger buffers / queues) would reduce jitter / noise by reducing the rate of buffer refilling.

 

[WindowsX]

How does reducing the latency reduce the range of latency jitter variations? I would have thought that increasing latency (larger buffers / queues) would reduce jitter / noise by reducing the rate of buffer refilling.

Actual tests may not reflect what you believe. Variations come in form of percentage.

Regards,
Windows X

 

[BiggerHead]

I haven't followed the whole thread but it seems to me there's some mis-representation about modern computers.  Many statements like "It's almost impossible to overlaoad modern computers" or "if your computer gets too loaded to handle audio you need a better computer", or whatever.
 
If you ask a computer to work it will typically work.. as hard as it possibly can, 100%, at least with one CPU, until it gets the job done. Sure if the job takes 50 microseconds, then that doesn't bump up the apparent load average because that average is calculated over some longer time.  Of course the task scheduler may limit a job or at least allow other jobs some of the time, and some process are I/O limited instead of CPU limited, but all that said it's not even remotely difficult to get a modern CPU core to spin at 100% for 50 milliseconds doing even ordinary tasks, but especially if you're doing something like.. oh.. for instance... audio compression, or even more so AV compression which is an ENOURMOUS computational task and something quite reasonable to have your A/V computer doing!  
 
What you do hope is that the audio itself is a very tiny load compared to everything else going on, and that your process scheduler is kind enough to give it the microsecond or so it needs before its buffer runs empty.  A bit of googling on windows scheduling reveals that windows workstations allow foreground processes to hold on to a CPU for 6 quanta, which seems to equate to somewhere in the ballpark of 90ms!  That's 90ms before anything else other than maybe an interrupt can do anything.  Multiple cores sounds good, but if one process on the same core as the audio does that, and you have a 50ms buffer, then it seems like a problem to me.
 
I'm almost surprised it works at all and I'm not an expert on the windows scheduler so I'm probably missing something, but at least it's certain that scheduling matters, at least if done badly, and I'm not surprised if improvements are possible.  I think the rep said this targets clicks and pops, not dull highs, and muddy lows.  Sounds about right.
 
Disclaimer, regarding audio, I have no idea how much of the work is offloaded to the soundcard itself using direct memory access.

 

[bfreedma]

I haven't followed the whole thread but it seems to me there's some mis-representation about modern computers.  Many statements like "It's almost impossible to overlaoad modern computers" or "if your computer gets too loaded to handle audio you need a better computer", or whatever.

If you ask a computer to work it will typically work.. as hard as it possibly can, 100%, at least with one CPU, until it gets the job done. Sure if the job takes 50 microseconds, then that doesn't bump up the apparent load average because that average is calculated over some longer time.  Of course the task scheduler may limit a job or at least allow other jobs some of the time, and some process are I/O limited instead of CPU limited, but all that said it's not even remotely difficult to get a modern CPU core to spin at 100% for 50 milliseconds doing even ordinary tasks, but especially if you're doing something like.. oh.. for instance... audio compression, or even more so AV compression which is an ENOURMOUS computational task and something quite reasonable to have your A/V computer doing!  

What you do hope is that the audio itself is a very tiny load compared to everything else going on, and that your process scheduler is kind enough to give it the microsecond or so it needs before its buffer runs empty.  A bit of googling on windows scheduling reveals that windows workstations allow foreground processes to hold on to a CPU for 6 quanta, which seems to equate to somewhere in the ballpark of 90ms!  That's 90ms before anything else other than maybe an interrupt can do anything.  Multiple cores sounds good, but if one process on the same core as the audio does that, and you have a 50ms buffer, then it seems like a problem to me.

I'm almost surprised it works at all and I'm not an expert on the windows scheduler so I'm probably missing something, but at least it's certain that scheduling matters, at least if done badly, and I'm not surprised if improvements are possible.  I think the rep said this targets clicks and pops, not dull highs, and muddy lows.  Sounds about right.

Disclaimer, regarding audio, I have no idea how much of the work is offloaded to the soundcard itself using direct memory access

While the scenario you describe is not impossible to see in the real world, it is highly unlikely to occur. Thread prioritization, core assignment based on load, and scheduler sequencing all work to prevent such a scenario. There are two ways it might happen. Running audio playback on a machine running a high workload application that uses multiple cores, primarily gaming and video processing, or intentionally setting thread priority for audio replay processes to "low". Neither seems to be common in a system dedicated to audio playback and both fall into the "oversubscribed system" category. That's without getting into the impact that buffering has on transient workload spikes.

Regardless, the claim is Fidelizer improves audio in all situations for all users. Nothing published to date by its author and proponents supports that claim.

 

[WindowsX]

While the scenario you describe is not impossible to see in the real world, it is highly unlikely to occur. Thread prioritization, core assignment based on load, and scheduler sequencing all work to prevent such a scenario. There are two ways it might happen. Running audio playback on a machine running a high workload application that uses multiple cores, primarily gaming and video processing, or intentionally setting thread priority for audio replay processes to "low". Neither seems to be common in a system dedicated to audio playback and both fall into the "oversubscribed system" category. That's without getting into the impact that buffering has on transient workload spikes.

Regardless, the claim is Fidelizer improves audio in all situations for all users. Nothing published to date by its author and proponents supports that claim.

He already told you there's some mis-representation about modern computers so you should try to listen if you don't have any proof to show that you're software engineer or someone who examined Windows thoroughly.

Regards,
Windows X

 

[BiggerHead]

@bfreedma, I'm not taking sides here, but you're saying the computer knows in advance how to keep high load threads off the same core as the audio processes? I don't see that you necessarily need to load up multiple cores, just the wrong core.

I might not understand all the tricks available to balance cores but I didn't think you can move a running thread to a different core because it's getting in the way of audio. Certainly in a one core scenario at least any video (or really even audio) compression is automatically "oversubscribed" regardless of CPU or I/O speed. It's effectively an infinite work load. Sure "sequencing" (scheduling) can help, and that was my point, and maybe it's always done well enough already. I don't know, but the premise seems reasonable.

The best snake oil starts with reasonable premises, but some of the arguments here have seemed to imply that premise is unreasonable because you can't possibly even tax a computer hard enough now, and I just really don't think that's the right argumentation. The right argumentation might be that modern process schedulers can't possibly ignore the audio process for that long. I'm definitely not saying everyone needs this.

 

[BiggerHead]

I'll go one farther and say that I'm pretty sure if you do need it, or need it, or often enough to care, that you'd hear noticable pops, etc at least enough to annoy you.  If there are even more often a little less noticable problems, who knows, but what I think know of process schedulers is the algorithms seem too flexible to leave them right at the the threshold of almost working and never beyond.

 

[bfreedma]

He already told you there's some mis-representation about modern computers so you should try to listen if you don't have any proof to show that you're software engineer or someone who examined Windows thoroughly.

Regards,
Windows X

 
Yes, I've only spent 3 decades optimizing system performance from the individual server (Windows being one of the many platforms) level through full data center design and implementation in highly regulated industries where failure to meet operational goals results in massive fines and possible business closure.  What do I know....?
 
I've also written mission critical software used by enterprises supporting 10000 simultaneous users, but again, what do I know....
 
I find it interesting that instead of responding to questions or posting measurements to support your product, you resort to insults.  Frankly, it makes me wonder what beyond Fidelizer makes you think you have any idea about actual system and component performance testing and whether you've actually done the same in a customer environment.

 

[WindowsX]

   
Yes, I've only spent 3 decades optimizing system performance from the individual server (Windows being one of the many platforms) level through full data center design and implementation in highly regulated industries where failure to meet operational goals results in massive fines and possible business closure.  What do I know....?
 
I've also written mission critical software used by enterprises supporting 10000 simultaneous users, but again, what do I know....
 
I find it interesting that instead of responding to questions or posting measurements to support your product, you resort to insults.  Frankly, it makes me wonder what beyond Fidelizer makes you think you have any idea about actual system and component performance testing and whether you've actually done the same in a customer environment.

 
I only told you to listen to people has different ideas instead of shooting down everyone who disagree with you. There's no insult here. If anyone, it's you or your confidence in your field of work.
 
You did manage enterprise server but not computer audio server. Don't mix the job please. They need completely different optimizations.
 
I did my part to show significant improvement with correlation depth in pure software environment. This measurement data is used in gearslutz and a lot pro pros accept this kind of measurements. Since I can show significant improvement in pure digital domain, there's nothing more to prove within analog. I'm writing software to optimize Windows platform not the DAC itself.
 
Regards,
Windows X