Tír Na HiFi

jrling wrote:

jrling wrote:Saw this article over on CA (sorry SBGK!) -
http://www.computeraudiophile.com/conte ... omparison/

Mitch was using readily available tools to do pretty much what we would want to do with MQn by the looks of it. However all in the digital domain and perhaps therefore beyond the limits of the software to detect minute differences? He was comparing JRiver on Windows with JRiver on Mac so perhaps there are actually no differences in that comparison.

Anyone think his approach would work for our experiments?

Jonathan

Sorry if I am being a bit dim, (again!), but isn't jkeny's suggestion very much the same as this approach by Mitch? Although he uses a real music file which one would think is more valid than a test file. It does use readily available software which LowOrbit may already have?

For me the flaw in Mitch's approach is - at least I infer it is - that he records the output back to the same computer he is generating the replay from, so the processor is doing even more work than normal. If your argument is that bits are bits and computers are really fast so it makes no odds because playback is simple, then it makes no difference to you. You may as well play Call of Duty with all screen effects turned on at the same time.

But other than that his methodology seems to be along the right lines.

There is no more validity in playing a music file than a test waveform. The test wave gives you a known and ideally simpler thing to compare. We are probably hunting for a little needle in a big old sonic haystack.

Mark

jrling wrote:

jrling wrote:Saw this article over on CA (sorry SBGK!) -
http://www.computeraudiophile.com/conte ... omparison/

Mitch was using readily available tools to do pretty much what we would want to do with MQn by the looks of it. However all in the digital domain and perhaps therefore beyond the limits of the software to detect minute differences? He was comparing JRiver on Windows with JRiver on Mac so perhaps there are actually no differences in that comparison.

Anyone think his approach would work for our experiments?

Jonathan

Sorry if I am being a bit dim, (again!), but isn't jkeny's suggestion very much the same as this approach by Mitch? Although he uses a real music file which one would think is more valid than a test file. It does use readily available software which LowOrbit may already have?

I didn't read it carefully but is he playing the audio file through Jriver & recording it through Audacity on the same computer simultaneously?

As confirmed on the Lynx support forum, the audio bitstream is going from JRiver, through the ASIO driver, through the USB cable, into the Hilo, and then clocked back out the Hilo, through the USB cable, through the ASIO driver, and into Audacity.

Apart from the fact that Audacity is running while Jriver is playing (which might effect the noise spectrum?) is this pass-through feature the same as the DAC converting to analogue & then recording the analogue signal i.e (the noise may only enter the system at this D to A conversion step)? Is this passthrough simply routing the digital file from DAC input to an output port back to Audacity?

I'm only asking these questions - I don't know the answer.

Edit: The above point in bold may well be significant.
Also there is a possible difference between a test signal & music - if the noise is a result of the CPU handling a dynamically changing bit pattern (as SBGK has hinted at) then we may not see any issue with a well controlled test signal - it may require the dynamic shifts of music to reveal it.

If your argument is that bits are bits and computers are really fast so it makes no odds because playback is simple, then it makes no difference to you. You may as well play Call of Duty with all screen effects turned on at the same time.

is definitely not my approach!

I take your point about one PC. But offloading the output from MQn along a transmission chain to another PC measurement device, potentially adding masking 'noise' is also not ideal?

Accepting your point that the PC will add noise through having to work harder, surely, if it is a constant added noise, if we are playing the same WAV file but just with different MQn versions, then could we accept that it is comparing 'apples with apples'? Admittedly the additional noise could be what broke the proverbial camel's back and the needle will be lost in that haystack!

LowOrbit wrote:

DaveF wrote:I've been away for the last couple of weeks so just catching up on the last few pages.

Even if we manage to come up with a valid and repeatable measuring technique, we're still only gonna be measuring at the output of the DAC or amp. We musnt forget that we have the additional stage of the electronic crossover in the speaker and the mechanical responses of the driver/cones.
I guess my point is that even if we managed to find differences within the noise of different MQNs, they could well be "swallowed up" or not revealed by the speaker thus making them inaudible. Now I dont know much about proper speaker design but I'm guessing that ideally a very accurate studio monitor would be required here.

The ultimate solution would be to somehow measure at the speaker output but as a starting point, measuring at the DAC is probably easier.

Dave

