Tír Na HiFi

Great discussion. Must say at such a better and well-informed level than other forums some of us have inhabited in a past life.
Thanks to all concerned.

One piece of the adverse SQ [Windows] jigsaw not so far mentioned and a bit of a hobby horse for me using Windows as the OS, is the USB Audio Class 2 proprietary drivers we have to interpose in the PC chain. Some may be written well - I have Thesycon v1.67 for my WaveIO USB/SPDIF converter - and others are not or so I read.

Whilst Microsoft have apparently rewritten a lot of the audio code for WASAPI in Win 8/8.1 Server 2012 R2 (which I recommend highly), they still do not provide native UAC2 drivers so that we can do away with proprietary USB drivers for our DACs. Linux did that ages ago.

I have tried to minimise CPU interruptions by applying various registry settings recommended for MMCSS, Priority Control, turning off unnecessary hardware and software/services and accumulated they add up to noticeably improved SQ - either through timing or reduced noise I wouldn't know - but there is a limit to what we can do with an OS that is designed to do all things for all men. I reckon SBGK with MQn and optimisations to Windows are beginning to approach the practical limit for what can be done using the Windows OS.

DaveF wrote:

jkeny wrote: I believe a lot of the "magic" of MQN is got to do with it's timing

But MQN is running on Windows which is a non real-time OS. How can MQN guarantee that at some point it wont be interrupted by some Windows process with a higher priority?
I did work before where we were streaming high speed data from an FPGA development card in a PC PCI-E slot to PC memory. We couldnt guarantee above a certain data rate because some random windows processes would kick in resulting in overflows on the FPGA card. Shutting down some of these did help but only to a certain extent.

Only OS's such as QNX or VXWorks can guarantee that an interrupt etc will be serviced within a certain time slot.
Now I'm more on the hardware side of things so I'm open to correction on any of the above.

Just re-reading these posts from the start again & I thought of something in relation to this point, DaveF
Maybe what MQN is doing is providing a smaller target by being quicker i.e less chance of windows interrupts during what seems to be the critical element of the render loop. So it's not that it guarantees interrupt-free operation of this loop but significantly cuts down the incidences of this occurring? So it's almost a side-effect of making the loop tighter & more efficient.

In other words, keeping each critical process in the audio playback system as much as a self-contained, uninterrupted process as is possible in Windows. sbgk has identified the render loop & memcpy as the two most critical processes in this chain & shown what tightening up these processes can do for the sound.

Does this concur, sbgk with your view of what your code is doing?

jkeny wrote:

DaveF wrote:

jkeny wrote: I believe a lot of the "magic" of MQN is got to do with it's timing

But MQN is running on Windows which is a non real-time OS. How can MQN guarantee that at some point it wont be interrupted by some Windows process with a higher priority?
I did work before where we were streaming high speed data from an FPGA development card in a PC PCI-E slot to PC memory. We couldnt guarantee above a certain data rate because some random windows processes would kick in resulting in overflows on the FPGA card. Shutting down some of these did help but only to a certain extent.

Only OS's such as QNX or VXWorks can guarantee that an interrupt etc will be serviced within a certain time slot.
Now I'm more on the hardware side of things so I'm open to correction on any of the above.

Just re-reading these posts from the start again & I thought of something in relation to this point, DaveF
Maybe what MQN is doing is providing a smaller target by being quicker i.e less chance of windows interrupts during what seems to be the critical element of the render loop. So it's not that it guarantees interrupt-free operation of this loop but significantly cuts down the incidences of this occurring? So it's almost a side-effect of making the loop tighter & more efficient.

Does this concur, sbgk with your view of what your code is doing?

im thinking
Efficiency and priority settings means less chance of the interrupts, theres just less to do
whether that is bringing better timing or less noise or both im not sure

nice to talk about this stuff without dodging troll bullets :)

jkeny wrote:

DaveF wrote:

jkeny wrote: I believe a lot of the "magic" of MQN is got to do with it's timing

But MQN is running on Windows which is a non real-time OS. How can MQN guarantee that at some point it wont be interrupted by some Windows process with a higher priority?
I did work before where we were streaming high speed data from an FPGA development card in a PC PCI-E slot to PC memory. We couldnt guarantee above a certain data rate because some random windows processes would kick in resulting in overflows on the FPGA card. Shutting down some of these did help but only to a certain extent.

Only OS's such as QNX or VXWorks can guarantee that an interrupt etc will be serviced within a certain time slot.
Now I'm more on the hardware side of things so I'm open to correction on any of the above.

