It's Friday here, so here is the BIG one :-)

[PeterSt]

As promised for some longer time, differences impeeded by software can be measured. Remember, playback is bit perfect. For now, here is a small example of differences between - in this case - two settings in one player.

 

So this is it. Differences in software players can be measured.

 

Yeah, I thought to put this in bold because I think it is the first time it was done. Somewhere end of April 2009 and published here now because Chris must have been pointing to this with Something big is coming ...

Joking of course, but I thought it was worth my first thread at CA.

 

As it may be known to some here, I have been fighting myself for a longer time to squeeze out something like this, and AFAIK normal measurement equipment can't do it. So after some months of tinkering I wrote something myself.

It is all just in an early stage, and the real task is yet to come : recognizing what's good and what is not. I will be working on that the upcoming time, a.o. by providing additional analysis means.

 

Please note that this is about the relative differences between players and settings, and (so far) there is no relation to the original source (the digital WAV file). This wouldn't make much sense anyway, because no matter what DAC you have, the analogue result is miles off compared to the source.

 

Edit: Peter, I adjusted the size of the graphic and made the original visible via a link. The dots were a nice gesture so it didn't interfere with a banner - Chris :~)

 

click to enlarge

 

What you see here is (one channel of) a breaking up of sound (not explicitly noticeable, but degrading) because of a time cursor repositioning each one second. Therefore this pattern repeats every one second.

This can be unveiled at comparing the analogue output of the DAC with such a time cursor running, and without it. In this case this would be about XXHighEnd running "Attended" vs. "Unattended" (GUI vs. no GUI there).

 

To see more as per todays status, go here : http://www.phasure.com/index.php?topic=692.0;all

Peter

 

[Mr.C]

This is all a little difficult to figure out. Could you label the axis'?

 

"What you see here is (one channel of) a breaking up of sound (not explicitly noticeable, but degrading) because of a time cursor repositioning each one second. Therefore this pattern repeats every one second.

This can be unveiled at comparing the analogue output of the DAC with such a time cursor running, and without it. In this case this would be about XXHighEnd running "Attended" vs. "Unattended" (GUI vs. no GUI there)"

 

What exactly does this mean?

 

[audioengr]

Is the conclusion that when other processes suspend operation of the player stream and then resume later, that the data gets corrupted, or is this just jitter?

 

Steve N.

Empirical Audio

 

[PeterSt]

What you see on the vertical axis is the accuracy of the samples as output analogly by the DAC (RCA or Balanced Out) as compared to a reference. The reference here is playback without anything like a time cursor that moves across the screen with steps of one second. It is compared to playback that includes such a time cursor.

 

When two exact same situations are compared, the black line would be straight and covering the red line completely. No samples will be "really off" in that case, unless e.g. temperature in the DAC changes between measurements (read : recordings).

 

I said "really off" because differences always occur, with reasons like jitter, of which I think it may have a repeatable pattern by itself, but which does not have a repeatable start point. The inherent accuracy of the DAC will play a role too. Also the (accuracy of the) ADC used influences the results.

When all these factors are taken into account, hence are recognized in the first place, reliable measurements can be done, and they are completely repeatable.

 

Looking at the picture again, you see a pattern exists already before that breaking up. It can have many reasons, and in this case (for general outlay) it is the difference between XXHighEnd used with GUI (the reference in this case) and without. The without GUI operation was created to take distance from SQ at changing stuff in the GUI and/or functionalities, which at some stage was found to just influence sound. Here you can (at last !!) see it does, at the left side of that breaking up. The pattern is around 1/100 second. Notice that this pattern of 1/100 of a second is beyond my own interference; it will be the OS doing things here, since I don't use 10ms timers.

 

Once you see a nicely repeated pattern like a sine wave the picture shows, you can be sure that one of the two recordings just is flat for whatever it is the other recording incurs for. If one of the recordings wouldn't be flat, you wouldn't see a sine like "off" wave. It takes several comparisons to absolutely determine a situation to be flat, but once it is done, it has become *the* reference. This may take days to find/determine, and the software I'm working on should help minimize the analysis time.

 

