MQN testing/experimentation thread

[jkeny]

when people say bits are bits they are really talking about values held in bytes, 8 bits to a byte, 16 bit requires 2 bytes and is called a word. The cpu can't load a single byte from memory, it deals in cache lines which are 64 bytes, so get one byte and you get a whole cache line. There are 3 levels of cache which are usually L1 - 32kb, L2 - 512 kb, L3 3 MB, in a multi core cpu L1 and L2 are dedicated to a core and L3 is shared. So the idea is to load a cache line and pass it through the cpu as efficiently as possible. The penalty for accessing data not in cache is several hundred cycles.

There's a lot going on in the CPU and plenty of things to generate noise, the above description is just a brief intro to the complexities of it all.

so it might be some measurement of things like cache misses correlates to sibilance etc

Yes, cache misses would be another good measurement. Any software which can measure this (which doesn't interfere with the MQN process)? Or would there have to be another approach?

[sbgk]

when people say bits are bits they are really talking about values held in bytes, 8 bits to a byte, 16 bit requires 2 bytes and is called a word. The cpu can't load a single byte from memory, it deals in cache lines which are 64 bytes, so get one byte and you get a whole cache line. There are 3 levels of cache which are usually L1 - 32kb, L2 - 512 kb, L3 3 MB, in a multi core cpu L1 and L2 are dedicated to a core and L3 is shared. So the idea is to load a cache line and pass it through the cpu as efficiently as possible. The penalty for accessing data not in cache is several hundred cycles.

There's a lot going on in the CPU and plenty of things to generate noise, the above description is just a brief intro to the complexities of it all.

so it might be some measurement of things like cache misses correlates to sibilance etc

Yes, cache misses would be another good measurement. Any software which can measure this (which doesn't interfere with the MQN process)? Or would there have to be another approach?

there are tools that do it while the exe is running vs has profiling as well.

[jkeny]

there are tools that do it while the exe is running vs has profiling as well.

Have you tried them? It could be very useful not only for proof of differences of MQN versions & also, to possibly add another aspect to differentiate versions that are sounding closer together?

[Julf]

One thing though - Audacity FFT spectrum plot only goes down to -90dB which I don't believe is sufficiently low enough for what we want to test here.

Only by default, the range setting can be changed.

[Julf]

Lined them both up to the same sample Not too difficult with this track as it has a nice transient from an isolated triangle sound to line up to) - Inverted one file, rendered the two files together & did an FFT on the resultant combined file.
Nothing in the FFT i.e tracks are exactly the same!

But was there something in the file before the FFT - did you look at the "raw" difference?

[DaveF]

I believe a good first step would be to use a USB analyser which allows us to look at the electrical signal as well as the logical signal coming out of the USB port.

I don't have such a device. A very fast oscilloscope may well suffice?

DaveF would you be willing or allowed to do such tests? Do you have access to such equipment?

I'd have all the equipment I need at work to do the job but unfortunately there would be no way of being allowed to use it for something like this plus the equipment is all tied up with testing anyway.

[DaveF]

If equipment wasnt issue I'd be inclined to take the digital out just before the DAC and run it into a high speed ADC board connnected to a FPGA PCI-E card in a PC. Take several sample sets and use Matlab to do all the fancy analysis offline to your hearts content.
The ADCs would have to have a sufficient noise floor and high ENOB(effective number of bits) to make sure we have enough resolution.

Using scope to look at a stream in real time might be tricky to get a stable trigger.

[jkeny]

I'd have all the equipment I need at work to do the job but unfortunately there would be no way of being allowed to use it for something like this plus the equipment is all tied up with testing anyway.

Yea, I thought it would be restricted to work-only usage.

[jkeny]

If equipment wasnt issue I'd be inclined to take the digital out just before the DAC and run it into a high speed ADC board connnected to a FPGA PCI-E card in a PC. Take several sample sets and use Matlab to do all the fancy analysis offline to your hearts content.
The ADCs would have to have a sufficient noise floor and high ENOB(effective number of bits) to make sure we have enough resolution.

Using scope to look at a stream in real time might be tricky to get a stable trigger.

But that will only be examining the digital logic signal, not the electrical waveform that is the physical form of this logic signal.
It's in this waveform that the noise is likely to be embedded & it's interaction with the USB receiver & downstream circuit may well be where there is some insight to be gained?

[jrling]

Saw this article over on CA (sorry SBGK!) -
http://www.computeraudiophile.com/conte ... omparison/

Mitch was using readily available tools to do pretty much what we would want to do with MQn by the looks of it. However all in the digital domain and perhaps therefore beyond the limits of the software to detect minute differences? He was comparing JRiver on Windows with JRiver on Mac so perhaps there are actually no differences in that comparison.

Anyone think his approach would work for our experiments?

Jonathan