Playback Engines

is,

you shouldn't be alarmed by your own thinking about playback engines, you're most likely still in the majority opinion. On the one hand, we have this belief by the majority that if digital data is presented bit perfect to the DAC then no differences should exist if another player presents the same data bit perfectly to the same DAC.

On the other hand, we have folks (engineers, both hardware and software) here on CA telling us that things can effect the eventual sound. For example, Peter (software developer of XX High End) has found changes at the output of his DAC that correlate directly with user interaction with the software player. Gordon Rankin (pioneer of Async USB DACs) goes so far as to say 'everything matters'. That would seem to be the other end of the continuum.

Somewhere in the middle, truth lies, although increasingly the evidence suggests that factors other than bit perfect data do matter.

I believe that at least one of the reasons Chris put together his symposium was to expose this (previously) fringe thinking more effectively to the public eye, in a way that skeptics would have to stop hiding behind statements 'it just isn't possible'.

I'm still not sure if people understand why something like Amarra sounds better, but judging from the results at the Symposium, many more now believe that it does.

One thing seems clear, a high resolution system certainly benefits more from these 'improvements', e.g. SSD versus spinning disks, same as it's always been.

Hopefully, Chris will report on the themes that were well received at the Symposium that were/are rather more controversial in the absence of direct experience such as Chris' event.

Hope this helps,
clay

It appears that there's more to it than "bit-perfect". Over AA people are harping over that Amarra must be manipulating something if the differences are that dramatic and it must doing something to the bits. People hear differences between SSD and a convential spinning hard drive. The bit-perfectness has not changed, only the medium holding the data, yet there appears to be differences in the sound.

There were many releases of cPlay, the DIY memory player, where the bit-perfectness had not changed between releases, yet minor changes in code affected the sound. Even different motherboards apparently sounded different.

If switching power supplies inject "noise" yet don't affect bit-perfectness, then why do some people hear differences by using a linear power supply?

It appears to me, that we don't fully understand all the variables that can affect the sound and bits is bits argument is just one piece of a complex puzzle.

Hi,
thanks for your responses - I'm extremely interested to hear that people have measured differences ( Peter with XXHighEnd ), but I can't seem to find anywhere that has these? Or any measurements that the data is bit perfect?

I tried to use the demo version of XXHighEnd, but only playback engine 1 worked for getting any audio out of my laptop, and it seemed very similar to me to WMP/iTunes

Another aspect to the puzzle I find even more confusing is that the PC-based approaches ( cPlay, cmp etc ) seem to attempt to reduce CPU load, but as I understand it using Amarra on a Mac iTunes both iTunes and Amarra play back the audio, but the iTunes output is muted - this is surely increasing CPU load?

your friendly neighbourhood idiot

the idiot :-) wrote... "thanks for your responses - I'm extremely interested to hear that people have measured differences ( Peter with XXHighEnd ), but I can't seem to find anywhere that has these? Or any measurements that the data is bit perfect?"
A few references I can find quickly...

Peter's original graphs were posted on the CA Forum a while ago - without rehashing old discussions he compared the output of his XXHighEnd software when using the GUI vs CLI. The thread I just linked to was the main discussion and it was also brought up in another thread. I don't recall any further testing or comparisons.

That I know of, there have been two documents published (external to CA Forum) regarding "bit-perfect" and confirming that iTunes is bit-perfect. The first, discussed here was published by dCS, a UK Manufacturer of DACs and related digital audiophile equipment. Bit-perfect in the case of the dCS artical is considered to be avoiding sample rate conversion. There are some legitimate negatives of this dCS article in that it wasn't mentioned what equipment was used and a couple of errors regarding availability of WASPI implementations under Windows Vista - the CA thread discusses these more.