Lastly, notice that this means of measuring does not make use of any kind of test files with certain patterns, but just uses normal audio tracks by your choice. This guarantees that any perceived audible difference in e.g. bass or cymbals, just can be measured. The latest version (but this is on-going) shows the transients in the graph of which I thought would matter largely on the results, but I found it actually hardly does. This may depend on the DAC though. Anyway, where it does it should be visible to you, for a reliable interpretation.

 

I hope it is somewhat more clear now.

Peter

 

[PeterSt]

Steve,

 

when other processes suspend operation of the player stream and then resume later

 

I'm not sure whether a comma or anything is missing, but assumed everything is there I don't get what you mean, or you are on other tracks than I am (which is very ok). But I'll try to have a response in the assumed context of what you want to know;

 

First off, I don't think (and never saw) that the playback stream gets interrupted. The only thing which can happen is that - when indeed it gets interrupted - the buffer in the DAC underruns (or the shared memory buffer in the PC already does). This will stall sound (hiccups etc.).

 

So it is just jitter ... ?

 

I like to have that for a conclusion when nothing else for explanations is left. It seems logic that part of it would be jitter, but it seems more logic to me that a larger part is something else. I have always said that (by empirically looking at stuff) and now being able to measure things, this idea sure did not get less.

 

In between the lines you could say I'm seeking for help here, and it sure can't harm to feed me with (the wildest) ideas.

 

If I look at what's happening, it is just samples receiving other data than they should. Now, before thinking about this in a too abstract fashion, let me tell you about practice, and what we're actually looking at. This is important for proper interpretation I think, and it may be the first reason to invalidate jitter as what we look at (official measurements) - might it be the base of anomalies or not :

 

What I can show now, for example, is that a high transient may take a 1000 samples to settle in the DAC. So, let's say I burst 2000 samples with a value of decimal +20000 while the current sample is +0, then there will be a huge overshoot, and only 1000 samples later all is "back" to the wanted value of 20000. Never mind DAC specs on settle time etc., this just is so. Or at least in my (1704) DAC this is so, and I thought I had the best analogue stage ever.

And I don't think such a thing can be shown on a scope, but possibly with some special techniques and test files it can. A digital scope should be able to show it, at reading back the recorded file. Ok ...

 

The problem is, that these kind of anomalies "flatten" anything that might be jitter impeeded. I say "flatten" while actually it is the other way around, because one spike incurred by jitter, has a huge effect on the output. That is, looking at my +20000 example above. And the point is, these things happen in real life ...

 

I found that the most apparent "excursions" - like the one from the picture" are about resettling of the DAC (might it be the DAC itself or the I/V behind it). So, I am quite sure what you see in the picture, is about one spike, and it takes a ms or so to resettle to the original value. Edit : It takes a 700ms to resettle.

What also matters (for more difficult interpretation) is that quite some preringing occurs. You can't see that in the picture, but at zooming in it shows clearly. For me this is hard to explain, but it is clear to me that exactly this preringing changes per player setting or player for that matter. It is *the* reason why aligning recorded tracks is a most cumbersome thing to do, and the "trigger" can vary a lot.

 

The only thing *I* see from the various comparisons is PSU impeeded stuff. I don't see jitter-like anomalies, I see different responses to asked for wave forms. But then again keep in mind how a "one tick" jitter anomalie can influence a huge amount of samples, while the actual cause (the jitter variance) has vanished long gone.

 

Right from the beginning I have always said I can influence the DAC. Right now I see nothing that does not justify that. My DAC can make use of a jitter rejecting SRC (it can be switched on and off) and I see no difference. Or anyway not the real difference it sould make when the SRC would eliminate all the jitter, an otherwise stupid SPDIF connection would carry. Note though this is hard to interpret correctly, just because of the SRC operating and changing the samples to begin with. So, this needs indirect comparison, and e.g. the situation from the picture would show the same with SRC-SRC comparisons.

 

Added to this, and for highly speculative further interpretation available, is that I can run my DAC on a free running clock, by itself I2S connected. So no PLL nothing. It is the best sounding mode to my ears, and any two runs of comparison with the exact same settings are incomparible. So, *this* is jitter for sure. And what does it bring ? better sound. Why ? not sure, but it makes me think the other anomalies, clearly there, are just flattened by it.

 

This principle is explicitly applied in XXHighEnd, and while it sprung from theories which are more or less proved by what I just said, this clearly works for better sound. Keep in mind, this actually makes things *worse* to the absolute sense, but in the end it will flatten the (spikey !?) anomalies. At least that's my idea about it.

