Is a 'buffer' a universal panacea

[Audio_ELF]

The issue with both the PWT and Genesis Digital Lens is that they both place the buffer separate from the DAC and then rely on a "flawed" link (SPDIF or i2s). So while the output from the buffer is independent from the transport, it's surely also independent from the DAC's clock (yes i2s link on PWT might limit this independence).

 

IIRC the Genesis Digital Lens was designed by one of PS Audio's original founders - is this right?

 

Eloise

 

[barrows]

I am not advocating the use the digital lens, I am just pointing out that it did offer a deep buffer, with an independent output clock, and was quite successful in its day as a jitter reducing device.

I2S from the Perfect Wave Transport makes the clock in the transport the master for the DAC, so with this setup one has a single fixed frequency master clock for both the transport and DAC. The only potential drawback for the PWT/PWD system connected by I2S, is that any clock signal will be subject to slight degradation when transmitted over a cable, as no cable has infinite bandwidth and zero rise time. BTW, this is the same limitation that is present with any separate clock connected to components via a cable (as used by dCS, Esoteric, and in virtually all recording situations).

The original Genesis Digital Lens was conceived and designed by PS Audio founder Paul McGowan, and current PS Audio engineer Bob Stadtherr. The Perfect Wave Transport and Perfect Wave DAC was conceived and designed by a team of engineers, including outside engineering consultants, as the PWT is a memory player and required quite a bit of development.

 

 

[idiot_savant]

but the clock systems quoted ( using a wordclock ) will use a PLL inside the DAC to filter ( de-jitter ) the clock. You're exactly right in that clocks will degrade over distance, and this is why I'm not a huge fan of I2S between boxes, as you can't then use a PLL... ( there is a thread somewhere with my thoughts on I2S )

I do think PS audio are being quite clever, as HDMI cables will be very good in terms of termination, etc, and I'm sure they make good products, but from what I've seen on the measurements ( HiFi News ), it's certainly no better, and probably quite a bit worse in jitter performance than other products using the evil SPDIF....

 

Why doesn't anybody use SDIF-2 anymore? Interface designed for external use, 3 wires, one for clock, 2 for data, big company backing it ( Sony )

 

your friendly neighbourhood idiot

 

 

 

[PeterSt]

All,

 

Maybe I can comment a bit further on what happens when a buffer -like discussed in here- under- or overruns;

 

First of all this is nothing about being without data suddenly (underrun). Because remember, this buffer is additional to the normal means of buffering, and that normal means will be waiting to stuff in the waiting data. So, it is the clocking at the "additional" buffer that makes it run empty at the attempt to be without jitter.

 

Now, when this is corrected, there is nothing like a dropout or anything, but the sequential data just is not sequential anymore, and a (small) range of samples will be skipped. Maybe this is not easy to understand, but this is related to the virtually perceived latency which is not in order in the first place. I mean, when a buffer starts empty, it is certainly not necessarrily so that it first needs to be filled FIFO. It can be filled starting at the end, and when a few samples are there playback can start and the remainder is filled. So, when the buffer is full *then* you will have latency. This latter is again not necessarily applying when pressing stop, because the DAC can just abort playback, instead of emptying the buffer first.

 

Having said this, what happens at e.g. overruns, is that a small amount of samples is cut out. Small can be even 100, and actually you will never notice. However, because the voltage from the last output sample over to the 100th sample after that may jump at a too large amount, you will hear a tick. This tick is minimal, and really vinyl like, but more fragile (because way more shorter -> 1/44100 of a sec).

 

I even dare state that designs may explicitly anticipate on such a situation more often than once per 74 minutes etc., because it really takes a more high resolution (resolving) system to hear such fragile ticks in the first place. Meaning : those who design like this explicitly may never have heard it, and missing 100 samples out of 44100 really is not audible if it would happen once in the, say, minute. The "tick" may though, but sure not on your PC speakers.

 

At underruns really similarly happens, but an additional 100 samples are repeated. That too will go as unnoticed, and for the exact same reasons a tick may occur. May ... because it really needs a huge voltage step to create this in the first place. So, if I were to design something like this, I'd wait untill the buffer is almost empty or full, look ahead for similar voltage levels, and cut (paste) right there.

 

Peter

 

 

[sq225917]

If your buffer is big enough, and your transport vaguely within spec, then the chances of ever emptying or filling it are on the right side of negligible. Instead of thinking about it as filling a swimming pool and emptying with a hose, replace the hose with a dripping tap on either end, that's probably a more accurate representation.

 

