MQN testing/experimentation thread

[jkeny]

I believe a lot of the "magic" of MQN is got to do with it's timing - in other words I think that it is more accurate & sharp in it's signal deliver to the two stereo channels & as a result the sound is more precise & accurate. Hence better timbre to instrument sounds.

That'd be where the difference lies, IMO. It's the timing cues that are less important, and or not heard, to the bits is bits brigade, it would seem. How do you measure that ?

Some people will see timing & think jitter but I don't believe this the issue. Trying to analyse the differences I hear suggests to me that the timing in the music is just more precise & sharper. I think this is more to do with inter-channel timing which I have never seen anybody measure. The result of this better timing is audibly more accurate presentation with the timbre of the instruments rendered more realistically. This is what I was talking about when I said the individual changes are subtle but the overall effect on the presentation is much more noticeable. Trying to isolate & hear individual differences is more difficult than hearing differences in the overall presentation

It would help if we all talked about the same tune or tune, but isn't that a bit too sect like ?

I don't mean talk exclusively about one particular tune (or a set of them) but rather use them to highlight a point that someone is hearing. Of course other music should be/will be discussed - it just gives a point of reference for others to test on their own systems

[DaveF]

I'm really struggling to see how MQN affects timing and I'm just trying to tease out a few ideas no matter how unlikely they are.

If MQN really is different, I think the causes are elsewhere.

I'm not sure it is a timing issue, think it may be a noise issue. It has thousands of instructions firing every second, which, I surmise, puts some sort of modulated wave/frequency on top of the data. In the squeezebox days the idea was that the signal could be isolated by using a wireless transfer, but I think this just swapped one sort of noise for another as the SQ was worse.

I dont think its a timing thing either so noise is one possible explaination.

But lets say for example MQN is a sequence of 100 basic instructions repeated over and over again as it plays/renders the WAV file. Is windows at some point not going to come in and preempt or interrupt the core executing these instructions? And it could be different each time you play back a file.

For example during the first playback, the first 20 instructions takes the core 100us to complete but on second playback, it might take 250us to complete as windows has come in and demanded that the core service something else.
So you're going to get inconsistencies betweeen playbacks at this level of resolution.

Now of course from a data integrity point of view it doesnt matter as all this taking place in the GHz range so my understanding of it is that the PC/Sofware will render the data and fill up a buffer for the audio transitter to feed the DAC. The PC/SW has to stall at some point until the buffer gets near emptied by the TX as the transmitter is just chugging along at very slow rate of 44.1 relative to what the processor is capable of. The hardware will need to tell the layers above it that hey my TX buffer is getting near empty, you better give me another big chunk of samples or else dropouts are going to occur.
Perhaps its a variation in how MQN keeps the TX buffer in the hardware near full even though it never allows the buffer to actually empty. Is it this variation that is modulating noise in the hardware perhaps?

Since everybody has different laptop specs this introduces more inconsistencies so is this why only some people are hearing a difference with MQN?

[jkeny]

the only question you need to answer is do all bit perfect players sound the same ? If you have chosen one player over another and/or one set of settings over another because of SQ reasons then the answer is no.

For me most players sound digital and the best sound is via memory play which usually sounds even more digital, but the timing is much better.

So given there are differences between players why might that be ?

Well to give you an insight into what's going on in the player here is some info - the cpu has to load instructions into a cache, decode those instructions, attempts to predict what those instructions are going to do next (branch prediction), decide how it's going to carry out the instructions, execute the instructions in a time slot. The cpu likes to know where the branch is going so it can load instructions ahead of time, it likes to know the likely values of any variables, in fact it prefers constants as they can be hard coded and optimised at compile time, it likes data to be sequential so it can prefetch etc

for memory a similar set of actions is happening, the cpu is trying to prevent cache misses, the cpu has 3 levels of cache which are located on the chip L1,L2 and L3, these take say 1, 10, 50 cycles to retrieve data, L1 is 32kb and L3 is 4 mb, typically. The cost of a cache miss is several 100 cycles as the cpu needs to fetch the missing data from slow ram or even worse ssd/hdd. data is loaded in cache lines of 64 bytes and it is important to load and utilise data in cache line chunks otherwise the cpu is loading data it doesn't need.

There are a thousand other things that may cause the cpu to use extra cycles and there seems to be a correlation between cycles and SQ, for instance the assembly instruction sub has always caused problems with sibilance even though it is effectively the same as add.