Btw, this kind of appliance also can be clearly measured now (these are the Q2,Q3,Q4,Q5 settings).

 

After reading this, one may think "ok, clear, so it's the PSU doing it". Yeah, but better think twice.

Which PSU ? how ?

 

Peter

 

PS: To be clear on things : whatever situation is compared, this is a bit perfect situation for the data itself (read back by means of a digital loop back at the souncard end (RME Fireface in my case)), and no samples are lost in the process of the analogue recording, nor are they shifted along the way.

 

[Scrith]

This is an incredible waste of time, in my opinion.

 

Here's an idea: try a blind test between Foobar2000 and XXHighEnd. I'd much rather read the results of that vs. whatever it is you are ranting about, which probably proves nothing other that your test data is flawed due to imprecise measurements and external factors unrelated to the programs that were being used to transfer data from a storage device to some audio driver software.

 

 

[MahlerFreak]

Peter, can you tell us more about the system under test here? Is the DAC internal or external to the PC? If external, are you using an internal or external SPDIF interface? The pattern of "breakup" associated with the ticking clock is strongly suggestive of electrical noise from the graphics interface leaking back through the PC's PSU, or through the bus ground, or similar ... But if you're using something like a Weiss or other Firewire interface to output SPDIF, then noise from the PSU is a less likely culprit, of course.

 

Are you using any noise-reducing AC power conditioners or cables?

 

[PeterSt]

Well, if you'd know how many cpu cycles it takes to actually update one screen pixel under Vista with Aero (the whole screen is redrawn), that makes sense. But I have similar examples from no GUI there at all. It still looks in this direction though ...

 

What I used for this was :

Spinning disk SATAII -> PC -> PCI Firewire -> RME Fireface800 -> SPDIF -> PCM1704-uK based balanced DAC (super shunt regulated /w digital PSU per channel and analogue PSU per channel) -> SE (RCA) out.

 

But I will investigate my grounding. The Fireface is not galvanically separated from the PC (nor does it act like that itself, afaik).

 