Ignore the amps and speakers and room. They would be the same (in any given system) whichever player we used. And - allowing that we do hear a difference between playback software versions - we can assume the speakers are good enough to let that difference through.

Capturing at the DAC output removes any speaker/room issues and also removes any possible issues of microphone placement, background noise, power amplifier distortion and so on.

Mark

hmmm I'd be careful of making assumptions in the world of testing and verification.
It may well be that certain versions of "MQN generated noise" are getting through the speakers and some are not.
If we can correlate between what noise is really audible (i.e not filtered out by speakers) and what code construction was used then it might give a clue as to what exact coding style or what type of movement of data with the processor gives rise to such audible affects.

jkeny wrote: Also there is a possible difference between a test signal & music - if the noise is a result of the CPU handling a dynamically changing bit pattern (as SBGK has hinted at) then we may not see any issue with a well controlled test signal - it may require the dynamic shifts of music to reveal it.

Good point.
Instead of a music signal, how about creating a test pattern such that each bit toggles from one sample to the next or by making the DAC go full scale to half scale and to near zero in successive samples.
This would be giving the internal buses of the processor and PCB buses more work to do thus generating more noise or switching noise.
Obviously you dont want to play such a pattern with speakers and amps attached. :-)

DaveF wrote: hmmm I'd be careful of making assumptions in the world of testing and verification.
It may well be that certain versions of "MQN generated noise" are getting through the speakers and some are not.
If we can correlate between what noise is really audible (i.e not filtered out by speakers) and what code construction was used then it might give a clue as to what exact coding style or what type of movement of data with the processor gives rise to such audible affects.

DaveF, I think you are posing too difficult a test including speakers, room nodes, background noise etc. given the low level noise that we are looking to find. Even moving the recording mic 1 inch can change the whole spectrum of the signal, not to mention the background ambient noise constantly changing.

DaveF wrote:

jkeny wrote: Also there is a possible difference between a test signal & music - if the noise is a result of the CPU handling a dynamically changing bit pattern (as SBGK has hinted at) then we may not see any issue with a well controlled test signal - it may require the dynamic shifts of music to reveal it.

Good point.
Instead of a music signal, how about creating a test pattern such that each bit toggles from one sample to the next or by making the DAC go full scale to half scale and to near zero in successive samples.
This would be giving the internal buses of the processor and PCB buses more work to do thus generating more noise or switching noise.
Obviously you dont want to play such a pattern with speakers and amps attached. :-)

Ah but that's assuming we know what bit patterns give us noise modulation (if this is what we're looking for) & we've no way of testing this other than listening to the analogue output. We can hear the audible difference with music.

I think trying both would be worthwhile - a music signal test & a signal test pattern test

jkeny wrote:DaveF, I think you are posing too difficult a test including speakers, room nodes, background noise etc. given the low level noise that we are looking to find. Even moving the recording mic 1 inch can change the whole spectrum of the signal, not to mention the background ambient noise constantly changing.

Yeah, I have to say I'd be more convinced by comparisons of DAC output than any in-room response. I would have thought it would be "simpler" to identify and interpret differences there too. If bits aren't bits, then this is the first place we're going to see evidence of that fact. If bits are bits, and all players give identical outputs from the DAC, well then...

jkeny wrote:

DaveF wrote: hmmm I'd be careful of making assumptions in the world of testing and verification.
It may well be that certain versions of "MQN generated noise" are getting through the speakers and some are not.
If we can correlate between what noise is really audible (i.e not filtered out by speakers) and what code construction was used then it might give a clue as to what exact coding style or what type of movement of data with the processor gives rise to such audible affects.

DaveF, I think you are posing too difficult a test including speakers, room nodes, background noise etc. given the low level noise that we are looking to find. Even moving the recording mic 1 inch can change the whole spectrum of the signal, not to mention the background ambient noise constantly changing.

oh I'd agree. As per an earlier post I was proposing this as the 'ultimate' test setup but yeah it would be very difficult to do. Perhaps doing it in a well controlled studio with damping and so on.
You then have the 'problem' of measuring the speaker output which probably brings recording equipment back into the equation and that would smear the results or conclusions I think.

Diapason wrote: If bits are bits, and all players give identical outputs from the DAC, well then...

....go on. ;-)