So given all that, which would you expect to sound better, a player that optimises for the above or one that has lot's of variables, branches etc ie one that uses fewer cpu cycles in a consistent manner or one that uses more in an unpredictable manner. I have yet to hear a player that sounds better because of more cpu cycles. There may also be an instruction component to the noise as well eg it's not just cpu cycles that cause noise but reading from memory etc

These are all things that can be investigated and hopefully the whole CA community would benefit because there are only really a few ways of passing data through the cpu. Then you can decide how much of a SQ trade off you want to make in order to have better functionality (usually has an effect on SQ due to more checking required for user interaction, end of track etc). Streaming players have additional issues because they are checking for near end of track every buffer load cycle as well, so they can queue the next track up, probably doing format conversion at the same time, but heh, as long as it's bit perfect.

Great post, sbgk
An idea might be to create a "BAD" MQN - one which has the max amount of looping before loosing bit-perfection.
It would be a good reference point for both listening tests & measurements.
What do you think?

[jkeny]

Yes, DaveF, you raise a number of good points
I agree Windows is not the ideal platform for audio playback, but it is still showing how good it can sound when done well. Whose to say a real-time OS will sound better? Theory says so but .....Only trying it will show that.

About the timing - I'm really saying that when I try to analyse what I hear I find I keep coming back to hearing the timing within the music more precisely. I'm not fully sure what is the cause of this - is it better inter-channel timing, is it lower noise floor & therefore the subtle cues are being heard, is it a combination of both? This is the sticking point in so many other forums & why I like this forum - we understand the difference between kicking around ideas (brainstorming) in order to formulate some possible theories of operation. Sites that will remain nameless jump on this as a point to argue rather than debate.

However, we really need some measurements before we begin theorising- but this is the tricky bit - where/what do we measure - this is usually informed by our theory of what the possible mechanisms could be.

Firstly, using sinewaves is not going to be useful, in my opinion. We need dynamic signal content in order to investigate the possible issues.
Measuring noise in a dynamic signal is a tricky business
Measuring timing in a dynamic signal is a tricky business

Maybe you have some thoughts about how these measurements could be approached? I have some ideas on the timing measurements.

[sbgk]

But lets say for example MQN is a sequence of 100 basic instructions repeated over and over again as it plays/renders the WAV file. Is windows at some point not going to come in and preempt or interrupt the core executing these instructions? And it could be different each time you play back a file.

For example during the first playback, the first 20 instructions takes the core 100us to complete but on second playback, it might take 250us to complete as windows has come in and demanded that the core service something else.
So you're going to get inconsistencies betweeen playbacks at this level of resolution.

Now of course from a data integrity point of view it doesnt matter as all this taking place in the GHz range so my understanding of it is that the PC/Sofware will render the data and fill up a buffer for the audio transitter to feed the DAC. The PC/SW has to stall at some point until the buffer gets near emptied by the TX as the transmitter is just chugging along at very slow rate of 44.1 relative to what the processor is capable of. The hardware will need to tell the layers above it that hey my TX buffer is getting near empty, you better give me another big chunk of samples or else dropouts are going to occur.
Perhaps its a variation in how MQN keeps the TX buffer in the hardware near full even though it never allows the buffer to actually empty. Is it this variation that is modulating noise in the hardware perhaps?

Since everybody has different laptop specs this introduces more inconsistencies so is this why only some people are hearing a difference with MQN?

I assumed windows was constantly swapping the task in and out of the cpu, that's where core affinity and MMCSS helps in prioritising how much cpu time MQn gets.

I thought WASAPI event gets a event trigger (IRQ) when the buffer is empty, it then has a period to fill the empty buffer before the other buffer is emptied. Other methods use a timed buffer fill and have to calculate how much of the buffer is required to be filled eg WASAPI shared, not sure what KS, ASIO etc do, but am impressed with WASAPI exclusive event mode. By filling the empty buffer we know exactly how much data is required and the whole thing can be optimised based on that figure. Calculating how much buffer you have to fill is the last thing you want to be doing in a noise sensitive environment.

[jkeny]

Great post, sbgk
An idea might be to create a "BAD" MQN - one which has the max amount of looping before loosing bit-perfection.
It would be a good reference point for both listening tests & measurements.
What do you think?

I can do one that you're dog will sing along to, a watery one, a dry one and bassy one, could even do a fishy one, oh wait that's a different sensory organ.

Right, please do one that is broken to the max but still bit-perfect.
I'll blind-test it with the local dogs & report results.
No grooming of participants will happen :)

This would be a less challenging concept for the bits-is-bits crowd playback software that "claimed" it was worse sounding than other playback software while still being bit-perfect