Oh, no noise reduction here, which reminds me about a heating pump I can see on the mains and which I most probably am able to see through this analysis just the same (and the analysis *equipment* says I'm all clean while I can see it in the FFT, hahaha).

 

I didn't say it was easy ...

 

[MahlerFreak]

This is fascinating. Let me see if I can sum up what we think we know thus far, so that I can understand it.

 

If we play back and record the identical digital signal through an identical PC-based digital playback and recording system, we consistently get a strong statistical correlation between the digital samples in our recording. If we modify something in the software portion of the playback environment, the statistical correlation between digital samples in the recording goes way down. We are assuming, for the moment, that the change in correlation represents a distortion of one playback signal relative to the other (rather than a some factor impacting our recording or comparison environment).

 

Given that assumption, what do we know about this distortion? Two things stand out for me:

 

1. At least some of the distortion occurs in regular temporal patterns, and

2. the distortion patterns don't change with the content of the source audio signal.

 

If we put 1 and 2 together, we have an indication that the distortion is, at least in substantial part, uncorrelated with the audio signal. In other words, it is the kind of distortion we commonly call "noise".

 

Now, our computing environment is just full of electrical signals which represent "noise" relative to our audio signal. The CPU, memory bus, PCI bus, disc controller, graphics controller, and video monitor are prominent examples of subsystems that rely on "noisy" signals. Can software create such noisy signals? Yes, software does create such noisy signals; in fact, in a reductionist sense, that is how software works

 

How would this noise make its way into our output signal? Well, the noise could impact the effective timing of the digital bitstream, by modulating the digital audio clock or "blurring" the leading edge of bit transitions. Or more drastically, large fluctuations in voltage could be interpreted as false digital samples. Or, the noise could be injected into the analog circuitry of the D/A converter. Based on what we know thus far, none of these possibilities can be rejected.

 

How would the noise reach sensitive digital or analog circuitry? Either through direct electrical connection - signal interconnects or AC mains - or through electromagnetic radiation. Given the architecture of Peter's system, electromagnetic radiation does not seem a probable pathology - the digital interface and D/A converters are effectively inside their own Faraday shields. This would leave transmission through interconnect or AC main as a likely culprit.

 

It might be an interesting experiment to try measuring the noise between the "ground" side of your single-ended audio output during playback, and an entirely independent ground, and see if there are differences in that noise which correlate with different software settings? In any case, as you say, this will not be easy - but you will have the satisfaction of adding completely new knowledge to the audio community

 

 

 

 

[PeterSt]

MahlerFreak, I see you are quite serious about this all and I want to thank you for the guidance.

 

I think I am going to approach it like this : I have another DAC which *is* galvanically isolated, and I think I just can use this one to prove about everything, might it come down to transferred "noise". I have several separated mains groups (including separated ground pin), so that should do it. The connection can be the same (SPDIF behind the Fireface).

 

When I have done this, I'll report back. Can easiliy take a week, because I rather extend the recording and analysis software first. It is there where all the time goes when not optimal.

 

Peter

 

Edit : The whole of XXHighEnd was developed by using this DAC, so I actually already know what to expect ...

 

[bluedy1]

Fascinating job Peter!

Congratulations for your hard research work.

 

[Mr.C]

If it is just "noise", won't a toslink connector reject it? It might induce more jitter, but it would be a good test.

 

[MahlerFreak]

If it is just "noise", won't a toslink connector reject it? It might induce more jitter, but it would be a good test.

 

This won't do much, since the components are still interconnected through the ground lead of the AC mains. And if I'm not mistaken, Firewire connections may be galvanically isolated by design, in any case.

 

This is slightly OT, but lest anybody think that noise transmission through AC mains is an esoteric consideration, it is an accepted fact of life in the pro audio community. Basically any component which has a conventional power supply design will inject noise into the AC mains; digital components have many additional noise creation elements which will contaminate the system ground, as previously noted. The noise created by different components essentially "accumulates" as they each do their part to pollute the power supply and the mains ground. In a pro audio environment with many different components in close electrical proximity, treatment of AC mains power with power conditioners like those made by Equitech and others can reduce the measured noise floor by as much as 15-20 db. That is not a minor tweak!

 

 

 

 

[audioengr]

"Spinning disk SATAII -> PC -> PCI Firewire -> RME Fireface800 -> SPDIF -> PCM1704-uK based balanced DAC (super shunt regulated /w digital PSU per channel and analogue PSU per channel) -> SE (RCA) out."

 

Peter - what are you using to bypass the PC audio stack? Is it Vista?

 

I have had nothing but poor sound results using Fireface400 with a PC, even clocked through my reclocker. ASIO sucks IMO, so I believe the Mac is the only viable option for Firewire interfaces.

 

Also, if you think the difference might be jitter, then I recommend a good reclocker. Take the jitter out of the equation and then see what the plots look like.

 

Like my Fireface 400, your Firewire interface is async clocked I believe (has word-clock input), so jitter from the computer should not be expected to come into play.

 

Steve N.

 

[PeterSt]

so jitter from the computer should not be expected to come into play.

 

I am using Vista WASAPI (Exclusive Mode only).

Steve, there's another reason any jitter from the PC up to the receiver can't play a role I think, and this is because only related clocks can be used to do these measurements in the first place. So, the Fireface is doing the capturing, but has to provide the playback clock as well, or otherwise the samples will get out of sync (and measurement is worthless). Only jitter in the DAC itself can be part of it, but comparing with / without SRC ... it's all so much the same, that I don't think this is jitter.

 

As I said it more often, "the DAC can be influenced", and I know how to do it. But despite my own theories, so far I can't prove why it happens. I built a DAC that should be immune to it, but it is not.

 

Right today I at last could go back to an SSD (an earlier one just got corrupted several times), and this too is really something to go for. The audible difference is way beyond what we can understand. And if you'd only know I have 9 hdds mounted, but the OS now is on that SSD *and* XXHighEnd is playing completely asynchronous from memory ... yeah, WTFIGO.

 

But I can measure the differences now, so I guess we will know in due time.

Peter

 

PS: We certainly agree about ASIO. No matter what implementation (and there are many).

PPS: I have a new I/V stage coming up; I have a hunch that that will tell us more. :-)

 

[audioengr]

I think the SSD improvement may be more that just eliminating the disk.

 

