Tír Na HiFi

sbgk wrote: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

jkeny wrote:

sbgk wrote: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 wrote: there are tools that do it while the exe is running vs has profiling as well.

jkeny wrote: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.

jkeny wrote: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!

jkeny wrote: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?

DaveF wrote: 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 wrote: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.