Tír Na HiFi

Peter Stockwell wrote:

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 ?

sbgk wrote:

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.

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

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

sbgk wrote:

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

jkeny wrote:

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.

erin wrote:

jkeny wrote:

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.

LowOrbit wrote:

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

Isn't that called Foobar?