MQN testing/experimentation thread

[sbgk]

umm, well it doesn't need to be real time - all it needs is to fill a buffer in the required time to prevent dropouts, MQn does this using as few instructions as possible (or that's the aim, not quite there yet). So MMCSS ensures it has priority and putting it on it's own core helps as well. MQn is a background task and I understand that the maximum % time the scheduler will give background tasks is 50% and there are no dropouts. So, inclined to think real time is a red herring, video transfer through the cpu has much higher throughputs and doesn't seem to be a problem. Why do you need real time when the data is not a constant stream, but buffer sized chunks required on a periodic basis ?

I'd agree, we certainly dont need real time responses from the OS in order for it to deliver data down to the TX hardware buffers. I merely brought it up when I saw MQN and timing being mentioned earlier this morning.

Its this whole timing thing that I'm struggling with. Lets say we're transmitting a pair of 16bit words each time @ 44.1KHz. So the TX transmitter will grab a pair of words from the buffer every 22.6 us. (hardware buffer, not software) Lets say we have a 256 deep buffer x 16bits wide. We read a pair(stereo left and right) each time from this buffer so after 128*22.6us we will empty the buffer. Of course the hardware would be monitoring when the buffer approachs near empty, say when there is 10 words left. It will then interrupt the hardware or perhaps initiate a DMA to transfer another bunch of samples to the buffer until its full again.
Lets say one version of MQN only manages to get around to refilling the buffer when there is 8 words left and another version only manages to get around to it when there is 6 left. Either way the TX doesnt care as it always has a valid pair of words to read from the buffer.
I've kinda simplified this so that hopefully some of the non technical people can follow this.

Another question: Where is the divide between software and hardware here? Is MQN running at a very low layer so that it has direct access to the hardware or is it sitting higher up and relying on a few more layers of software to do the talking to the hardware? My guess is that since it runs on many different PC specs it sits higher up. It would have to really.

From my experience of embedded systems, the hardware/sofware divide is usually pretty distinct but a pc/windows enviroment is quite a bit different.

MQn fills a 8192 byte buffer (there are 2 buffers, so one is always being filled as the other is read), it loads data into memory and initialises a WASAPI end device, data is then moved from memory to the buffer triggered by an IRQ from the end device/driver . Understand the driver may be working at a DMA level. So MQn controls the movement of data from memory through the cpu to the end device/driver.

[nige2000]

Yea, so these listening impressions about how electrical mods are different sounding to MQN effects, point to the possibility that MQN is doing more than just noise reduction.

Tony, as and of themselves, measurements which show differences between different bit-perfect digital streams will be a big leap in our understanding. Correlating these measurements to what we hear would be a huge leap in understanding. I'm all for advancing understanding.

I don't for a moment doubt that the more rabid measurists will still argue - claiming that the differences are too insignificant to be audible

MQn is much better at the complex and fast moving, other players miss notes and muddle,
thats likely timing

[jkeny]

DaveF, you're working from the top-down i,e theory & knowledge of internal processes to determine mechanism at play
I'm working from bottom-up i.e what a stumbling analysis of the end sound suggests is the mechanism at play

Both approaches are useful & equally valid & keep up the detailed inquiry - it is very useful & interesting.

I'm not sure how to reconcile what you have said Vs what sbgk has just said about the internal operations of this process. From my brief read it seems there is a read & write buffer. From what sbgk has said in the past, if I remember correctly, having a buffer size matched to samplerate seems to be beneficial to efficiency of the movement of data in fewest CPU cycles. So I guess this might point to timing too.
sbgk's comments about moving the data through the CPU to the end device/driver also signifies a very critical role.

I know the CPU processor speed is in the GHz & we are talking about 44.1KHz audio so it would seem to be an easy task to handle. Even I can understand your pause in this regard - you have more knowledge at a deeper level than I, in this area.

[adolfo.a.aguiar]

sbgk,

There is something that I can't figure out.
The CPU is executing the rendering loop and you are carefully selecting the loop instructions to obtain the best sound.
While executing the loop, the process might be interrupted and several instructions will be executed before the rendering loop gets the CPU back. The consequence of this would be an inconsistent SQ.
You have remarked before that the CPU prefers to have predictable work.
Have you attempted to disable interrupts in critical parts of the rendering loop in order to minimize this effect?
If it is true that predictable work sounds better, then a real time OS would be beneficial, even if a non-real time OS can do the job.

[DaveF]

sbgk,
While executing the loop, the process might be interrupted and several instructions will be executed before the rendering loop gets the CPU back. The consequence of this would be an inconsistent SQ.