If your buffer is large enough, and the source read speed fast enough, all that counts is the precision of the data/clock on its way out of the buffer to the DAC chips, because before you make that conversion to analogue, ASRC excluded, there is no jitter.

 

Naim are certainly 'egging the pudding' with their descriptions and wishy washy vagueness, but they do have considerable processing power in that box, more than most consumer dacs, hopefully they know how to use it.

 

[idiot_savant]

people are discussing whether ticks are big or small, and how audible they are?

 

As for the swimming pool/tap analogy, we've already done the sums here: to meet spec, the buffer will over/underflow if we don't track the input at all. The Chord example cited required a 2 second buffer to deal with a CD's worth of data "from a reasonable source", which is not a dripping tap in a swimming pool. This is true if you have a Z80 or an i7 unless you are going to manipulate the data ( ASRC ), which, again I think is a bad idea...

And don't forget, a big buffer means big latency, which for at least one poster here is unacceptable....

Don't forget, for a DAC, you could be talking about an awful lot of uninterrupted audio ( think about going on holiday, leaving your tap running into your swimming pool )

 

this is true for all DACs, not just Naim ones...

 

your friendly neighbourhood idiot

 

[Audio_ELF]

Lets face it; there is no (so it seams) perfect way to transfer digital audio to the DAC. There is always compromises ... We just have to decide what compromise we're willing to make. Remember that you can't always control the input so we need someway to sync the clocks: using a buffer is one method of doing that just as ASRC and PLL are others. Or can use i2s to transfer data and run into a whole nother raft of issues. Or use a Word Clock which have other issues. Maybe async USB or FireWire removes the issues, or maybe they just introduce new issues. What's really relevant when talking about specific DACs is the end result.

 