I think the improvement may be due to improved compute capabilty outside of the streaming I/O or audio stack itself. Both Gordon and Victor have told customers of mine that they have experienced better audio quality just by going to a faster computer, faster FSB, or SSD. Putting just the OS into SS memory makes a big difference. Again, WTFIGO here???

 

The interesting experiment is to put the music data on a hard-drive, but the OS only into SSD and then see if if still sounds just as good.

 

Steve N.

 

[PeterSt]

The interesting experiment is to put the music data on a hard-drive, but the OS only into SSD and then see if if still sounds just as good.

 

I'm afraid that's exactly what's happening already.

 

But also take this into account :

 

1. The music data is read from a normal spinning disk, and it goes completely into memory before playback even starts;

 

2. The OS is completely dead for harddisk access (as per my own registry hacks etc., which for Vista wasn't so easy at all).

 

So no access to the OS disk anywhere, and it still makes a difference which is perceived immediately (the whole character of the music changes).

 

Peter

 

[audioengr]

"when other processes suspend operation of the player stream and then resume later

 

I'm not sure whether a comma or anything is missing, but assumed everything is there I don't get what you mean, or you are on other tracks than I am "

 

No, I'm talking about how computers work. They have lots f processes running in parallel, although they are really not all executing at the same time. Most are suspended and one is actually running. Then these get suspended and the new process runs. Instructions get cached and programs stop and resume. All the time competing for bandwidth of the I/O bus that gets data from memory or disk or other devices into the accumulators, where it can be operated on. Only DMA has guaranteed bandwidth.

 

Steve N.

 

[audioengr]

Peter - you know if you used a device like the EMU 0404, which is truly ASYNC, the computer clock does not matter and the USB cable does not matter. You could also use a Fireface400 with Firewire interface. Same thing. This would eliminate the changing jitter as a possibility.

 

Steve N.

 

[PeterSt]

No, I'm talking about how computers work.

 

I did see that post before ? what happened ?

 

[PeterSt]

You could also use a Fireface400 with Firewire interface.

 

... which is just what I am doing ...

(FF800 that is)

 

[tmfidelis]

Dear Gentlemen:

 

Many of the experiments you are suggesting I have demonstrated to local component level engineers and music mastering engineers for the past two years.

 

8 digital work stations.

6 SSD drive.

Hard drivers.

NAS drives.

OSx 10.4.1.1 and Leopard

Zalman and Dell XP based computers.

G5s

Mac Pros

Media Monkey

Sequoia Digital

Wave Lab.

SoundBlade and Amarra.

iTunes.

A plethora of 24-192 DACs

Firewire and Lynx hardware I/Os

Analogue running master tapes.

DDP files and direct transfer from analogue to 176.4k and 192k

32-bit float files.

 

Regards,

 

 

 

 

[PeterSt]

I am sorry, but you didn't forget the outcome or conclusion ?

Probably not. But now I don't understand !

 

[tmfidelis]

No apologies needed, thank you. Generally all the A/B comparisons are consistently audible and for the most point, interpreted with consistency, even using different clocking methods. Defining the cause for the differences is extremely difficult. Some things are clearly easy to define such as measurable added noise over the AES cable due to p/s of various computers. The sonic signature of drivers is very difficult to measure. I forgot to mention I also work with C++ programmers writing drivers for OSx and Lynx. I'm informed jitter is extremely difficult to measure and perhaps what we hear is also a matter of redistributing jitter.

 

Great to know you guys are spending your valuable time trying to sort this out.

 

Regards,

 

[PeterSt]

Ah, now I understand. And at reading back your first post ... it's just my english.

 

and perhaps what we hear is also a matter of redistributing jitter.

 

Yes. For a more normal explanation, this would be hard to measure (I think). But a first thing which springs to my mind opposed to this, is that any normal measurement won't include any influence like I showed in the picture. A PC wouldn't even be involved !

... And once it is, normal measurement can't be done because the clock normally provided by the measurement device can't be the master, and nothing else but very indirect comparisons can be in order.

 

What we see, I think, is only subjective to PC playback ... although CDPlayers would be subjective to it too, but more consistently. With a more close pattern perhaps. More similar over CDPlayers throughout.

I now think this is the reason why software players can show such an inconsistent behaviour on SQ (over tracks and albums), perform so much worse compared to CDPlayers, or do so much better.

 

Oh well, we'll see.

Peter