How so?

I've touched on it before in my earlier posts. Even if in playback session 1, the CPU renders a loop in 50us with no interupts and then in playback session 2, the CPU takes 200us because it got interrupted, it doesnt matter. This variation in execution time is off no consequence to the audio hardware below as its chugging along at 44.1KHz. As long as it gets its correct sequence of samples, we're fine.
This isnt just theory, I've had plenty of experience of looking at this stuff in a lab over many years. Even when the software guys on the team tried to allocate priority to a piece of software to a core on the processor and shut down processes, they found that Windows was an absolute bastard for coming in and interrupting when it felt like. Now this was only a problem because we were dealing with extremely high speed data transfers and lots of it. In our audio case here things arent anywhere near as demanding as this.
For timing critical applications such as those on certain embedded systems, a real time OS is essential where you must have a very high degree of predictability in what goes on in the system.
From a 'data processing' point of view, audio isnt timing critical because we have a huge amount of overhead in the processor.

If the differences in MQN are indeed real and not placebo and so on, then I think we're looking in the wrong place. But I'm running out of places to look.

As for my own testing of MQN, one of my hard disks has developed a fault and I need to drain a waterloop and disassemble part of it in order to get at the drive. Major hassle so my testing has been put on hold until I find time to fix my problem.

[adolfo.a.aguiar]

DaveF,

We have 2 different issues here:

1. Does the interruption affect the capacity of the render loop do its job?
Here we agree that the answer is no.

2. Do the extra instructions executed to handle the interruption affect SQ?
I don't know but I would be inclined to say yes, the reason being that sbgk detects change in SQ if he replaces an Add instruction by a Sub in the render loop.

Concerning MQn, it provides the best sounds I've ever had in my room.

[jrling]

DaveF
If the differences in MQN are indeed real and not placebo and so on, then I think we're looking in the wrong place. But I'm running out of places to look.
Sorry to hear of your disc breaking.
I have tested just about every version SBGK produced from the start, and there is no doubt that differences are real and not placebo effect. That's getting worse as well as improving. Really clear differences. You will find many others here who will tell you the same.

I can say that moving MQn onto its own core, changing registry settings to give MQn process priority and changes to MMCSS settings, seem to do stuff for others, but with my D510 Atom dual core rig, I think that might be a placebo effect and certainly no major change in my system. One version of MQn to another though can be very noticeable if changes to the render loop have been made.

I am finding your posts very clear and helpful and persuasive.

I can only agree with you that we should look elsewhere.

Adolfo -
Concerning MQn, it provides the best sounds I've ever had in my room.
Me too by a long way compared to JRiver, Foobar and MPDPup on Linux. It is extraordinary what can be done with plain 16/44.1 WAV files. Although I would love to play 24/96 soon - Hint, Hint SBGK!!

[sbgk]

DaveF,

We have 2 different issues here:

1. Does the interruption affect the capacity of the render loop do its job?
Here we agree that the answer is no.

2. Do the extra instructions executed to handle the interruption affect SQ?
I don't know but I would be inclined to say yes, the reason being that sbgk detects change in SQ if he replaces an Add instruction by a Sub in the render loop.

Concerning MQn, it provides the best sounds I've ever had in my room.

don't think those instructions do anything with the IRQ, they just sound different, because they have different code behind them ?

[DaveF]

Out of interest, is there a unit test in software to ensure that each version of MQN is bit perfect?

I dont think you need real audio data to test for this. Something such as creating a buffer in software and initialising it with some checkerboard data pattern. Feed it into your code and observe the output of your code just before it hands over the result to the driver level. Maybe this isnt so straightforward as to me the exact divide between the MQN code, windows sw and the hardware isnt clear.

[LowOrbit]

That would be an interesting check, though I do think this "bit perfect" measure is nothing to get too hung up on.

The origin of "bit perfect" is - as you will be perfectly aware - in the old Windows mixer, which resampled everything to a common output stream at a given depth/rate. What you pulled out of the file was not necessarily what came out of the buffer. ASIO, KS and Wasapi Event make this a moot point. (Bit perfect does not get talked about much in Mac circles, for this very reason - it was never an issue.)

There is still the possibility that your application messes with the original samples but that should be in your control and for a specific purpose (EQ, gain etc). On a general purpose computing platform the code for doing such dsp effects at decent quality is quite sophisticated. And we should not be scared of that per se, as pretty much every album recorded in the last five years (or more) has been recorded using such a platform, probably mastered in such an environment.

I'd be amazed if MQn were applying any kind of "treatment". It's a tiny programme compared to most.