Just a note: the Chord QBD76 has both the buffer and also a WordClock out to your transport if you choose. Not sure how much the WordClock would improve a computer link (via dual AES in the Chord's case).

 

Eloise

 

[idiot_savant]

Yes, I'd absolutely agree that there will be compromises to be made- I just find it hard to believe that a DAC that ticks/pops occasionally would be a compromise anyone would be willing to make!

 

It would seem that Chord offer a good choice of jitter reduction schemes, so I'll take my hat off to them.

 

I still don't understand the bluetooth input on the new box, though ( which can be MP3 standard at best... ), but what do I know? Has anyone tried it?

 

your friendly neighbourhood idiot

 

[Audio_ELF]

I agree ... Ticks and so are would be unacceptable to me (on a DAC or on my dog) ... I've not heard any reports of such from the Naim DAC but do t know how t copes with buffer under/over runs. My comments about compromises were meant more generally. I also can't see point of BlueTooth AD2P on the new Chord DACs though I like them generally.

 

Eloise

 

[barrows]

As to the Perfect Wave Transport specifically: this product does not suffer from buffer either running out, or being overfilled with data, the clock on the output of the memory IS entirely independent from the transport mechanism: this is not a video product, so latency is a non-issue-these are facts and not subject to interpretation in any way.

The measured losses in cable transmission of the clock signal to the DAC, over a proper HDMI cable of 1 meter in length introduce less jitter than the jitter inherent in most (PS Audio did not use every possible PLL implementation) PLL circuits, and the inherent jitter in the clock itself is just a handful of pS.

The PWT and PWD units tested by Paul Miller were pre production units, and were not the final versions by any means, even so, jitter performance was quite acceptable (comparable to high end products such as those made by Esoteric) without resorting to engaging the ASRC and/or a PLL, both of which are questionable in terms of sonic performance.

It will be interesting to see what happens when current production units of these products are tested independently.

In any case, is a buffer a panacea? IMO, no, of course not. A properly implemented deep memory storage, with an independent fixed frequency output clock is one good way of keeping jitter low: the key to producing low jitter is to design a system that allows the use of a fixed frequency, independent, low jitter clock, and a well designed buffer is one way of achieving this. Other ways I am aware of are: Firewire, Async USB, and networked interfaces. Other "solutions" to lowering jitter seem to me to be band aids in comparison (ASRC, PLLs) intended to "filter" jitter after it has been allowed to occur. These band aid type of solutions tend to measure very well, but their sonic performance is questioned by many people, myself included, in listening comparisons to products which do not use them.

 

 

[idiot_savant]

The buffer is irrelevant(ish)... the transport itself is ( or should be! ) clocked by the clock driving the output, which is not the case in a DAC ( unless it is providing the clock ).

Buffers are cheap - to build a PC with a transport, providing several hours playback from a buffer could be done for 300 pounds/500 dollars....

 

I'm not trying to have a go at PS Audio here ( or anyone else ), but surely if the pre-production units were good enough for positive publicity for a review, then any sub-par performance in regards to a key marketing point has to be recognised? If I were Ferrari, and said my new whizz bang engine provided better acceleration than a Porsche, but it was measured to be worse, would that be acceptable?

 

Again, I'm sure that the PS audio products sound lovely, but if I were making a pair of products like that, I would make the DAC the master....

 

your friendly neighbourhood idiot

 

EDIT I am not aware of any product that would be as foolish as to allow it's buffers to overflow/empty ( although apparently MSB do ). All I am trying to point out is that to stop this there must be a link between input and output...

 

 

[Audio_ELF]

If my understanding of the way the PWT utilises a buffer than it works different from (say) the Chord.

 

If I may use a couple of analogies, the PWT is like a cistern with a ball cock valve. Initially the cistern is filled at a high rate (the PWT's drive reads at 2x or greater IIRC), while the tank is being filled, the water flows out of the bottom at a constant rate. However the input flow is greater and at some point the tank will become close to full and the ball-cock will close the valve. The output flow continues and so the ball-cock open the valve again. The point being that the flow INTO the cistern (or buffer) is controlled so it will never over flow nor be empty. This system works in the PWT because it has control of the transport AND the buffer. It then uses the i2s link which basically makes the PWT and PWD work as an integrated player.

 

Now with the Chord DAC there is still the cistern but in this case it is being filled by a tap which is turned on to approximately the same rate as the output tap. We wait before turning the output on until the cistern is half full so hopefully the cistern will never empty completely. However if the input tap is too quick, eventually it will fill the cistern and some water will overflow and be lost. The concept relies on the fact that we only have a smallish tank (a CD worth of music) supplying the cistern and that will empty before the cistern over flows.

 

Not sure if these analogies work completely, but hopefully they show the difference between the two uses of a buffer.

 

Eloise

 

[barrows]

I do not agree that all DAC interfaces are compromised. As far as theoretical performance is concerned, there are two things which should matter, data accuracy, and timing. To interface a DAC with a computer one should get perfect data accuracy pretty easily, so all we need to consider here is timing. Properly implemented Firewire interfaces, Async USB interfaces, and network interfaces all have the clock in the DAC as the master, and can utilize a fixed frequency clock with very high accuracy. As such when properly engineered these interfaces should produce the lowest possible level of jitter, subject only to degradation from intrinsic clock accuracy and internal engineering details (temperature control, board layout issues, rf pickup, voltage control/power supply design, etc.).

In comparison to these types of interfaces, SPDIF/AES interfaces are inherently flawed because they always require some kind of negotiation of the differences between the DAC clock and the source clock.

Idiot, I mostly agree with your points, but I will make one exception: building and bringing to market an audiophile product with a large buffer, sophisticated enough to utilize a fixed frequency output clock is not an easy (or cheap) task. I am not talking about the actual parts cost here, but the R & D time to develop these designs is quite high in comparison to usual engineering done by most audio companies; the R & D resources of audio companies are pathetically small compared with computer companies that rely on selling hundreds of thousands of units of their products to recoup development costs.

The Perfect Wave DAC will operate with the DAC clock as master when it is used as a network player. When the PWT is used with the PWD, the clock in the transport must be the master, as the data must have a local clock to time it out of the memory, the degradation of this clock signal through the I2S interface is really not bad at all, and the I2S interface performs at a much higher level than the SPDIF interface. The PWT was developed for those audiophiles who want the best performance from a physical media player, without a computer involved in their system.

I guess my main point in these posts is to really stress that the SPDIF/AES interface is really flawed, and as audiophiles we should really be demanding products that address this shortcoming, instead of making excuses for why we should use products that rely on SPDIF/AES. I am not suggesting that some DACs, connected by SPDIF/AES cannot offer excellent performance, but I am suggesting that a given (SPDIF/AES) DAC's performance would be improved if it offered a better interface.

 

[Audio_ELF]

Barrows said... "The Perfect Wave DAC will operate with the DAC clock as master when it is used as a network player. When the PWT is used with the PWD, the clock in the transport must be the master, as the data must have a local clock to time it out of the memory, the degradation of this clock signal through the I2S interface is really not bad at all, and the I2S interface performs at a much higher level than the SPDIF interface. The PWT was developed for those audiophiles who want the best performance from a physical media player, without a computer involved in their system.

I guess my main point in these posts is to really stress that the SPDIF/AES interface is really flawed, and as audiophiles we should really be demanding products that address this shortcoming, instead of making excuses for why we should use products that rely on SPDIF/AES. I am not suggesting that some DACs, connected by SPDIF/AES cannot offer excellent performance, but I am suggesting that a given (SPDIF/AES) DAC's performance would be improved if it offered a better interface."

I'm not sure all would agree with you on the SPDIF vs i2s suggestion. I would hazard that Naim in designing their DAC would have investigated using a direct i2s link considering they have also had to redesign their CD Players to add SPDIF link and it would have been just as easy to implement i2s IF this had given them better performance. If you know Naim's philosophy, then you will know that for a very long time they have resisted 2-box players (splitting DAC and transport) and it's only now they feel they can get the performance (of if you are cynical only now can they market 2-box player).

 

The great thing about the SPDIF / AES interface is it is universal. The DAC (to a greater or lesser extent) doesn't care if it's connected to a £50 DVD player, or a £15,000 dCS transport. Part of that universality is because of jitter reduction techniques such as buffers, ASRC and PLL. Without those you have a mess. i2s is only relevant when connecting two pieces designed to work together - basically splitting a one-box player into two chassises, while still treating it AS a one box device. The advantage of doing this is possible reduction of PSU noise and improvement of PSU stages as you have more room. However you are also extending the i2s link "out of the box" something which (while PS Audio have implemented it and it is shown to work in this case) it really was never designed to do. All this talk of i2s is really nothing to do with "computer audio" except that the way the PWT works you can quite easily consider it to BE a computer.

 

Anyway thats enough of that and I think explains my thoughts.

Eloise

 

[PeterSt]

Let me first state two things :

 

1. I am not here to be "teaching" or anything, and the last thing I would do is "teach you";

2. I certainly do not say a buffer method can't work. This, despite my earlier post about a completely flawed implementation of it.

 

Referring to this earlier post about the Fireface, this (IMO) "just" uses a smart driver, sending out the packets when the hardware needs some. This method needs a special driver, and anything can be done. No big deal and nothing different from the USB Asynch DAC I worked on myself (that needing a special USB driver).

But of course this doesn't work for everything and all, and better would be to use the common drivers. Now :

 

When you read the way Naim approached this, it may be the easiest way to understand what *may* happen, with a guaranteed always sufficiently filled buffer. Btw, this is how I perceive it, and if this is wrong or in doubt, let me know.

 

The 10 clocks Naim uses, are tweaks upong the normal communication with the sending instance (say, the PC). In fact this is about *another* buffering means, but at the same this is the "normal" buffering means. Thus :

When at the DAC side a dummy clock is clocking in the data, dat dummy clock being real to the sender's side, that buffer (being the memory) is filled at the speed just needed to keep it, say, half full. What Naim does, is hop over to another (slower) oscillator when the buffer starts to run more than half full, the same when it starts to run out (faster oscillator). The PC just looks at a clock, and it clocks out as told.

 

At the other end of the buffer there's the DAC, and wether it's fast or slow, and even whether it's stable or not, all doesn't matter as long as the 10 oscillators are able to cover for the "unequal" speed, with the buffer itself as a measure for that (meaning : any program running in there only needs to look at the balance in the buffer, in order to see whether things are running slow or fast at the input, and when slow, select a somewhat faster oscillator).

Again, no big deal, although it wouldn't be my solution because it incorporates hardware, and this is less my thing.

 

All 'n all this is what I would call a "tweak", because it all runs on existing implemenations (the PC doesn't know the difference and nothing has to be changed on that side, and the DAC too doesn't see any difference from without such an implementation).

 

The way the "cistern" solution works, beautifully described by Eloise, IMO is of another kind, and although I'd call that a tweak too, I think this needs special drivers at the PC side always. This is exactly how I would solve things (worse, I am working on that right now), and is perfectly suitable for Firewire because (stupid reason) Firewire involves a special driver in the first place. It really doesn't take more than telling the PC side another burst of packets is needed, plus the (earlier agreed) message how large the buffer is. This by itself may be called a tweak too, because agreeing upon the size of the buffer is happening always, but in this case it can be 4MB etc., and once behind the driver (towards PC) nothing sees the difference and player software would just be pumping longer with longer rests (I know my player software and it really wouldn't care less).

 

All 'n all, and to get to some consensus, I would never agree upon the means MSB uses, anticipating on the length of a CD. However, I think if I had to make a solution like that you would not notice where the "resets" took place, even if they were to be there each minute. Like I said, this is only a matter of aligning similar voltages (always to be found) and the few samples missing (equal to the PPM of the output clock) will go unnoticed.

But then I would never do that, because at least I'd know about it, and because of that I will be hearing it. :-)

 

Peter

 

[DavidL]

A very enjoyable discussion, though these water flow analogies are really missing the point.

 

We are not talking about keeping in synch with a time-varying phenomenon that is once-and-for-all; the audio data we wish to extract remains available on the disc all the time - it is not lost. Given the high data-transfer rate possible and the speed of processing available, there should be no problem in getting specific data off the disc whenever it is needed. Obviously this presumes that any chunks of data that are read in this way can be re-assembled perfectly in synch for output.

 

I've no knowledge of exactly how this process is implemented on the PWT, but my experience with this transport so far (spurious track numbers displayed during the play of a single track) leads me to guess that an algorithm that detects short periods of 'silence' is being used to chop up tracks into more manageable chunks. For hi-res audio this is probably essential as one track would give too much data for the memory available. Re-assembling these chunks for output would not require super accurate clocking.

 

David

 

[Audio_ELF]

The analogies to cisterns and water tanks are not perfect, but waseant to show how the PWT buffer is very different to the Chord (and others). In the PWT the flow INTO the buffer is controlled. With the Chord the buffer has to try to accept all the SPDIF data the transport sends. Therefore in the Chord the transient data is lost as there is no mechani to ask for the data to be resent.

 

So respectfully you are missing the point of the analogies, they are completely demonstrating the point I was trying to make.

 

Eloise

 

[DavidL]

Your comments are consistently to the point.

 

David

 

[barrows]

Eloise: I agree with you on SPDIF being a current standard, and if one is going to use SPDIF I believe a large buffer in the DAC, with a fixed frequency clock on its output is the likely the least offensive way to reduce jitter.

The problem is the flawed SPDIF interface, why not demand that we get rid of it for something better? I do not know if this is still the case, but when I was associated with PS Audio the plan was to make the I2S interface open source, and free to any other manufacturers who would like to use it. The idea was to promote getting away from SPDIF and create a new standard. Hopefully this is still the case. BTW, I am pretty sure there are also modders out there who will provide an I2S input/output on existing DACs and transports to match up with products using this interface.

In any case, this being "Computer Audiophile" I still think we should really promote the best computer interfaces here, and these seem to be: Firewire, Network, and Async USB.

 

[manisandher]

@Eloise,

 

You said, "Not sure how much the WordClock would improve a computer link (via dual AES in the Chord's case)."

 

It wouldn't necessarily* affect the link from the computer to the interface, but would certainly affect the link between the interface and DAC.

 

I find that feeding the wordclock back to the interface (i.e. having the DAC as master and interface as slave) is superior. (But this has to be done properly, i.e. using 75R BNC connectors and taking care of correct impedance termination, etc.)

 

If you're using a DAC with an spdif/AES input and a wordclock output, and an interface with a wordclock input, I strongly recommend that you use the above configuration.

 

* I'm still not clear how an interface (e.g. the the Lynx AES16 or Weiss AFI1) 'controls' the audio stream from the computer. But if you are playing a video on the computer and streaming the audio through the interface, changing the clock frequency at the interface changes the speed of the video.

 

Mani.

 

[Wavelength]

Gang,

 

Well there is jitter in any serial system. BUT we are only really worried about the Audio Serial system. So anything ahead of that is pretty much associated with getting bit true information.

 

Ok so the delivery and anything inside of the computer does not increase the jitter.

 

Now things going on inside the computer can effect the sound and can have an impact on the Audio Jitter, such as Adaptive USB and Native Audio in Firewire.

 

But really all of those issues plus the INTRINSIC jitter of the dac only comes into play iniside the DAC. See the jitter caused by Adaptive mode or Native mode on Firewire does not happen on the link. These variables only effect the receiver chip that puts the received data into a serialized Audio Stream. So this variable + the intrinsic jitter (jitter caused by poor power supply design, poor oscillators, PCB layout, etc...) will be the total jitter than the dac chip itself sees. Some of which it will reject and some will have everlasting effects.

 

With all interfaces except SPDIF the computer tells the device the rate for which the sampling will take place. There is no actual clock on the data.

 

With SPDIF it is totally different because you are wrapping the Audio Clock around the Data and sending it out. The receiver pulls the data and clock apart then runs the clock through a PLL to create all the clocking information for the data before it spits it out.

 

Thanks

Gordon