Tír Na HiFi

This is a split off thread relating to questions about testing differences observed by users of different versions of MQN.

The idea is to remove discussions about why it works/sounds as it does from the main MQn users thread.

Keep it clean, as it has been up to now - no trolling.

Circular arguments, well,that'll be a paddlin'

Trolling, yup, er that'd be a paddlin' too.

Combative prove it posts, oh they'd definitely be a paddlin'.

Yup we like a good paddlin' round here. Gives the mods something to do.



Fran




Now on to Jkenys post which I think marks a good spot to start this discussion:




In order to try to bring some order & like for like comparisons in our evaluation of MQN Vs other players or evaluating the sound between the different versions of MQN could we try to settle on using some track excerpts that we can all use to specify the differences we hear.

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. I can hear this through my generic earbud h/phones directly from my netbook's audio out (HP, AMD CPU, SSE2). This is subtle & has to be listened for but it's effect is distinct & audible. Once the ear is keyed into the effect of this timing issue it becomes more easily identified in other tracks.

The thing is it is more noticeable in some tracks than in others. The track that I use & find it most noticeable on is the Oscar Peterson track 03 "My One & Only Love" - probably because it has lots of notes :) - the piano playing is fast (allegro?). With MQN I hear a very distinct & realistic rendition. With Foobar it is just that bit more indistinct. I'm happy to provide a 30sec or 1 min download link of this track (I don't think this breaches any copyright laws, once it is for research/educational purposes, right?)

What do people think of this as an idea for having a couple of excerpts of reference tracks that they have found the most noticeable differences with & that others can then do their own evaluation of?

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

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

There is more than just timing IMO. I think noise level is somehow down comparing to the other players which brings more details, more air between different lines, less harsh on highs, more texture on the base, and so on. It is hard to say why and how without understanding the facts, but I can certainly hear those differences, and they are significant enough to me to use MQn. I'm not even trying to understand it, I just enjoy it. I will let other experts to measure it and to figure out what exactly those bits are doing under SBGK's control.

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.

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.

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.

I guess real time would be the best, MQn runs on it's own core and is boosted by MMCSS, the IRQs and other activities on that core could be allocated to another core for more real timeness. With modern GHz chips the difference between realtime and scheduled is a moot point (nearly said mute point).

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.

no doubt its hard to believe in the windows environment,
like youve stated above playback is open to interrupts
thats why the efficiencies of the player and the os come into good effect
as with minimising using server os's, core, setting irq priorities and running scripts to disable services seem to have a positive effect on the sound quality.

Granted there are better os's for the job even a playback only os,
where would you even start to do that
windows was the easier option

like the thought of a minimalist linux MQn, another compromise but an achievable goal

but its easier to believe if you can hear the difference between players

dunno how it will sound on your "beast" of a pc as its a very busy board,
but i think youll be able to hear the difference between players

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

I guess real time would be the best, MQn runs on it's own core and is boosted by MMCSS, the IRQs and other activities on that core could be allocated to another core for more real timeness. With modern GHz chips the difference between realtime and scheduled is a moot point (nearly said mute point).

With the relatively slow transmission rate of audio (assuming 44.1KHz), the 'realtimeness' of the OS responses probably isnt an issue considering the GHz chips as you said.

I still cannot see though how MQN could affect timing. Im assuming what John is referring to is the timing of the signal along the cable to the external DAC beit over an SPDIF or coax?

In the past I've implemented both SPDIF and I2S transmitters both on an ASIC and FPGA, one of which ended up in the original Xbox console. There was also SW running on the chip also. The PLL feeding the transmitter is controlling the timing of the samples along the cable and as long as the SPDIF block is being handed the samples from a buffer you wont get any dropouts. This is all handled at a hardware level.

In this situation, MQN exists in a software layer, several layers above a bunch of other software, correct?. Perhaps its the randomness of the MQN/SW filling the buffer that in turn feeds the SPDIF transmitter that is at issue here? (Even though it always provides enough samples for the transmitter to work on)

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.

In this situation, MQN exists in a software layer, several layers above a bunch of other software, correct?. Perhaps its the randomness of the MQN/SW filling the buffer that in turn feeds the SPDIF transmitter that is at issue here? (Even though it always provides enough samples for the transmitter to work on)

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.

Dave

The usage scenario with MQn is mostly via USB, using the asynch protocol, so in theory I think the DAC interface is driving the demand for packets from the USB bus, which in turn is pulling samples into the buffer from the Wasapi service (it gets so complicated in Windows at this level, so I could be off beam). At some level MQn is providing those samples to the WASAPI service.

What is really unclear to me is at what point the samples get turned into USB packets, which are formatted according the a generic UAC spec and contain headers and all the usual network layer stuff. My assumption is that the cpu does that packing and formatting because it has access to the relevant data and gets the interrupts from the USB interface coming in from the DAC. And we talk about Wasapi as an entity when in reality it is just more cycles on the CPU.

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