[erin]

Firstly, using sinewaves is not going to be useful, in my opinion. We need dynamic signal content in order to investigate the possible issues.
Measuring noise in a dynamic signal is a tricky business
Measuring timing in a dynamic signal is a tricky business

Maybe you have some thoughts about how these measurements could be approached? I have some ideas on the timing measurements.

I like talking about this stuff.
Thought 1:

I don't think it is possible to measure this sort of stuff directly in the digital domain - because bits are bits. No-one will dispute this. The problem we are faced with is that these bits end up sounding different when played by different players (and different versions of MQn)

My suggestion is that if we can hear it we must be able to measure it, however the apparent difference is only present in the analog domain such as our ears, therefore the signal coming from the output of the DAC MUST be different if we can hear it. So, to capture the difference we must use analog recording equipment.

We need to:
* playback a piece of music (signal etc.) and record the output of the DAC to analog tape
* make a change to the playback software (MQn)
* then playback the same piece of music (signal etc.) and record the output of the DAC to tape,
* then playback both analog recordings and capture using a soundcard.
* then using audio editing software analyse and compare the spectral content, invert the phase of the first recording and see if the second recording is nulled when the inverted capture of the original recording is overlaid. - All of this can be done in Adobe Audition.

Problems: tape has noise, hiss, wow/flutter, uneven coatings etc.

Theory: despite the problems of analog tape, we should still be able to capture some differences such as deeper bass, better attack on notes etc.

Thought2: perhaps we can just use a second different computer to record the output of the DAC?

Thought3: I have gone mad :P ;(

[sbgk]

Firstly, using sinewaves is not going to be useful, in my opinion. We need dynamic signal content in order to investigate the possible issues.
Measuring noise in a dynamic signal is a tricky business
Measuring timing in a dynamic signal is a tricky business

Maybe you have some thoughts about how these measurements could be approached? I have some ideas on the timing measurements.

I like talking about this stuff.
Thoughts:

I don't think it is possible to measure this sort of stuff directly in the digital domain - because bits are bits. No-one will dispute this. The problem we are faced with is that these bits end up sounding different when played by different players (and different versions of MQn)

My suggestion is that if we can hear it we must be able to measure it, however the apparent difference is only present in the analog domain such as our ears, therefore the signal coming from the output of the DAC MUST be different if we can hear it. So, to capture the difference we must use analog recording equipment.

We need to:
* playback a piece of music (signal etc.) and record the output of the DAC to analog tape
* make a change to the playback software (MQn)
* then playback the same piece of music (signal etc.) and record the output of the DAC to tape,
* then playback both analog recordings and capture using a soundcard.
* then using audio editing software analyse and compare the spectral content, invert the phase of the first recording and see if the second recording is nulled when the inverted capture of the original recording is overlaid. - All of this can be done in Adobe Audition.

Problems: tape has noise, hiss, wow/flutter, uneven coatings etc.

Theory: despite the problems of analog tape, we should still be able to capture some differences such as deeper bass, better attack on notes etc.

One of of differences that MQn produces is in stereo presentation it can be wide, narrow, compressed, tall or 3d. Is there no measurement that can be used to measure the effect on stereo presentation ? The same on pitch, some versions have an enhanced treble, some the bass is enhanced, can a tone be played and then checked to see if it has changed pitch ? Don't know if that is the correct attribute, but am looking at a way to measure the audible differences.

[sbgk]

Right, please do one that is broken to the max but still bit-perfect.

Isn't that called Foobar?

the playerextreme.exe in the test folder could be used, just rename it to mqncontrol.exe. It uses the original memcpy, no optimisations, no memory play - reads straight from the hdd, presumably is bit perfect.

[jkeny]

Absolutely agree, Erin, the measurements have to be taken at the analogue out of the DAC, at least initially to prove the case. At a later stage further & deeper measurements of the digital signal going into the DAC would be of interest but not just bits measurements but actually electrical signal measurements.

Question 1: Why record analogue to tape? Why not directly into a good digital recorder? This has to be sufficiently accurate for the proposed level of measurement required.

Question 2: What level of null is acceptable or is it just that we want to compare the MQN null value to other player null value? What value null is achieved by playing the same track through the same player twice & nulling the inverted against the original ? Remember there is never a perfect null. The nulls for MQN have to be consistently & significantly different to other players but what does significant mean? If we are talking about noise being reduced & subtle audio cues being now heard - what level does this imply -70dB, -80dB, -90dB, what do you reckon?

Maybe we should branch off this discussion to another thread about measurements of MQN?