Just re-reading these posts from the start again & I thought of something in relation to this point, DaveF
Maybe what MQN is doing is providing a smaller target by being quicker i.e less chance of windows interrupts during what seems to be the critical element of the render loop. So it's not that it guarantees interrupt-free operation of this loop but significantly cuts down the incidences of this occurring? So it's almost a side-effect of making the loop tighter & more efficient.

Does this concur, sbgk with your view of what your code is doing?

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 ?

Yes, Nige, it is refreshing to be able to discuss these notions without fear.

Just trying to tease out noise Vs timing - is there a different type of improvement that we hear when we moved to linear supplies & then to battery? I heard increased body, solidity in the sound in your meet-up & I think this is the generally reported audible improvement with the electrical mods/tweaks. Am I right?

The reason being electrical mods/tweaks can probably only influence noise in the system - hopefully decrease it.

Are these different to the audible improvements we hear with MQN - which to me sound like more distinctness, delineation of the sound. This audible effect happens both in electrically tweaked systems & in non-tweaked systems

Briefly from me, linear supplies and battery on the usb stick and then battery fed from linears gave improvement in tone and background noise/blackness improved.
Couple that with optimized core server and I was at a point where I couldn't see how it could improve further unless big money was outlayed trying expensive supplies etc that may have delivered nothing. I still suffered from the occasional tracks that were a bit too bright in presentation.

MQn got rid of any issue above. Soundstage and the richness of harmonic tone improved for me to a point any stuff I play sounds enjoyable. Yes the well recorded jazz albums are really incredible but vocals in even eighties favourites and Neil Young etc have as a good a sound as I think possible with the equipment I have.
Level of details which since jplay ultrastream has been really good also is just at perfection for me. A number of people have reported the same thing you can hear all the small delicate details. The double bass guy in Oscar Petersons You Don't know me is really audible.

Not sure what all your measurement stuff is going to deliver.Knowledge to help you develop and understand the effect of changes well that's great. If this will just provide results that can quieten the measurbators time badly spent.

Leave it at that.

tony wrote:Briefly from me, linear supplies and battery on the usb stick and then battery fed from linears gave improvement in tone and background noise/blackness improved.
Couple that with optimized core server and I was at a point where I couldn't see how it could improve further unless big money was outlayed trying expensive supplies etc that may have delivered nothing. I still suffered from the occasional tracks that were a bit too bright in presentation.

MQn got rid of any issue above. Soundstage and the richness of harmonic tone improved for me to a point any stuff I play sounds enjoyable. Yes the well recorded jazz albums are really incredible but vocals in even eighties favourites and Neil Young etc have as a good a sound as I think possible with the equipment I have.
Level of details which since jplay ultrastream has been really good also is just at perfection for me. A number of people have reported the same thing you can hear all the small delicate details. The double bass guy in Oscar Petersons You Don't know me is really audible.

Not sure what all your measurement stuff is going to deliver.Knowledge to help you develop and understand the effect of changes well that's great. If this will just provide results that can quieten the measurbators time badly spent.

Leave it at that.

I expect Mqn to still improve by up to 50% or at least a large amount, there are still a large amount of instructions that are being run that could be taken out and from what I have found so far these instructions affect the sound. JK might have his own reasons for trying to understand where to allocate resource to improve SQ. Then there is just curiosity, there is a so far unexplained phenomenon which we may be able to find a reason for or maybe not, but it's human nature to investigate it.

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

jkeny wrote:Yes, Nige, it is refreshing to be able to discuss these notions without fear.

Just trying to tease out noise Vs timing - is there a different type of improvement that we hear when we moved to linear supplies & then to battery? I heard increased body, solidity in the sound in your meet-up & I think this is the generally reported audible improvement with the electrical mods/tweaks. Am I right?

The reason being electrical mods/tweaks can probably only influence noise in the system - hopefully decrease it.

Are these different to the audible improvements we hear with MQN - which to me sound like more distinctness, delineation of the sound. This audible effect happens both in electrically tweaked systems & in non-tweaked systems

dont think the power mods helped timing
only noise
blacker backgrounds

micro detail because less noise to blur it
those are the things I associate with less noise

The body and solidity I associate with the power distribution
multiple power supplies

The batteries seem to be more involving but I dont know why

Pcs are well capable of making their own noise too
So less processes is welcome

MQn is probably tackling both noise and timing

but the os and the hardware play a part too

thats my guess work anyway

oh see tony got in before me
and agreeing about the blackness

were suffering the same delusion

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