The second is written by Kent Poon - the respected musician and producer (think he's both), creator of the Jazz Prologue series. It was discussed on CA Forums here. The Kent Poon article does note a problem with High Resolution files with iTunes under Windows (using version 8.1.1 IIRC), but shows the digital output of iTunes on MacOS to be perfect and perfect under Windows for CD resolution files.

Neither of the latter documents mentioned actually claim that bit-perfect equates to sounding the same at the output of the DAC.

Hope those links are helpful to you.
Eloise

Eloise,

thanks for the references, I shall have a look at these in more detail. The XXHighEnd measurements look, on first sight, at least very interesting, although the lack of scales on the plots doesn't help, and Peter's english make it hard for me to understand what's going on - I would find it hard to believe that if he's claiming the output to the DAC is bit-perfect, then the output would be corrupted like that without something very funny going on! Additionally, this kind of corruption would not indicate to me problems in the "audiophile" realm - that of imaging, transparency, fine detail etc. - it looks like the output being just broken ( crackly, etc ).

I shall look further into this, together with the two extra papers you mention,

your friendly neighbourhood idiot

Reading through the large number of posts on the performance of Amarra and other playback engines, on this site and on Audio Asylum, one aspect struck me: the potential influence of the computer operating system on the quality of playback. Contributors noted that the sound from playback engines produced for the professional audio community was typically better than that from iTunes - it was surmised that the former software went to great lengths to minimise any effects of the OS. As all modern OS always run multiple threads (most of which are buried in the system) this could be a complex task.
This started a train of thought: rather than complex, expensive software are there any other ways that the effect of the OS can be minimised?
(1) do not use a computer (!!!). Not so silly as it sounds; the music data could be dumped in memory (SSD) and played back to a 'hardwired' DAC. You could argue that this is what PS Audio PWT achieves.
(2) use a minimalist computer. Ideally non-multi-tasking, but it could be a stripped-down unix box dedicated to audio playback.
(3) use a bridge (wireless or ethernet). The data is transmitted in packets and hence the receiver will be isolated from any OS effects. [The sound quality from my AppleTV running Airtunes is very good - it matches what I get from an MF CDPre24 pre-amp/CD player - so it must be doing something right.]

The question of retaining bit-perfect audio data always struck me as an irrelevance - as stated cogently elsewhere, audio data is no different from other computer 'data' including all software code. If the latter was not bit-perfect our computers would be crashing very frequently! So much was being made of this on forum threads that I did my own checks: I re-ripped a CD I ripped to iTunes 2 years ago but used different software and encoded at a different bit depth, 24 rather than 16. I read the new file into Peak Pro, truncated it to 16 bits (without adding any dither) and did a file comparison bit-by-bit. The 2 files were identical.

David

David, the 2 files may have seemed identical bit-for-bit but did they sound the same? Sounds like a silly question I know but now that bits seem to have acquired some strange quantum/mystical properties that allow them to remember how they were treated in history, who knows?

- John.

Hi,

I've just read the two articles stated by Eloise ( the dCS one and the Kent Poon one ). There are a couple of interesting things here - firstly, the dCS paper mentions some hidden resampler within iTunes on Windows, accessed by control panel - is this the thing that is messing up Kent's playback of everything but 44.1 on iTunes on windows? Secondly, as I read it, the dCS paper doesn't equate bit-perfect with no SRC - they state on the XP measurements that there is no SRC, but it is not bit perfect ( but may be OK ). They DO state that the SRC within Vista seems unfeasibly broken, though.
Reading your linked thread, doubts appear to have risen over the dCS paper - has anyone contacted dCS about the equipment used, etc?

As for the later points, nobody is questioning that the audio can be stored and retrieved without corruption - rather the question is, can this data pass transparently through the assorted audio stacks and mixers on a typical PC/Mac platform? Both the papers here suggest so, given some caveats, which is at odds of some statements a few months ago ( only a Mac can be bit-perfect/K-Mixer is in league with the devil, etc ). It seems to me that we must establish that the playback engines are generating the same output data before we can start discussing how otherwise they may be different.

I'm still trying to make sense of the XXHighend measurements :(

your friendly neighbourhood idiot

idiot (always makes me smile typing that - feels sometimes like I'm writing to myself :-)

As you say, there is no reference made to the test kit used for the dCS paper. They do say it was a 24/96k capable interface so I would think it's pretty safe to assume they would be using the top end dCS kit - i.e. (async) USB into the Scarlatti Upsampler, then FireWire (not computer capable) out to Scarlatti DAC - with the Master Clock it's close to £30,000 IIRC.

Eloise

Hi Eloise,

Now all is out of focus anyway ...

That I know of, there have been two documents published (external to CA Forum) regarding "bit-perfect" and confirming that iTunes is bit-perfect. The first, discussed here was published by dCS, a UK Manufacturer of DACs and related digital audiophile equipment. Bit-perfect in the case of the dCS artical is considered to be avoiding sample rate conversion

This is one of the (implied) problems I have with that article. It doesn't deal with bit perfect at all ... it deals with resampling, but implies that bit perfect is the same. It really is not as you know, and therefore the context anyone uses the article in, is wrong rather quickly.

FYI (keep it secret) I may add that if you play 16/44.1 on Vista (outside ASIO and WASAPI), with the output settings set to just that, Vista will upsample to 96, and back to the wanted 44.1.
This is completely contradictionary to what the article says, which (for me) obviously has the main flaw that the one who measured there doesn't know how to. It has been said more often I think, but those who manage to let Vista show worse than XP, must do something wrong.

Didn't Daniel Weiss make a same huge mistake ? yes he did. Is that bad ? mwah, as how it turned out not.
BUT :
Once you're into these matters, and you see those graphs, you must scratch your head and think as long as it takes to find out what *you* are doing wrong. Only (and this is my implied statement) when you are not so much into the matters at all, you believe your own crazily out of line measurements ... and publish them.
Or you must have a second agenda of course, which at least I do not dare to say in either situation.

Best,
Peter

What I showed for measurements is only one small tiny piece of data, showing that things change at the analogue output, while looping back the input digitally shows a 100% same file. Actually it is as simple as that, and it just proves that what we may think we hear, is so (for differences anyway).

I didn't proceed on it further because for me (back then) it was enough to prove this, at talking about these kind of measurements endlessly (here at CA too), and in fact I'm still out of breath a bit because it is not easy at all to create the software for it.

I may be repeating, but what I do is this :

- Loop the analogue out of the DAC to the anaolgue in of an ADC;
- Record that.
- Record that again, and compare to make sure that both resulting files are EQUAL, hence the procedure (software) works.
- Change settings, or change player, and record it again.
- Compare this result with the first, and notice the differences all over (not a few small spots, but all over.

It is really that easy, and no matter what small change of setting in XXHighEnd (ok, *meant* to change sound !), or what other payer is used, the results are always different.

If you still have that crazy ("breaking up") picture in your mind, try to imagine that this wild "break out" (which is still measuring bit perfectly !) can be compared with two subsequent recordings just the same. The result ? always equal.

As said, that picture is just one example out of unlimited more, and I used it because I could explain what's happing (when the time cursor moves the whole screen gets repainted because of the aero appliciance in Vista). But other settings create even more wild excursions and I can't see where they come from. But here too, and no matter how wild or what situation, it is always exactly repeatable (hence two subsequent recordings of the same give a flat line).

The creapy thing is, that while two subsequent takes are always the same, it is so hard for me to believe it is jitter impeeded. I mean, I'd say that jitter is not repeatable in the absolute time domain. But maybe it is ... (but then it's my guess I'd always be looking at data jitter only).

When I have some time again, I will be presenting (many) more examples.
Peter

Hi Peter,

You must be reading a different document to the one linked to by Eloise - the one I read says if you set up iTunes incorrectly, it does that ( 44.1->96->44.1, page 8 ).

As for the bitperfect stuff, it says, and I quote, page 7 : "Closer examination reveals that using WMP11, with the system sample rate set to the same as the file, it is now bit perfect" - Closer examination says to me that they did some other tests to verify it being bit perfect. Or maybe I'm being an idiot again, it's hard to tell sometimes. It is true to say that if an SRC is involved, the output is definitely not bit perfect.

As for your assertion that Vista resamples to 96 then back to 44.1 without using ASIO or WASAPI (e.g. using WMP11 ), do you have a graph that contradicts the dCS one on page 7?

I would also be interested in your implied agenda here - don't dCS make USB interfaces? Surely them pointing out that the PC can muck up the sound isn't a good agenda for them to follow, ESPECIALLY, if, as Eloise asserts they were using their own products? Or are you saying that dCS have some secret playback software in the pipeline to "fix" these problems?

your friendly neighbourhood idiot

I have a theory that will explain why the issues in the document are not important for it's target market. I think one of the problems with (our reading of) the dCS paper is that it was never intended as proof that iTunes, WMP, etc all sound the same because they are "bit-perfect", only that with care, a computer can be a viable source into the dCS Scarlatti Upsampler. As I've also acknowledged, there is a big flaw with reading the document as a scientific white paper in that there is no description of how the tests were carried out, if the output of the "audio device that has a maximum capability of 24/96" was measured in the analogue or digital domain and what hardware was used for the tests (though I think it's safe to assume that as far as possible dCS devices were used).

In the summary, it's said "The document is intended to illustrate that audiophiles cannot just assume that the PC will generate bit-perfect output without checking settings, and that setting up the PC incorrectly can result in severe audio distortion. [...] If the user does not check the sample rate being used, performance can be extremely compromised with little indication of extra processing being applied." Now within the paper there is no indication as to who the document's intended audience was, so I'm going to make an assumption that it was aimed at dCS dealers.

It's only quite recently that dCS released the Scarlatti Upsampler and Puccini U-Clock devices which include an asynchronous USB interface. The dealers who are used to handling dCS products are (in most cases) unlikely to be used to computers as audio sources - they're not Computer Audiophile fans. They are used to selling Turntables and CD players - possibly separate transports, DACs and upsamplers, etc, but not setting up PCs. A customer comes in and buys a Scarlatti Upsampler and finds it has a USB port so buys a cable and "gives it a go". They come back and complain that the result is crap and not a patch on using the dCS transport. This document helps these people.

Having said that, although dCS also want to sell their (incredibly expensive) CD/SACD transport - which I guess is where Peter's accusation of hidden agendas comes from. However they also don't want people moving away from them because they want computer audio source, so they obviously have faith in the fact that iTunes, etc. can provide a "True High-End Source".

I don't doubt there can be variance in the sound from different software - there is too much anecdotal and subjective evidence to say otherwise, but the is also no doubting in my mind that the variations are not down to non-bit-perfect reproduction, but down to other (so far unexplained) factors - otherwise things like SSD vs HDD wouldn't come into it. There is no doubting that the data read from a SSD is the same as read from a HDD, but somehow there is still a difference weather due to variations in the speed of reading, etc. Until I have time / money to buy a high end DAC with transparent power amps and speakers, to buy several identical computers with small variations (i.e. Lynx AES16e in one, AES16 in another, EMu 1010 in a third) and carry out testing; I have to rely on other people's testing/evidence and judge it based on how they document it, the quality of their language (unfortunately Peter English being your second language sometimes your posts are difficult to decipher) and the background of the people/companies involved. Yes everyone has some form of agenda, whether to sell hardware (dCS) or software (PeterSt / XXHighend)

Finally, Peter wrote... "FYI (keep it secret) I may add that if you play 16/44.1 on Vista (outside ASIO and WASAPI), with the output settings set to just that, Vista will upsample to 96, and back to the wanted 44.1. This is completely contradictionary to what the article says, which (for me) obviously has the main flaw that the one who measured there doesn't know how to. It has been said more often I think, but those who manage to let Vista show worse than XP, must do something wrong. Can you tell me where this information comes from as I've never heard it said before. I don't disagree with you though that Vista's SRC should measure better than XP's.

Eloise

Edited for clarity

Peter, what's your theory?

Peter, I have no doubt of the authenticity of your tests but rather than see more of them I would love to hear your theory as to how these results can manifest. How can a DAC respond differently to two identical bitstreams? There are 3 logical possibilities I could imagine:

1. DACs are random, not Deterministic, in operation. However, you seem to have established a pattern so let's rule this out.

2. The DAC 'knows' what happened before the bitstream arrived. This requires the bits to carry information beyond their binary state, presumeably at some sub-atomic level, and moreover to 'communicate' this to the DAC. It also requires the DAC to care about this. This is beyond physics and implies sentience; it is too ridiculous to countenance.

3. Something other than the bitstream has an impact on the DAC. This could be electromagnetic or radio or telepathic interference for example.

What's your theory? Even if the differences are real and provable, we cannot take advantage of them without a theoretical model to work with. Any ideas HOW this could be happening. Thanks.

- John.

hahaha, start laughing. I already did. This one is for fun of course and not for debate. If I write this :

Or you must have a second agenda of course, which at least I do not dare to say in either situation.

... two different people immediately read this as the explicit other way around.

Is it my tone of voice ?
Do I tempt you to read this wrongly ?
Is it that the internet skips "not" in this case ?

If I say NOT I mean NOT. Or otherwise the "not" wouldn't have been there.
So in this one special occasion, could both of you (ah, one is enough) please explain to me where this one went wrong ?

Ready to learn !

John,

I'm not Peter, but I'll throw in a few words here anyway.

It's not clear yet WHAT might be causing different sources (player software/hardware/OS) to sound different.

Being a software engineer, not an EE, I can admit to haven taken some time to come around to the idea that there's more than bits that can make a difference. Gordon Rankin says that everything matters (these words are a gross oversimplification).

The question is: HOW does everything matter. Not being an EE, as stated, I'm envisioning a steady stream of ants marching deliberately to their goal (delivering a sample). It's not difficult to envision that some in the long 'train' are also carrying bits of food or leaves (noise, and ???). It's also not difficult to imagine that upon arrival, some get mischievous and stray off into the surrounding area, to eat their food and leaves.

We've heard that the Matan server sounds as good as Amarra and learned that the Matan Server is built on the idea of isolating the playing hardware from the delivery hardware (which connects to the DAC).
Others, notably John Swenson, have proposed this idea. Indeed, many refer to this as a 'networked' player.

If the issue was simple electrical isolation between player and DAC, one would think that Toslink would be the queen of the interfaces, instead of the ugly stepsister. Perhaps Toslink does eliminate some/many of these so far unattributable factors, but can never reduce jitter enough that the reduction of these other factors (whatever they are) is noticeable. Matan is using fiber optics, and has developed it's own proprietary protocol, perhaps in lieu of an improved Toslink specification.

How do different players affect the sound, even when housed within the same hardware? that's even more of a mystery to me. Obviously they would interact differently with the hardware - one could easily believe that the minimalist approach (in player software) might leave the least footprint on the electro-mechanical environment, but then, why would Amarra sound better, as it reportedly improves steadily up to 8Gb of RAM (which is quite a large footprint, or maybe spreading things out over 8Gb lessens the impact)?

clay

None of your three points of course John. Okay, you knew that.
The whole point (and I called that creapy) is that this can only be impeeded by one thing only (as far as *I* know) : jitter. Bu then (at least this is what I think) this can be data jitter only, being the only plausible explanation for
a. The being 100% repeatable of it all;
b. The sole fact that different settings (or different players) show a difference to begin with (those differences being as repeatable).

Further, as a base for this only possibility - jitter (and I'd better call that data jitter now) are many other environmental things, always related to power (better call that current). These things have been addressed by me in this forum somewhere, but instead of pointing to that, this time I'd like to paste in two posts from somewhere else, the second one being a copy of the post in here I just referred to. What you will read is important for myself, but just might be important to all of us, because it just might hold the truth.

The first post is from AmirM aka the head designer of Vista's audio engine, by now not working at MS anymore. Some people may know about a long thread on AVS where Amir explained about the new Vista audio facilities, which was a nice thread until page 5 or so when I jumped in and a "fight" went on throughout the thread. This fight itself is totally unrelated to what we are talking about here, but fact is that this was initializing my development of XXHighEnd WASAPI's engine which in fact was a proof of ignorance because I said it couldn't all work as easily as Amir tried to put it, but did it anyay, was the first to have it going, while right now the others are still struggling with it for some sample rates. Is this then important ? yes, I think it is. Why ?

Back then (2006) people weren't talking about software making a difference for SQ, but I did. Now, WASAPI was supposed "the one and only solution" to get rid of not-bit-perfect (as MS stated it), while IMHO this wasn't even important and other things were (at that time for me to prove). Let's say that by now we know more (say you all just start to believe in it since the Symposium notes), and by now we're merely up to the why.
Well, no matter the fights I had with Amir I think he is to be respected, and when he has ideas about something, they just might be right in the first place. So, here is his post about this, which nicely says exactly the same as what I said about it (second post), but try to keep in mind that my post (originally here at CA) was there quite some weeks earlier. I only want to say that it is not that I went along with his words or whatever, but we just both agree in full about this (or he has copied my words hahaha).
Btw, the question here was : Why do different bit perfect players sound different ? and it was indirectly asked to both Amir and me.

(keep in mind that all of the below is a copy paste from somewhere else or otherwise it will get pretty confusing)

Post from AmirM

OK, I better answer the question before someone else does .

Please note that what I describe is the theory behind the differences. Whether they exist in practice, is another question (which is impossible to answer).

To get started, we need to dig into some fundamentals. Nyquist tells us that if we sample an analog signal at twice its maximum frequency, we can reproduce it perfectly, given appropriate filters at both ends. What gets lost in this is that this is only true if the source and destination samples have identical timing. Variations will cause distortion and the output signal is no longer a reproduction of the source. This is where jitter comes from. Timing variations at the point of digitization and playback will cause distortion.

Second principal is to understand what causes jitter. Every digital audio stream has a sampling/input rate. The system has a “clock” which generates the “ticks” which cause the digital to analog converter to output its sample. In theory, the clock frequency is exactly the same as the sampling/input rate. In practice, the perfect clock cannot be built. The timing of the ticks will change, sometimes a bit slower, sometimes a bit faster. This is of course the definition of jitter.

So what causes jitter? Well, unfortunately just about anything. Every electronic circuit, like the D/A clock has a voltage source to power it. If I took that voltage and changes it slightly in value once every millisecond, the clock accuracy will change once every 1/1000 of a second. We call this a jitter with a frequency of 1 KHz. How far it changes is expressed in time. Of note, a jitter value of one billionth of a second (1ns) is considered high! It can be shown mathematically that in order to reproduce the higher frequencies perfectly, we need a jitter value measured in picoseconds, not nanoseconds.

Now let’s examine our current scenario. We have a PC, hooked up to an external DAC using a S/PDIF connection. Question becomes, why would it make a difference if the source file is stored on local hard disk, solid state disk, or remote/networked hard disk (NAS). Here, we need to dig into how computers work.

A PC has a CPU which executes code which includes the operating system and all the applications running under it. The CPU is a device that is also driven by a clock (the “Gigahertz” rating refers to this number). On every clock tick, the CPU executes code. If it has nothing to do, it idles meaning it sits there in a tight loop, doing nothing. When say, you hit a key on the keyboard, an interrupt signal tells the CPU to go and execute a bunch of code. Other times, like having a media player with visualization effects on screen, cause the CPU to execute a bunch of code and also drive other components in the system such as the Graphics processor.

In case of reading data from disk, SSD, or NAS, we face a different workload for the system. In case of Disk, the drive power consumption and RF interference comes into play. Every time the OS tells the drive to go and read something, it causes its servo motors to activate, causing a spike in power consumption. SSD does not have mechanical components. But it also has a power consumption graph that varies. For example, if the OS attempts to write something to it, the architecture of Flash requires erasing cells before writing to them which in turn, varies its power consumption behavior.

NAS also changes system characteristics. Here, instead of reading bits locally, we execute a bunch of code which drives the NIC (network interface card) to transmit and fetch data. The code path in the operating system to handle this data transfer is radically different than the HD or SSD cases.

What does any of this have to do with jitter and audio fidelity? Well, recall the simple example that I gave on how the clock frequency of the D/A changes based on voltage that is powering the circuit. In case of S/PDIF, it is the PC that drives the clock used by external DAC to output its data samples. So anything that changes the accuracy of the clock circuit in S/PDIF, can cause jitter in the external DAC.

Now let’s bring everything together. We have shown that depending on what source you use to read your “lossless” bits, you radically vary the load put on the system. If one zoomed in for example on the power supply line in the PC, which is shared by the clock generator for S/PDIF, we see that its noise spectrum is very different in each case. Noise on power supply is another word for its value changing. A disk drive taking 10 milliseconds to fetch a block to read something continuously, will cause a 100 Hz variation in the supply voltage which in turn could translate into a jitter component at the same frequency.

People are quick to point that these differences are too small to matter. But what they forget is that we are talking about laboratory grade precision necessary to guarantee low enough jitter values to reproduce audio signals perfectly. In that scenario, anything is game. Move your mouse and you might be changing the system characteristics enough to cause jitter!

Note that in all cases, the sample values are captured perfectly by the external DAC. That is never an issue to worry about. What we worry is the timing of those samples which unfortunately is anything but “digital.” Indeed, I call reproduction of digital audio an analog problem, not digital! After all, one end of the system is analog (the output signal) so no matter what you do up front, eventually the system turns into analog. So one cannot use the line that “digital is digital” and hence we should have no worry. The system is not digital.

Let’s use what we have learned and think about what makes the best system here:

1. We want predictable load. Why? Well, audibility of jitter (or any other distortion for that matter) varies based on whether it is correlated/changes with input. Correlated distortion is much more audible. Imagine if your projector fan noise got louder every time a bright scene came up versus always being at the same level. I bet you notice the former a lot more. Same here. Therefore, a perfect system keeps all activity in the system constant during playback.

What does that mean? Well, it certainly means having your CPU only doing one thing and only one thing. You don’t want it to wake up 1000 times/second to service a USB port for example. Those abrupt changes at 1 KHz induce distortion at that frequency (or relative to it).

But it doesn’t stop there. If you have nothing to do, you want something to do! Recall that we want the load to be constant as to translate into random noise. To the extent the CPU reads some data from a data source, then goes to sleep and keeps repeating this 100 times/second, that is also bad.

We can even get more esoteric here. When a data bus like a USB has nothing to do, we send nothing. This happens all the time since USB is faster than our audio data rate. So the OS pumps data onto the bus, then waits, and keeps repeating. This causes the load to keep changing, and worse yet, in a correlated way, making the variations more audible.

We also cause a similar problem at the other end in the DAC. The DAC also has a CPU that interprets the audio samples coming from USB. Its CPU now has a variable load due to spiky data transmission on its USB port. So we cause problems on both ends!

The ideal system here, would send out a stream of data constantly on the data bus with a header telling the receiver to ignore them and not what a computer guy would design, seeking efficiency and sending data only when data is needed!

2. You want to have absolutely lowest power consumption in the digital circuits. It is a law of physics that the more power you use, the more you disturb the power supply lines. A Gighertz CPU stopping and going constantly will result in incredibly high spikes on the power supply line. A typical PC processor draws as much as 30-50 amps while executing something! No power supply in the world can keep its supply voltage perfect when faced with such incredible changes in power consumption.

3. While we have focused on power supply variations as they are easier to understand, many other factors can cause inaccuracies in clock circuit. Radio Frequency noise for example, can “bleed” onto the clock circuit impacting its operation. A typical PC is a jungle made up of many RF frequency sources. The processor itself is one but as is every component in the system running at a different frequency. Without properly shielding, leakage occurs readily causing inaccuracies. When was the last time you saw a sound card be fully shielded in your PC? Even pro sound cards lack shielding of any sort.

I could go on but as you see, a PC is pretty far from ideal here. Indeed, I always say that the best sounding device is a Home Theater in a Box where every component of the system can be controlled.

All is not lost. Good techniques can be used in the DAC to make it very immune to such variations. But to the extent someone doesn’t have such a well designed box, then it is possible for them to hear such artifacts. Changing sources will vary the system load, resulting in different jitter components and hence, different levels of fidelity.

Note that up to now, I have assumed a more difficult scenario to explain. That is, the case of an external DAC. In case of an onboard sound card, outputting analog audio is much, much simpler. Here, the analog stages and DAC reference voltage can also vary even if jitter is non-existent. Recall that a 16-bit DAC takes a low, fixed voltage and divides it up into 65000 values. Reproducing such small differences requires a very stable and quiet environment – something that lacks in a typical PC.

On my den PC, I have a Creative XFi card that came with the box. When I turn on my fax machine connected over USB, I hear every bit of noise from its operation! Every activity in the scanner part to dialing up and communicating, causes noises of different sorts to come out of this sound card. A digital guy would roll his eyes, denying such a thing could occur. But of course, it does and the explanation is simple. The noise is traveling over the USB cable, bleeding into the power supply and going into the output stages of the sound card. So we don’t need to travel far to find explanations of system activity causing analog output to vary.

Anyway, this is getting long. Hope it gives you a flavor of the complexity of what we are dealing with here and possible reasons for hearing audible differences with identical, “bit exact” sources.

P.S. Apologies in advance for any grammar errors. Too lazy to proof read it .

_________________
Amir

Post from PeterSt

Hi guys, let's try to make something out of this all. Amir, very nice to see we are on a same track today ( 8-) ) although my findings would be somewhat more empirically derived than yours.

Allow me to paste in two posts from a thread somewhere else, which saves me some typing time and new typos, but more importantly, which may prove to us all that at least two perons on the Globe may state things, hard to prove by themselves. I mean, not copying your lines by any means, Amir.

The first post is an initial response to a question which was this :

Anyway I'm curious what manufacturers of DACs and other hardware think. With their own hardware, should any differences between software disappear?

In this case I'm on my act as a "hardware manufacturer" working on the greatest (commercial) DAC ever. You must know that this DAC was created in the first place with the objective of avoiding software influence. It has the best super-shunt regulation and everything, but it does not help ...
Here's my response to that question :

As to my findings so far, the DAC is influenced on an area which is (or at least very much seems to be) outside of jitter. As far as I can tell this leaves the "power" area. Note that I am talking about everything which is current related behind the DAC chip itself.
Although it is rather premature, this actually would be about wrong designs, where the DAC chip itself interacts with the I/V (current to volt conversion) stage behind it (which also can be on-chip btw).
I say "interacts" because that's what I think is happening.

As you know, my means of measuring allows me to see things not seen before, and as far as conclusions can go now, I see something like a difference between an output voltage of + needing to go to minus on one side, and a voltage of + needing to go less + on the other. The first heavily draws the voltage down, while the second just doesn't (and can't), and from here a high degree of non-accuracy emerges.

This by itself, of course, is not the explanation of software (#3 or #6) influencing the DAC, which (for now) I keep on seeing jitter related always. However, where one "spike" of jitter would be inaudible, this spike incurs for a heavy spread on the output stage, and while one or a few samples originally were influenced, at the output thousands are.
Keep in mind that this would be right in the middle of a high degree of inaccuracy in the first place, but since this high accuracy is relative to exact repeatable situations, any variance in "jitter" (or other influences by software might they exist) makes this visible when it is the only parameter changing.
You could say that just because of the DAC as a whole being so inaccurate, it is more easy to see this, but, it is also more easy to impeed for high influence (think of the one spike incurred by one sample, influencing thousands).

To me it is clear now that, when I am thus far correct on things, it is the accuracy of the DAC itself being *the* parameter for allowing more or less influence. As how I reason this : when the DAC would be 100% accurate, software may still have the same influence at the input, but with the example of the one spike, only that one spike occurs at the output, and this will be inauble.

All is in the perspective of my own built DAC with such a stable output stage that external influence seems impossible were it for current (drop etc.) reasons by itself, but the influence just remaining.
On this matter I have just replaced the output stage with another, focusing on inherent accuracy instead of stable power alone, and the only thing I can tell you right now is that I never heard such a sound coming from loudspeakers, and anyway it is totally different from before.

Today I am spending time on measuring what I hear, but it is my estimate that when this measures far more accurate, it won't let itself influence by software as easy as before. And as you know, I can measure that influence just the same, so ...

So, I'm a bit premature. :-)
Peter

So here you go; This is about Amir's "the other end", and it is the very first time I saw someone else writing about it. Nice.
IMO this is the main part being influenced, although it needs the initial influence in the PC as well.
The means *how* I do this in XXHighEnd will be a secret as long as I like that. But I think Amir's post is a perfect one to see it can be done.

Allright, the thread from the first post continues, and where people in there wonder (like in here) how software can make a difference, this was the question :

Plus, can you shed a little light on why you think you are doing things so much better than Sonic? You've already stated what you are doing, but why do you think a software company with a really good background is doing things so much worse than you are?

answer

My explanation about XXHighEnd sounding better changes from month to month, which is because I'm still learning myself how to influence "sound" in the direction I want. But usually it comes down to a story like this, because it tells all I think :

Everything happening in the PC influences; Although you could say that "processor load" is doing it all to you, this is not true, or anyway not true without a very deep insight in what happens in a processor. I mean, taking away some process that uses 10% of the CPU won't make sound better. The fact that the process is there in the first place, may make sound worse.
Keep in mind : "sound" is just what's coming from the DAC, and as I know by know this is not voodoo, but just there.

In between the lines, but as important, *why* sound (output "data") changes, is not known to me. I have never stated firmly that this will be about jitter, and the only thing I always have been saying is "I can influence the DAC". But give it some time, and we will know ... (measurements).

With the above as the so far ever base, it would be logic to conclude that I'm randomly trying things here and there until sound is better, and then onto the next subject. But this is not so, and it would be an impossible (time consuming) route to follow. However, at necessary changes in the software for unrelated other things, sound can change unexpectedly, and the way HOW it changes is very important (to me), and WHAT that changed is the most important as well.

The fun is, these things can't be explained because they are in the middle of a super large web of other (interacting) thingies, and all is about relative aspects. So, I could try to explain to a programmer that the way dot-net manages memory was not to my likings because of the expected influence on SQ - that I got around that while officially impossible - and that after working for months to rewrite the whole sound engine, well, it worked. Now don't ask me what worked, because the only thing I can say is the way dot-net deals with the memory, disturbs. Now, back to the beginning of this little story, I talked about the processor(s) and how it deals with stuff is for sure what influences. So ... now start thinking about the memory management and how that has impact on the processor's tasks.

So you see, even when you would be the programmer that wrote the whole Vista OS, you would not be able to make any sense out of this.

Right now I am working on this for three years, which means three years of experience on these stupid things which shouldn't be there in the first place. Each small element of which is proven that it influences, adds up.
In 100% of cases I created something explicitly because in advance I thought it would sound better - that worked out. But mind you, 90% of those cases where necessary counter attacks about things I changed in the software in general, but people started to shout all over the sound got worse.
In the end it may be the conclusion that it is al under my control very well, but I still don't know how the influences get to the DAC's output.

Lastly, from the many reports I received over time, and the changes necessary to repair SQ I just talked about, I derived the general parameters that explicitly influence sound, and this has turned into the Q2/Q3/Q4/Q5 sliders. From this, one can really get crazy, because an original problem would map onto one position of one slider, while 29 other positions are there in that one slider to (de)emphasize the "problem". And while this is one slider, there are 3 others working the same, though dealing with other aspects of the sound, hence are about different "problems".

Well, this is about all I can say. Shift up both Q2/Q3 from 0 to 26 and a dry piano comes as alive as if the sustain pedal is suddenly used. Some crazy found this out, and now it is a control.
This stuff is super subtile with the fun of all still being bit perfect.

That's my story. At least it *is* one ...
:-)
Peter

Now, lets quote one sentence from this :

I mean, taking away some process that uses 10% of the CPU won't make sound better. The fact that the process is there in the first place, may make sound worse.

That doesn't make much sense, right ? But now take Amir's considerations into account;
And in between the lines, isn't it great that with the (may I ?) authority of Amir, and the parallel empirical findings of myself, things just as well may come together ... closely. So :

What Amir states it that this is all about spikes not being all that good for audio;
If you read back the last quoted part above about Q2/Q3/Q4/Q5, this is all about that. Spikes (coming from elsewhere !) are eliminated or ... added to create a flat noise spectrum. Don't think about adding noise or so, but keeping the consumed power levels the same. If a spiking process can't be avoided, well, stuff in similar spikes so the "spike level" becomes flat.

This is all crazy difficult because (for me anyway) those spikes can't be seen. They can be derived though, emiprically.
Many things are in the area of multi processor cores, so it is a first task to get that under control (which are other parameters in the player). Again this need not be about less load or more lean, but about forcing the OS to spread better.

Of course besides all, there is the huge task of eliminating the processes to begin with, and many threads on the Net are about that. As some may know, I created one (thread) myself about eliminating all Vista's IOs. Takes days and days to get there, but it is an important base. It is, because it allows the OS disk to spin down and never wake up. And of course by now this is eliminated by itself by using an SSD for the OS disk.

All is outrageously complex, or an enourmeous pile of work anyway. But it is worth it, and when all comes together in a player thinking of all this, it pays of for sure.

I don't claim I'm there. Not software wise, but merely not hardware wise. It may sound stupid, but where XXHighEnd is there to influence the DAC to the good direction, I'd rather have a DAC that can't be influenced. Once that is so, there won't be *bad* influence either. So to me it is obvious that once the DAC is ready, XXHighEnd is obsolete.
I don't care.

Peter Stordiau

Thanks Peter. That's the best bringing together of the topic I have seen. Previously I was taking as given; statements that software cannot influence jitter. If we allow that it can, the whole debate makes much more sense. The path of being able to positively exploit the phenomena seems overwhelmingly complex but I am comforted to hear that it is not just 'trial and error'.

- John.

As you say Peter, a very long post and in places difficult to follow exactly ... however I'd like to sum up, if I may, what I understand from Amir's post...

First, nothing he talks about is to do with software to my mind, he talks about how as the computer works, loads on power supplies change, servos operate injecting noise back into power supply lines, high frequency noise shoots all over the computer, etc ... this we know. He also talks about jitter. Now my understanding (which mostly follows what Gordon says) is that jitter only comes into existence when data is referenced to a clock. This doesn't happen WITHIN a computer where the "music" exists only as data. The only time jitter is created, is when the data is translated into SPDIF (or AES or i2s) because only then does timing become an issue.

IF you use a PCI card to create that SPDIF output, then the clock is going to be influenced by the power issues, HF noise, etc that Amir talks about. In the case of Gordon's (and dCS's) USB interface, the close has no relationship to the actual PC as it uses asynchronous transfer (the same is true of FireWire interfaces). If you take this into account, then (as far as I see) non of what Amir has spoken of should affect the sound as his described "issues" are inaccuracies of the clock due to influences inside the computer.

Maybe I'm completely wrong, misinterpreting what Amir wrote, but in no way do I get any understanding of what SOFTWARE issues will affect the sound quality. Yes you can try to write your software to avoid data IO, etc which will affect the PSU and therefor the internal clock circuits, but there should be no influence on an async USB or FireWire device from this.

It all seams like a little hocus-pocus. You write your software and it sounds good, but if connect up your PC to your Berkely DAC via AES, and compare the output of the same file to the output from iTunes and the output of XXHighEnd sounds more expansive, instruments more clearly defined, etc. (that I've ever heard) you can't sit down and say "That sounds better because (for example) there is no continuous data transfer from the Hard Disk" or "It sounds better because system resources on this computer are only 35% rather than 55% with iTunes". Yes you program using what you see as best practices, but unlike with designing an output stage of a DAC, you can't measure it and say "yes that sounds better because harmonic distortion is down 2% after I changed that capacitor for this one".

I think your statement you make of "My explanation about XXHighEnd sounding better changes from month to month, which is because I'm still learning myself how to influence "sound" in the direction I want. But usually it comes down to a story like this, because it tells all I think" really sums it up. You just don't know WHY it sounds different. As (I think) you've said, you can rewrite a piece of code and it can influence the sound in either direction, without you knowing what the difference actually is. Don't get me wrong Peter, I don't think it's just you ... Sonic Studio's have been unable to say what makes Amarra the best thing out there - but 100s of posts on this forum and elsewhere support the fact that it is. The end result out of the DAC seams to be different, yet as has been stated, the input seams to be the same (within out understanding). Someone once said about Amarra, "Would we be more content if they told us the result was down to an ancient Tibetan chant their programmers recited while programming" ... well, sometimes it feels like that might be more accurate!

Eloise

PS. I've actually got some more comments to make about other issues but think a second post might make for clearing understanding...

Sorry hope this doesn't sound patronising to you Peter but here goes ...

You said in previous post... "Or you must have a second agenda of course, which at least I do not dare to say in either situation. and then commented ... two different people immediately read this as the explicit other way around.
You are correct that reading it directly you are not making any accusation that someone (dCS in this case) has a second (hidden) agenda.

However a lot of people would read it as sarcasm especially given the rest of your post. You have been critical of how the tests were carried out and presented and said that "Once you're into these matters, and you see those graphs, you must scratch your head and think as long as it takes to find out what *you* [the author?] are doing wrong. Only (and this is my implied statement) when you are not so much into the matters at all, you believe your own crazily out of line measurements ... and publish them."

It can be read that you are accusing the author of the paper of being either a fool or careless in his observations, OR he has a hidden agenda. By mentioning that he MAY have a hidden agenda can make people think, that you think, the author has one.

Eloise
(Hope that wasn't too school treachery!)

Peter wrote... "Many things are in the area of multi processor cores, so it is a first task to get that under control (which are other parameters in the player). Again this need not be about less load or more lean, but about forcing the OS to spread better.
Interestingly this is one of the trumpeted features of Snow Leopard so maybe will lead to a subtle improvement in sound quality.

One thing I have always found is that whenever someone "finds" a new piece of software which improves sound quality, they never use terms like "subtle" or "minor" it's always "x blasts y for sound" or "y is da bomb". My experience with upgrading HiFi is (beyond the move from a Sharp Mini system to my first separates) I've never experienced an upgrade that has transformed my listening, only ever minor steps towards perfection.

Eloise

Eloise,

never let anyone change you. You have an excellent grasp of matters at hand!

Anyway, I don't mean to start arguments, and I do think it's important that Peter has the opportunity to express his point of view, and I do think ( sorry Peter ) that he tends to get excited over his capability to express himself in English.

Peter, looking at your website, you seem to be able to do FFTs - would it be possible to repeat your experiments with bit-perfect data, and FFT the PC->DAC->ADC->PC measurements with the different settings? I applaud your efforts to measure the differences, but comparing time-domain data is sooo tricky to align, especially with group delay in the ADC and DAC. Also, would it be possible to put some scales on your measurements?

My experience of just about everything in the world is that if there is a commonly perceived difference that you can't measure, it may well be there, you're just measuring the wrong things. Maybe that's why people call me an idiot,

your friendly neighbourhood idiot

I just glanced over some of the long posts to your question and all I have to say is:

Don't wonder how or why (at least for now), JUST LISTEN to the different playback engines to hear what sounds better.

Why does an Esoteric D-03 or D-05 DAC sound better than Brand X DAC? If you're only listening to a DAC and not designing a DAC, why care?

So do I really care why Amarra sounds so much better than iTunes? It just does and that is confirmed by most audio experts, renowned music critics and laypersons that have heard the comparisons.

I guess someone could write a 100 page dissertation, but I'd be willing to bet that everyone who attended the CA Symposium didn't need anything but a listen to convince them with absolute certainty that Amarra sounds significantly better than iTunes.

Sorry to start responding to the last post, It's just the most fresh one in my mind.

Yes, the alignment is the most tricky, and this is exactly why it is such a breath taking complex thing.

What you don't know (or anyway I never expressed it in here I think) is that for a longer time now I'm also able to measure the absolute differences. Actually, the relative differences are a piece of cake compared to absolute. So, from the "absolute" measurements can be derived what is wrong and what is right, but ... everything is just very much wrong ...

Please keep in mind that I rule out the ADC here, which I most probably shouldn't, but otoh I can't find a real reason why an ADC would be wrong, while it's easy to see that a DAC can be wrong indeed.
Side note (though important) : this is exactly why I stopped measuring the other day, because I was shocked about of the DAC's results. It was so much out of line compared to the input file, that I thought I'd rather spend time on the DAC first (which I am able to, technically spoken).

Then, and actually just FYI but again possibly important for future audio : the result of two months of hard work you could call outrageous. The sound I have here now is in no no no way compareable to whatever I thought was good only a few weeks back. It did not only change my audio life, but it should change audio.
I know, quite a statement, but let me float on that small cloud for a while.
The point is : I only started working on these specifics because I could see what was wrong (call that slowness of the DAC).

What I have changed, for 100% sure can be seen in FFT's (this is not your question, I know), so, what about a THD+N of 98dB down in the audio band (better than 0.004%). Ah, not worth much. But keep in mind please I am talking NOS and filterless on the DAC side, by that not saying that I don't apply filters anywhere (like software). But please go out, and look for NOS with these figures.
Because I know / learn more and more about the deep inside of things, I wasn't satisfied with that, and went on to 80 dB down all the way up to 96 KHz (which would be a THD+N of better than 0.02%).
Now listen, and don't comprehend whatever happened ...

Nice unrelated story, right ?
No, I don't think so. What you can learn from FFTs is that a spike of HD is very fragile. Those who look at the results of sweeps will know what I mean. Thus, HD peaks will add up when they meet, and where four single peaks of 90dB down just incur for that, changing the frequency slightly and voila, there you have 66 dB down. No energy added, just coincidental meeting HD peaks, and zzzoooom does your speaker (or your amps outside of the audible band)
Nothing new by itself.
The whole points is though, that when the DAC indeed leads its rather own life, this HD is just out of control obviously. This is about the picture and the "outbreak", the burst/peak (whatever) taking 1ns perhaps, but the slomo DAC making 70ms of it because it just doesn't know how to recover faster from ... a transient.
So, this is software impeeded, and this destroys sound for 70ms just by external influence. But mind you, the inherent influence (the smash on a rim) just does the same.

By now I'm sure you'll think the whole thing is mixed up by influence of softare on one side, and creating a good DAC on the other. But if you followed me for a while - and this is in the quoted posts just the same - my objective is to eliminate the influence of software. No matter I wrote software that does the opposite. And while I know how that behaves (and can measure it), I kind of know what to do to avoid it. So that's the story behind it all. And why ? because software influence IMO can just fight the symptoms, not the cause.

For fun, and to throw some oil on the fire, some guys repeated the "symposium tests" with a better DAC, and no difference could be heard anymore (just copying words here !).

Anyway, an FFT or anything else from an analyser can not show the detail software influence creates. This is because an analyser can't work with live (music) data, and only with test tones. And might it be able to catch something like that outbreak, you yourself won't be able to make the snapshot of it.
I hope this is clear ?

Hi audiozorro,

the blunt answer is I don't care as to why someone prefers X over Y. As I have said on this forum, the thing that matters is your music being reproduced in the best way for you, be that with a tin can and a piece of string, or an iPod with a Wadia dock, or a Mac running Amarra using it's headphone out, what matters is what you hear. People like different things.

The problem is this : people, as a rule, can't say "I prefer X because it sounds better than Y" - they tend to have a belief system associated with X ( or inversely, to Y ). The manufacturer of X will say this, or that, and Y will say this or that in response. People who have have bought Y may feel dissatisfied with their purchase for no good reason than it is out of favour.

I ( as you may be able to tell ) would like to align X with some aspect of performance, and Y with another, and have SOME feeling that there is a quantifiable difference between the two. This is why I am extremely interested in the measured differences between playback engines, clocking schemes and DAC schemes. I am "just that kind of guy". Hence, my original question was "if the data being read from the file is presented to the DAC, how is there any difference?", and the cornucopia of answers with very few concrete answers does nothing but pique my interest.

I guess another point is that most people don't really have the opportunity to listen to an Esoteric D-03 AND a Brand X, or vice versa, and will rely on what they have read for purchasing decisions - this is obviously not the right approach!

I care about whether amarra sounds better than iTunes because nobody has done any _real_ tests to prove it, and the guys that wrote it have come up with nothing to explain it - that doesn't mean I don't believe it, but how many instances in hifi have we heard of green pens, or magic stones, or ley-lines?
Is it worth $1500? Why not, if it really is unquestionably better than anything else? Software is NOT FREE - just ask the US government what the most expensive thing in the world is ( http://www.embedded.com/columns/breakpoint/17500630?_requestid=268749 )

On a side note, I started this thread slightly playing devil's advocate, and the forum has proved very reasoned arguments for the different views,

your friendly neighbourhood idiot

One of the problems with most measurements is that they are taken in rather abstract situations. For example, test tones are used rather than musical waveforms or other more random signals.

In this case, DACs are usually measured outside of a system context. Here's one silly example of how that could be misleading.

Imagine a system with a large power amp that causes 1/2 Volt fluctuations in the AC mains supply when playing music. Now imagine that the DAC is sensitive to this supply change for some undefined (for this thought) reason. How would you discover that in a simple test of the DAC in isolation?

So, if even one person can reliably detect some difference between condition A and condition B, then there is something there. It may not be important to anybody but that one person, but it is there. If we knew what and how to measure for that, we probably could.

But, let me tell you, the audio world has for the most part decided that almost all of what's worth knowing is already known. Human auditory systems are well understood in this view, and the tests that have been done for a couple decades to determine the performance of an audio system are more than adequate.

Compare this to the open discussion of possible global climate due to (fill in the blank). I never knew there were **so** many experts in this one field! It's hard to distinguish between what is really reasoned and what is desired. In climate change and audio.

Enough blather - what do I know? Go listen for yourself. Trust your ears. You don't have to justify your preference to anybody except those who share your home and your bank account. Nor should you.

I only want to tank you for your outlays. In the end it shows exactly what I expected, and it will be the atmosphere I create that urges for wrong reading.
As I said elsewhere (not much appreciated I'm afraid :-) it is often about the context of the lot which I work with, and in this case indeed this is and was not finding the writer concerned not much worthy. If I say this, this is what I honestly mean, and if I add to that (later) that this same writer will not have a second agenda, this is only consistent with that.

OF COURSE there is no reason in "teaching" you or anyone how I operate, but if I only remind (specifically) you that I'm in IT for the whole of my life (closely :-) you actually wouldn't want it otherwise.

Anyways, if it is the result that people read 180 degrees differently from my intentions, in the end it is clearly me making the errors. Tough to deal with perhaps (for me that is), but not starting cynically (which I often do) may help for starters.

I wish I could apologise for all future misunderstandings right in here.
May you want to take the time, keep on pointing me to arbitrary routes, just knowing that I don't know that phenomenon (ha ! who understands *that* ?!).

Again, thanks.
Peter

"I care about whether amarra sounds better than iTunes because nobody has done any _real_ tests to prove it, and the guys that wrote it have come up with nothing to explain it - that doesn't mean I don't believe it, but how many instances in hifi have we heard of green pens, or magic stones, or ley-lines?"

There's other OS X playback applications that sound better than iTunes, at least in my estimation. Most are free, or less than $100. But, some are cumbersome to use because playback isn't their main purpose. Still, there's free playback applications designed for the task that I think sound better.

Amarra has just been so prevalent in the forums due to the commercial aspects of it that people get up in arms over it. If it was $15, people would feel better, but I'll bet that there would be a load of people who would whine about the outrageous price. Go look at the iTunes Application store for the iPhone if you want to see examples of people savaging some application they spent 99 cents for. If the Amarra designer spilled his/her/their collective guts over everything that was contained within, you'd still have people mount loud, long and often vile challenges to every word.

My point of view is that if magic stones, sorcery, green pens, or whatever works for you, then why worry about it unless it is harmful in some way?

Hi CG,

as you know, you are ( in my estimation, at least ) someone with knowledge in the field ( and always right! ). I entirely agree with the whole "secret sauce" thing with software - once the secret of the sauce is revealed, everyone can jump in, and the guys who put in the original effort go unrewarded. If Amarra is as good as everyone says, for some secret reason, then that's great for those guys. I have some sympathy for the guy being interviewed as to why it sounds better being a bit, well "vague", but I DO have a problem with misinformation. Hence, the Sonic guy going on about "floating point conversions" - well , if I write a playback engine that takes fixed point input and generates fixed point output, then why the hell am I passing it through floating point? Simple answer here is there's a good reason for PRO use - EQ, volume compensation etc. However, for bit perfect playback, which is what the market demands, it becomes somewhat impossible for your algorithm to do anything to the actual audio data, leading to a whole can of worms to do with processing, EMI, jitter etc that no-one seems capable of measuring.

If, on the other hand, Sonic said "well look everyone like iTunes, but no-one really understands the whole Audio Midi thing for sample rates, and we've fixed that", then again, good times are here!

I guess I'm just fed up of misinformation being spread around, and like I say if people just preferred one thing over how it sounded rather than misinformed engineering, I'd be delighted! Why do you think these other applications sound different, as a matter of interest, or are you happy with "they do"?

No worries either way,
your friendly neighbourhood idiot

I would _have_ to know about the resonant frequency of my magic stones :)

your friendly neighbourhood idiot

First, nothing he talks about is to do with software to my mind, he talks about how as the computer works, loads on power supplies change, servos operate injecting noise back into power supply lines, high frequency noise shoots all over the computer, etc ... this we know. He also talks about jitter. Now my understanding (which mostly follows what Gordon says) is that jitter only comes into existence when data is referenced to a clock. This doesn't happen WITHIN a computer where the "music" exists only as data. The only time jitter is created, is when the data is translated into SPDIF (or AES or i2s) because only then does timing become an issue.

First off - and maybe I should have put it less in between the lines - the question here was : Why do different bit perfect players sound different ?
Ok, it was in bold, but how to dig it up out of that stupid long post. Anyway, Amir, as well as I where responding to that question. I hope this kind of satisfies all you remarks about possible irrelevance of Amir's sayings.
Btw, per email with BEEMB he kind of said the same here at CA (it may have been a little before your times here).

[please appreciate the below as somewhat speculative, because for me too some things are guessings]

Above I incorporated your ideas about what Gordon thinks, but I think we must be careful about this. He may be unconditionally correct, but this doesn't say there is not more. This is from the angle of no galvanical separation on one side (so, just electrical influence) and from too easy assumptions jitter can be the only influence on the other side.
Those who followed my own forum a bit from the beginning, know that if anything, jitter is hardly mentioned (perform a search for it, and if you receive two pages I think something is wrong :-). I only want to say : I don't think this all is about jitter, and the Q1 slider in XXHighEnd I call the "DAC influencer". This is -completely outside the Q2/Q3/Q4/Q5 sliders - because I know what this does, and which I like to keep for myself. Sorry. But the myth will be unveiled only when I am 100% sure about what is happening, and this is not now. Now yet.
Allright, I can try to be funny by pointing to a post right in here (CA) where the same Gordon tells that XXHighEnd does not sound right on his completely asynchronously separated from all - DAC.
This leaves us nowhere, apart from the lesson that we'd better understand ourselves completely before using a quote out of that context as an argument (yes, I very well did see how cautious you are regarding this, as always btw :-).

From my side I could tell you more. It may be worth nothing to you or anyone, but for me it is just real life;
I coorporated on such a DAC myself. At the software level and at the listening level. And you know what ? it sounds like sh*t. It must reject all incoming jitter (there just can't be anything !), but it doesn't sound. Why ?

Well, because a DAC not subjective to jitter WHICH ROUNDS (how many !!! do I need here), is completely on its own, and only when it is the very best you may expect good sound from it. What I really want to say is this :

a. Jitter is a hype or hoax, and indeed at the levels it exposes, it can not harm (express it in dB down, and you'll understand).
b. Keeping in mind the super fragile Harmonic Distortions which WILL add up all over (from my previous post), and you'll know that any DAC exposing THD+N at the audible level (say 70dB down and less (= worse)) just won't sound right. But ...

again knowing how fragile HD reacts (and please be with me, I know) jitter can counteract it.

All too difficult to explain maybe, but if jitter is able to spread apart the HD peaks which inherently are there, you just have less HD. And man (yea yea) is HD audible ...

I cannot emphasize enough how much it is. And to understand the impact of it, keep in mind please that for a decennium or so, we tended to believe it isn't. This is the story about NOS again, and while it measures so badly, we perceive it as better sounding. NOT NOT NOT. This is all fake. It sounds crispyer allright, it sounds more bright, but it distorts just like it measures.
Am I saying something new then ? YES !
Yes, because I created an NOS which just not shows that HD, and no jitter is going to create it again.

What the heck am I all talking about ??
Well, before I stumble over my own words and ideas, the stupid fact that if software influences, the DAC is not right. If it does not, most probably this is the situation the DAC shows few jitter. And, if that DAC doesn't sound right, this is not because of jitter but because of harmonic distortion.
Lastly, such a DAC is lost forever, because no external influence can make it sound better by means of jitter injection hence spreading the HD signature.

A bit speculative ? may be. But I can tell you that by taking these kind of rather complex phenomena into account, digital playback of red book at least doesn't need hirez for the nest couple of ... (fill that in yourself).

But HD ( harmonic distortion ) IS something you can measure - If you remember, I asked for FFTs, which would show this?

your friendly neighbourhood idiot

OK...

"In Mac OS X, Core Audio expects audio data to be in native-endian, 32-bit floating-point, linear PCM format. You can use Audio Converter Services to translate audio data between different linear PCM variants. You also use these converters to translate between linear PCM and compressed audio formats such as MP3 and Apple Lossless. Core Audio in Mac OS X supplies codecs to translate most common digital audio formats (though it does not supply an encoder for converting to MP3)."

That's from the Core Audio documentation for the iPhone. I'd say that pretty much scrubs the bit perfection ideal, wouldn't you? (I assume that I'm reading this correctly. Someone will likely correct me, I'm sure.)

One thing I have always found is that whenever someone "finds" a new piece of software which improves sound quality, they never use terms like "subtle" or "minor" it's always "x blasts y for sound" or "y is da bomb". My experience with upgrading HiFi is (beyond the move from a Sharp Mini system to my first separates) I've never experienced an upgrade that has transformed my listening, only ever minor steps towards perfection.

Nothing against that, but it possibly depends on the "level" you are at, in the first place.
And, not to be "pedante" (i hope you understand), but elsewhere today at CA I explained about my 100K worth system not so long ago, while today this comes down to 17K only (commercial value, not DIY).
I won't repeat all that here, l but it indicates some things;

Before (the 100K system), I was struggling (without knowing it back then) with overcoming "distorted sound". The less annoying it was, the better. I estimate (just by visiting high end shops - which are all over here - that near 100% of audiophiles work like this).

Then there came this moment that I apparently jumped a hurdle, which changed annoyance into "how can I make that sound more realistically". From that point on - and only there ! - the escessive "a 10 times better !" emerged. Not before that. Before that, indeed as you say, changes were subtile. An off line UPS here, a jitter rejector there, but all was minor. Why ? well, because there was no real reference. Bass improved because it was more tight. Wow. Mids improved because you could hear what singers were saying. Wow. Highs improved because I could play louder. Wow.
But once you take that hurdle and those things being out of the way, it is much more easy to a. adjust and b. interpret.

In my last post I referred to the jitter-immune DAC. The hurdle was taken by then. Now, the subject was not that DAC but the loudspeakers. But now imagine : all cymbals (remember, those which sound ok already but which you try to improve) at a certain xover setting sound like chine cymbals (chine cymbals sound dirtly on purpose). Well, this can't be right, because not even Billy Cobham uses 8 chine cymbals, let alone all of the performers. Now :

a. this is a measure of something being really wrong
b. once you get it right again it is nothing less than superlatives all over.

Just try to imagine this, without EQ's or otherwise, how in the world a wrong sounding chine cymbal can start souding like a crash or much much "worse" - a ride. This is so impossible to imagine, than once it happens you legitimally may shout WOW.

It is the most easy (believe me please) to pump out super transients out of equipment just by means of bit perfect software alone (there is a "less dynamics" checkbox in XXHE for that). You may screem "more more more !", but I can tell you, it is not right. You may like the startles of smashes for one evening, but after that you get tired of it, and find out that this is nothing for background music.
The difference is really day and night, and your WOWs may be all over. Leonard Cohen (and Mark Knopfler to a lesser degree) seem to tear your diaphragms, and while this is the most interesting by itself, you will find that a sax merely sounds like a trumpet through your speakers at the same time. Now, when the timbre remains, but the sax suddenly is a sax, here is the "10 times better !" again.

Keep in mind : the hurdle is to be taken first. Before that, the sax may sound as a distorted clarinet.

Not even close to 2c
peter

But HD ( harmonic distortion ) IS something you can measure - If you remember, I asked for FFTs, which would show this?

Of course. But as I tried to say : this won't work with live music (through speakers hehe) because you'll always miss the snapshot (even with a digital recording analyser). Please keep in mind : my example of the 70ms ourbreak is an outrageously excessive example, and is still missed. More normal deviations are about 100 samples or so deviation, which is ... 1/441 = 2ms. Besides, an FFT is not an absolute measure of a snapshot anyway, and instead it is a measure of a bin of e.g. 4096 samples.

Don't blame me ... nobody can measure this by normal means.

Firstly, CG, yes, the OSX documentation does say that the native Core Audio data type is 32 bit floating point. However, there do seem to be flags around to say "this is fixed point", and on deeper investigation, it would appear that it deals with fixed point by using an 8.24 notation ( i.e. 32 bit fixed point ). Many people have verified that iTunes is bit-perfect, so my apologies for misunderstanding the issue, but the point is that iTunes and Amarra if both bit perfect will reproduce the sample samples at the output - the floating point stuff just confuses the issue...

Secondly, Peter, are you claiming that your measurements can't be repeated with sine waves? Even though you claim elsewhere that 2% of samples are wrong via your PC->DAC->ADC->PC route? An FFT is an excellent way of capturing large amounts of data an processing it, but you do need a much longer FFT...

your friendly neighbourhood idiot

Okay so this is probably a dumb question ... but what is an "FFT"? I assume it's either a method or device for measuring and testing audio?

Eloise

this might help

http://en.wikipedia.org/wiki/Spectrum_analyzer

clay

Hi Eloise,

sorry for complicating things ( again ).
FFT stands for "Fast Fourier Transform" - basically you capture data somehow ( sound card, etc ), and convert "time domain data" into "frequency domain data" ( also known as a spectrum )

in the time domain, plotting a sine wave looks like a sine wave ( so your x-axis is time, and your y axis amplitude ). In the frequency domain, the sine wave looks like a big spike at the frequency it is at, and the x-axis becomes frequency, and typically the y-axis is still amplitude, but in log form ( dB ). The graphs in the dCS paper you outlined are FFTs. Now, the cool thing about FFTs is that if you have something pure and never-ending, like a sine wave, _anything_ else on the graph is noise or distortion. On the dCS graphs, you see a spiky thing with a ripply line below it. The ripply line is the noise floor of the FFT ( which isn't really the noise floor of the system - things can get rather complicated! ). Any other spiky things than the original sine wave are distortion - so, if you read product X has 2nd harmonics at -90dB, the FFT would show the original signal, and 90dB down from this at 2x the signal frequency you see another spiky thing,

hope this helps,

your friendly neighbourhood idiot

Thanks to you both ... I've seen / used the function on a spectrum analyzer when (failing at) university ... just forgot what it was called :-)

Secondly, Peter, are you claiming that your measurements can't be repeated with sine waves? Even though you claim elsewhere that 2% of samples are wrong via your PC->DAC->ADC->PC route? An FFT is an excellent way of capturing large amounts of data an processing it, but you do need a much longer FFT...

(trying to avoid calling addressing you as idiot :-)

I must honestly say that I didn't try (FFT can be 64K deep I think). But, many things changed at my side since I started this, and back then I felt I had a too high noise floor to ever see such small details. But now ? I have so crazy low noise, I really should try it.

Peter,

just a quick question - why do all your FFTs have the signal at -40dBFS?

For those interested, this graph shows a 2nd harmonic at about -95dB with respect to the signal ( big spiky thing at 8k, little spiky thing at 16k )

your friendly neighboorhood idiot

"Many people have verified that iTunes is bit-perfect"

I'd like to correct that.

Many people have *inferred* that iTunes is bit perfect. This is usually based on the measured performance of a single sine wave or by noting that the HDCD flag doesn't get corrupted. I have yet to see where somebody has actually looked at the bit pattern coming out of the USB spigot or the Firewire port. If somebody has looked at this, I'd love to read about it.

Beyond that, I think I don't have anything further to contribute to this discussion.

(that seems a good one for addressing you :-)

just a quick question - why do all your FFTs have the signal at -40dBFS?

Just because I cannot in all cases reach a higher level; depending on my on-going tweaks on the DAC, it could be -10, -20, -30dBFS and so -40 is just to be on the safe side and my own (later) comparisons.
The -40dBFS in this case (IIRC) emerged from digital attenuation of -19.5dBFS (meaning I could have reached -20.5 here). So what you see is including digital attenuation from the player and a 16 bit source using 24 bit result data.

To make the story complete (and this you might want to hear) is that the more offial using -60dBFS won't be of much use, becaus then all the virtual harmonics would have been into the noise. Nice for the picture, but cheating also.
Note that the harmonics (allright, the distortion) is quite linear with the level (not 100% for all frequencies).
One could also argue that if I had to attenuate to -60dBFS, there would be additional distortion because of loosing bits (2 under 24). Nobody wants that, so nobody plays like that (with digital attenuation).

Is that something for an answer ?
Anyway it is on purpose.

Peter

Edit : ... and the noise floor sure doesn't rise with a higher input level ...

Hi Peter,

you must have some awesome playback software, DAC and ADC to get a -160dBFS noise floor, let alone with 16 bit data...

your friendly neighbourhood idiot

You should care whether you prefer the sound of X over Y and you should use other people’s opinions, tests or whatever to possibly give credence to your preferences. But IMO the ultimate choices and preferences should be yours, unless you are kind enough to involve family members that may wish to or you hope will share your music hobby.

Now I can’t tell how good something sounds to me by just reading text or measurements. If you can you’re a better man than me. I have to listen to how something sounds, though I have often parroted other people’s collective opinions on things I have never heard. Thus, I haven’t heard the Berkeley Audio DAC but based on other people’s opinions, especially those I respect, I have no qualms about declaring the Berkeley units to be an excellent sounding DAC. Enough so that I would be willing to consider ordering one for an in-home evaluation to assess if the unit meets my expectations for the price. I wouldn’t care if the Berkeley DAC measurements are inferior to a Benchmark DAC or an Esoteric DAC, whether the Berkeley DAC was a NOS, OS or Upsampling DAC, or what internal DAC chips were used. I would make my decision on how much better it sounds in my system over what DAC it would replace and whether I think the sound improvement is worth the cost.

I disagree with your statements on whether Amarra sounds better than iTunes and nobody has done any real tests to prove it, and the guys that wrote it have come up with nothing to explain it. I don’t know what real tests you are looking for but I consider listening tests to be real and the most important of all tests. It’s like if you read a food critic’s review of a meal’s ingredients, how it was prepared and cooked, how it well it tastes and compares to other meals, but you never taste the meal for yourself. You may even go so far to get the same meal but your interest is in analyzing the food and not eating it. And then there are other folks who may insist that there is only one best way to prepare and cook that meal to the disregard of what other master chiefs may be doing or saying.

Contrary to what you say, the Sonic Studio website writes plenty, which I quote, that you seem to dismiss.

[Quote] The first task is that the audio file, represented as digital data, must be read off the media and into memory. This requires the audio player to guarantee (as best it can) the audio will be read from the disk in time. The player needs to deliver the audio samples to the Hardware Interface not only on time but also synchronized. Otherwise, we may hear clicks, dropouts, phase, and balance problems. Sonic addresses this using optimized file handling routines. We do not look at latency as an issue in a home audio reproduction system unless it's being synchronized with video.

Once the audio is in memory, it needs to be converted to a format the computer can "understand". Current audio formats for uncompressed audio use a 16 or 24 bit sample and this must be converted to the IEEE floating point architecture in use by most computers today. This conversion can introduce noise into the audio signal. Should we
truncate, round, scale or perform some combination to achieve the best sounding result? This conversion occurs on input from the disc and on output to the hardware interface. Based on our experience, we sometimes find that textbook math does not mean the best sounding math.

The next stage is the gain structure and processing that may take place inside the audio engine. When you adjust the slider to control the volume a gain process is applied to the audio signal. Even when the gain is at full volume processing may take place that effects the sound. In the Sonic Studio Engine we perform all calculations using 64 bit extended floating point math. This allows us a full 56 bit mantissa which allows us to keep the noise levels below the 24th bit found in high resolution audio. When any processing is applied it is important to redither the sounds to mask the effects of all the rounding and noise that were previously introduced. To address this problem, SSE comes with
two dither algorithms which are optimized for use with Amarra. Perhaps as important as the underlying math is the efficiency in implementation as each operation has the possibility of increasing the noise [Quote].

So let’s review, Amarra reads in a portion of the music track into memory from the iTunes library, reprocesses the data with optimized routings and uses a superior playback engine to produce bit perfect data that sounds far better than just using iTunes processes and playback engine. That anyone doubts that the playback engine in Amarra, the same engine that many well respected recording and mastering studio use in soundBlade is beyond me.

But Sonic Studio goes one step further. They say here is a free demo, download it for yourself and listen for yourself. Conduct any A/B tests you want, conduct double blind listening tests, and conduct any measuring test you want. What’s left?

Or perhaps if I were a dealer, I would ask what else to I need to do for you to buy this product. Perhaps your answer is I’m not serious about buying, I’m just asking questions. Perhaps my dealer response may say thanks for all your objections to something others have clearly found to be superior, a product that you can evaluate for yourself and thank you for wasting my time. On the other hand my dealer (silent) non-response may be thanks for all the free advertisement. I can’t remember the last time that a single audio product received so much attention over an extended period of time, except maybe for king of the hill, the Linn LP12.

Hi audiozorro,

I will almost certainly attempt to get a demo copy of Amarra, and see for myself. In the meantime, I have a highly tuned sense of when people aren't being completely straight. I have NO PROBLEM with Amarra having some magic, but let them call it magic, OK?
So, let us break down the words that have been said by Sonic so far:
The first quote, that the audio has to be read from media into memory without clicks or pops. Does iTunes not do this, or does it crackle, click or pop?
The second quote is to do with translating the audio from the file format provided into one the OS can use to feed the audio device, and how errors can occur here. I reckon iTunes is bit perfect - i.e. EVERY sample from the media makes it's way to the DAC without any corruption. If there are errors, noise introduced here, then the output will NOT be bitperfect. Again, if, for every sample read in from the media, the SAME sample is sent to the DAC, how can Amarra do anything different without those samples changing?
The third part, about gain structures is where Amarra is probably better than iTunes, but, if we're changing gain, we're changing bits, right? So, if in both cases the volume controls are set at unity, and the output samples are the same as the input samples, where does the improvement come in?
Put it this way: If a player is bit-perfect, and we feed it the samples:
0 1 2 3 4 5 6 7 8 9 10
It should output the samples
0 1 2 3 4 5 6 7 8 9 10
And ANY processing involved can't matter if we get out the same samples, can it? Or are we saying that (for example) Amarra doubles every sample input, then halves it on output? The output IS the same, which is ALL the DAC sees. ( CG, I shall endeavour to get evidence of iTunes being bit-perfect - what format do you want? )

THIS is where I get annoyed, and feel the need to post in the internet - I just want people to recognise dodgy facts being fed to them ( -160dBFS noise floors and all ), and at the very least question them.
I'm sorry if you feel I am disregarding listening tests you have done, I am honestly not, but you don't know me, I don't know you, etc. etc. As I KEEP saying, Amarra does have a couple of useful features ( auto-sample rate changing, better volume control (IF USED)). If you consider the notoriously awkward way iTunes deals with sample rates, the chances of apples-to-apples comparisons is far from given.

your friendly neighbourhood idiot

IS try and get hold of the full version, with dongle, the download 'demo' version cuts out after thirty seconds and is franklya bit of a pain. Keith.

I hope you enjoy evaluating the demo version of Amarra and I look forward to hearing your impressions.

Personally I'm not a big fan of whether something is bit perfect or not. I am more interested in what sounds only what sounds best and thus I am not opposed to upsampling. I am only opposed if it sounds worse.

I know some people use the HDCD flag to determine whether the audio playback is bit perfect. To me that method seems to be an indirect method and does not explain differences in sound when for instance using a SSD versus a hard drive, a coaxial digital cable versus a different coaxial digital cable or a toslink optical cable, firewire cable or whatever. These are issues we usually never have to consider when we talk about transmitting digital data. Digital audio seems to be much different. Many people latch on to jitter and timing issues. Others suggest additional issues at work and are searching in earnest to explain, document and prove what they hear. IMO not unreasonable if you believe computer audio is in its infancy and all that can be known is not known.

Your handle may suggest that you are somewhere in between. We shall see.

CG wrote:

/begin CG quote

"Many people have verified that iTunes is bit-perfect"

I'd like to correct that.

Many people have *inferred* that iTunes is bit perfect. This is usually based on the measured performance of a single sine wave or by noting that the HDCD flag doesn't get corrupted. I have yet to see where somebody has actually looked at the bit pattern coming out of the USB spigot or the Firewire port. If somebody has looked at this, I'd love to read about it.

/end CG quote

---

well, perhaps not the bit pattern plumbing test you'd like to see, but some further interesting anecdotal evidence is Kent Poon's null testing on 16/44.1 data which consistently yields residuals in the vicinity of -144 dBfs. He also tested hi-res files; but of course it would be useful in that case if his metering extended further....

http://www.designwsound.com/dwsblog/?page_id=535
http://www.designwsound.com/dwsblog/?p=1591

[ edit - formatting ]