Jump to content
IGNORED

Is a 'buffer' a universal panacea


Recommended Posts

Probably a naive question but I would like to understand , you have a streaming device , Ethernet connection, once the data enters the buffer, there is no timing signal and hence no jitter at that point? Presumably jitter can be present at the spdif interface, I would just like to understand where does jitter appear in the 'chain' , finally how does an integrated cd player compare jitter wise? Thanks in advance ,Keith.

 

Link to comment

My take ...

 

If you have a device like a SB, I can't think of anything that would carry jitter at the end of the ethernet cable (in the SB). So, no way.

 

If all perceivedly starts with "timing", and without that - jitter can't exist, I would politely ask those who state that, how it comes that different software sounds different (though being bit berpect).

 

The integrated CDPlayer probably can be looked at the same; direct I2S from the reading laser, but putting the CDP upside down, put anti reflecting material on the CD, spray it with voodoo honey, blahblah etc,. helps. Still the CD was read error-free in the first place.

 

I guess we don't know much about it.

Ok. I don't.

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Chord Electronics, PS Audio and Naim's reply ... YES

Wavelength, Weiss, Berkeley Audio Design's reply ... NO

 

I think that sums it up :-)

 

Eloise

 

PS ... I guess I was talking about buffers in chain between SPDIF output of "transport" and the input of the DAC chip which is slightly different. In streaming devices the amount of jitter will vary depending on the architecture of the streamer, how good the clocks are, how the transport to DAC link is made, etc. - exactly the same as in a stand alone CD Player.

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

EVERY DAC has a buffer, of one size or another, implemented in one way or another. The key thing about buffers is that they have a rate at which data goes in and a rate at which data comes out. If these two rates are different at all, by the teeniest amount, the buffer will start to fill or empty, at a rate determined by the ratio between the two rates.

Conventional DACs use the clock from the raw data to drive the input and a filtered version of this clock to drive the output ( using a PLL ). The filtering used will vary in quality, depending on the manufacturer, and, in the case of SPDIF, some of the rate may be influenced to a small degree by the data being transmitted ( more in a bit ). The bigger the buffer, the less the output has to track the input, but the more the delay between audio coming in and going out ( possibly important for A/V ). If you don't allow the output to track the input in this kind of DAC, the buffer will under or overflow eventually, so some characteristics of the source will manifest themselves. Now, one manufacturer has come up with a solution which I'm sure can't work as described: They "pick" a frequency( from a fixed selection ) that is "close" to the audio and use this. However, in this case, the buffer will fill or empty, so at some point they will have to choose another clock, which must be a step in frequency away, which again will be a bit wrong, so the buffer will go the other way, and at some point they must select another clock....

 

and of course, there is intrinsic jitter of the DAC clock itself, which a buffer won't help with ( just needs good old-fashioned engineering )

 

your friendly neighbourhood idiot

 

Link to comment

Thanks for responding IS I rather hoped you would, in another thread you mentioned the possibility of two 'clocks' beating against each other ,did you mean the pre and post 'cleaned up' signal ?

Also you mention that, 'Conventional DACs use the clock from the raw data to drive the input ' where does that clock source emanate from, ( I realise spdif has the timing signal embedded) and can the dacs clock only be fully independent of the 'source' clock if you use an asynchronous sampling rate converter between 'source' and dac?

Thanks Keith.

 

Link to comment

Hi Coops,

 

the "beating clocks" I referred to is that it's generally a bad idea to have high frequency clocks inside a box which aren't locked together, because they will mix, which will generally exhibit itself as either noise, or random tones related to the two clocks.

The clock derived from the raw data refers to embedded SPDIF clock ( SPDIF has preambles, or illegal codes that are designed to be extracted to form the clock ).

Using an ASRC moves the problem from being time based into being data based, and is not a solution I like - effectively the ASRC manipulates the data into what will fit between the two clocks - the issue is that the filtering it does is based on it's measurement of the ratios, which it has to continuously monitor ( the two clocks will vary with respect to each other over time, as e.g. one gets warmer ) - however, boxes such as the Benchmark and Bel Canto both use these approaches, and both are well reviewed, so what do I know? I guess the key thing is that a DAC using an ASRC will react differently to different sources than one not using an ASRC.

The only way to decouple the two clocks is have the DAC control the source, which can be done with Firewire, Async USB, Ethernet or a feedback clock from the DAC to the source - again, all assuming they are done properly.

 

Your friendly neighbourhood idiot

 

 

 

Link to comment

 

welcome back, I_S

 

I've a question about oversampling.

 

Peter says that almost all DACs oversample. But only some seem to use ASRC. Can you offer an easy to remember description of the differences between the two? I can't seem to remember, nor do I know how to figure out which approach any particular DAC uses, e.g. my Metric Halo ULN-2.

 

Is it conversion to a fixed frequency (e.g. Benchmarks conversion to 110kHz) - that has no particular relation to the incoming frequency - that defines ASRC?

 

Seems like this ground has been covered already?

 

Thanks in advance,

Clay

 

 

Link to comment

IS wrote, ' Now, one manufacturer has come up with a solution which I'm sure can't work as described: They "pick" a frequency( from a fixed selection ) that is "close" to the audio and use this. However, in this case, the buffer will fill or empty, so at some point they will have to choose another clock, which must be a step in frequency away, which again will be a bit wrong, so the buffer will go the other way, and at some point they must select another clock....

 

Would you care to naim that dac?

 

Link to comment

I've read that white paper too, and while it goes into a lot of detail on many things (mostly way, way over my head) it doesn't say much about the buffer and what would happen if it either overflowed or emptied, or how much data it stores before it starts to empty. If the situation is analogous to a swimming pool being filled by one pipe and being emptied by another, you'd want it half full before you start emptying to allow as much leeway in either direction as possible.

 

I was just wondering if the logic that the buffer will inevitably fill or empty is valid: For example if both clocks are nominally running at 44.1khz, but the incoming clock is less stable, then wouldn't it vary from being slightly faster to being slightly slower? Therefore making it much more unlikely that you'd get overflow? Or have I completely misunderstood the situation?

 

Link to comment

but the buffer will begin to fill or empty - because there is deliberately no attempt to track the input clock, even if by some miraculous event one of the fixed frequencies exactly matched the source, this won't be the case for very long ( oscillators will change frequency over time, and especially over temperature ). Like I say, the paper isn't that clear, but as it's written, it doesn't seem the best idea I've ever read.

The best way to imagine this is you've got two watches, and you set them to the same time ( say midnight ), and one you've painstakingly calibrated to be extremely accurate. The second watch you've picked up from a market, and haven't touched - will they tell the same time forever?

 

As for telling if a box uses ASRC, most boxes that upsample to 192 use an ASRC, and I think the PS audio has a switchable one ( not sure about this, to be honest ). Notable exceptions to this rule of thumb are boxes from pro-origin companies

 

your friendly neighbourhood idiot

 

Link to comment

This maybe somewhat pretentious, or IOW I'm seeking for some truths myself here :

 

How "asynchroneous" is Firewire really ?

As far as I'm concerned some people started to spread the word it is, and before not so long ago I never realized it would or could. Today ? I am confused.

 

Allright, I own a Fireface800. From off the time I own it (2005), I know of its feature to control the sample rate. This is not about what you'd normally think with this, but this is about being able to do that in a continues mode. I mean, with a granularity of 1Hz. Thus, I can let play the music somewhat faster or slower. And not to forget : behind the Fireface is my DAC -SPDIF connected-, and it is really that which plays faster or slower. This should mean the Fireface is "tweaking" the original preambling, so the DAC just keeps on clocking by means of that embedded clock data.

 

In the mean time the Fireface connects to the PC via Firewire, and at the other end of the chain is the playback software. For my own argument's sake : this is XXHighEnd, because I know exactly what happens in there ... which is : well, filling a buffer when it starts to run empty. This buffer is on the PC side, and the driver will dictate when it's time to fill the buffer.

 

Of some importance is the fact that this latter is nothing special, and it works like that with every connected means (soundcard, USB DAC, Firewire, name it).

 

I never understood well (but also never thought about it really) how the Fireface could dictate the speed at this (1 Hz granularity) level. Of course, when it is an asynchronous connection it can, but this sure does NOT mean (at all) that there's a buffer playing an important role here, because the only thing what happens really, is that the buffer at the PC side (just being an area of memory) is "the buffer we try to talk about here", and it is nothing special (because used always, and used always like that hence the same way, from the player's view).

 

What must be happening is that the hardware (Fireface) talks to the driver about the speed it wants, and something at the PC side takes care of this (speed of) output samples.

There is sure no buffer at the DAC side, and there is a very small buffer at the Fireface side (48 + 116 samples in my case, and this really can't play a role as to how it is suggested in the before posts).

 

For side info : at a higher level there's the rough sample rate setting (like 16/44.1 and 24/96), and it is the player software setting that, it is the (in this case) Fireface which really will change clocks, and it is the DAC doing the same.

This is completely outside the 1Hz which *also* can be dictaded, but it is the Fireface doing that, or better the driver on its own. The rest will follow (player and DAC).

 

I don't think (but I am not sure) that the data over Firewire will carry (or can carry) jitter. I think this is just data. For that matter it would be right that this type of connection is asynchroneous ...

 

But now I have another Firewire device. In fact I have more of them, and they are all working by means of the same firewire receiver chip, and they are all based upon the same (driver) software. No, I won't name the brand for now, but when time comes I may because of angryness (never mind);

From this main Firewire chip I know it has 4MB of memory on board (not on chip, but on-PCB). This 4MB of memory could be used for various (DSP) activities, but I think it is used for the type of asyncronous we *do* talk about in this thread. The memory can run empty, and it can run full. Oh :

 

It just s*cks ALL OVER.

 

There's buffer settings in there similar to what I'm used to from the Fireface, and there's also explicit settings for the PC being the master and "Firewire" being the master. That too is similar to the Fireface, with the difference (which I not quite understand) that the Fireface always allows that 1Hz control, no matter the (master/slave) setting (which should come down to it never can slave to the PC really).

In the case of this most poor Firewire chip ugly thing, only when you are lucky the thing doesn't start (vinyl like) clicking, which merely happens at too large buffer settings than too small. There seems no way to let it work as should, no matter the master/slave setting.

 

Now, and this could be my message, before we all think that "Firewire = Firewire", this is not so. Apparently more implementations exist, and where the Fireface applies one of them, the two other main Firewire chip manufacturers apply another. As far as I can judge, at least one of these other two tries to maintain two clocks (one at the PC side, one internally), and this (most obviously) cannot work.

 

To me (and this is the pretentious part) it looks like not all Firewire devices (and I mean as a complete box, sold for the Pro environment) is made for streaming audio. MIDI will do allright, because it is totally unrelated to buffers running full or empty, but streaming audio, no.

All I can say at this momentis, be warned; besides there seems to be more than one definition (for the subject here) devices are out there we really shouldn't by for "PC audio" applications.

 

That's all.

Peter

 

Edit : Xpost with I_S, and I apparently have the proof of it. :-)

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

I didn't want to be ahead of I_S regarding your question about the ASRC, but

 

As for telling if a box uses ASRC, most boxes that upsample to 192 use an ASRC

 

What I meant in the other thread was that all sigma-deltas won't use it (there's just no application there because of the inherent working of those (OS to 64-512 in the first place), and the multi bits *will* use it, because it is the best and cheapest way to attack (incoming) jitter. And as I tried to explain overthere ... apart from the few ignorants which try to attack incoming jitter by other means, and which try to avoid the SRC because it is (perceivedly) no good by itself, therewith making the solutions expensive (or not working haha).

 

Thanks,

Peter

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

IS ok, we have the data sitting on our hard drive, twiddling it's thumbs, we plug into a spdif connector.

Is this instance is the data sent to the dac or drawn into the dac, there is an embedded timing code ,the 'timed' data enters a buffer where it may ( or may not ) be cleaned up and 'reclocked' which may reduce jitter?

The DAC's clock can only be fully independent of the source clock if there is an asynchronous sampling rate converter between the source and the DAC?

Just going back to 'two high frequency clocks in the same box which aren't locked together ' do you mean the incoming timing signal and the 'cleaned up' outgoing signal, or the example you cited where the manufacturer has chosen frequencies which he hopes will match?

Finally the ASRC ( cited above ) that presumably is quite different to 'Wavelength audio's asynchronous USB, which Ayre have licensed?

Thanks again for all your help, it is greatly appreciated.

Keith.

 

 

 

Link to comment

Mark Levinson has used a "FiFo" buffer on their (discontinued) 36(S) and 360(S) series (maybe on their flagship 31.5(.6) too?).

 

And Lavry uses this sort of Buffer on some AD convertors and the 924 / 2002 DA.

 

See: http://www.lavryengineering.com/white_papers/jitter.pdf

go straight to page eleven and read on.

 

It may be a "better" way as to use a ASRC (for the same purpose), but the bottom line still is the (a good) implementation.

 

Cheers

Harald

 

Esoterc SA-60 / Foobar2000 -> Mytek Stereo 192 DSD / Audio-GD NFB 28.38 -> MEG RL922K / AKG K500 / AKG K1000  / Audioquest Nighthawk / OPPO PM-2 / Sennheiser HD800 / Sennheiser Surrounder / Sony MA900 / STAX SR-303+SRM-323II

Link to comment

Other FiFo buffers exist in...

Chord DAC64 & QBD76

Genesis Digital Lens (standalone SPDIF in and out)

Meridian G68 and 861 processors

PS Audio PWD (on output admittedly so slightly different)

all respected products IMO so to say it can't work is obviously wrong. Yes at points you will potentially have buffer under or over runs but presumably the logic is clever enough to work out and sort this between tracks, etc.

 

Anyway that's my reading of the situation / technology as a fully paid up member of the IACEC (International Arm Chair Engineering Club).

 

Eloise

 

PS. The Naim DAC should avoid some of the "two clocks" problem when used with the external PSU as the input is powered separate from output of the DSP IIRC.

 

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Hi,

 

there seems to be some marketing spiel about the use of "intelligent" buffers, where you don't have to synchronise the clocks because there is enough slack that you resynchronize between tracks etc - I don't know of a single DAC that uses a buffer like this, because: You can't guarantee that there ever will be a gap big enough to resynchronize your buffers - think, for example, of 70 minute+ orchestral pieces with no gaps, and especially with PC audio the opportunity to have several hours' music without a break... additionally, the buffer needs time to fill, and if it's big enough to take all the slack that's several seconds - Chord, for example, has I think a 4 second buffer - that should be enough for an hour or so between two clocks that are relatively closely matched, so it can't "reset" it's buffers without a 4 second gap in playback...

 

a FIFO is just a buffer. Any DAC with an FIR filter in it anywhere must have a buffer at least the length of the filter. Bigger buffers are required for synchronisation schemes, but it's not what you've got, it's how you use it :)

 

To go back to an earlier post, the async USB ( as used by Wavelength, Ayre & dCS ) definitely does not use ASRC. The async bit refers to the fact that the audio is not synchronous with the USB frame ( which is a good thing! )

Also, the typical use of SPDIF is that the clock is embedded in the audio, so is "pushed", but there are some schemes where the SPDIF is synchronised to another clock, which may come from the DAC, making the SPDIF purely a data transport.

 

your friendly neighbourhood idiot

 

Link to comment

I_S,

 

I'm slightly confused about your overall thoughts on the concept of usig a buffer to reduce/eliminate jitter.

 

If I may, I'd like to use the Chord as an example as I've some familiarity with it. As you say, it has a few seconds buffer. Wen you press play on the transport, it takes 2 seconds (while the buffer half fills) before sound begins. Chords assertion is that the output of the buffer is completely independent (with regard to timing) from the input so the sound is unaffected by [jitter from] the transports SPDIF / AES interface. Obviously if the difference between the input clock (transport) and the output clock (DAC) is great then the buffer will either fill or empty and either there will be a delay in the audio or the audio will skip. I've never noticed this in listening though.

 

Within the limits of the 2 second buffer, does this claim hold water or are you doubting the usefulness of the whole concept?

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

I would say that by having such a large buffer, the tracking of output to input can be much slower ( i.e. the jitter can be more attenuated at a lower frequency ). However, it must still track the input in some fashion - if you do the maths, if e.g. the CD player source is 300ppm faster than the DAC clock ( which is well within spec ), 300ppm= 44.113kHz - so every second you are gaining 13 samples more than you are processing. A 2 second buffer at this rate is 88200 samples. 88200/13 = 6784 seconds = a bit under 2 hours for the buffer to overflow. I think the SPDIF spec is 1000ppm, which gets you about half an hour...

This may sound OK, but when does the buffer resynchronise itself? It can't wait for a 2 second gap in the music - apart from anything else, this would remove gaps that may have been intentional. So, it must track the input, but it can do it slowly, hence it can do a good job of getting rid of jitter. It's actually quite a good solution, if you can tolerate the delay, but it still can't be as effective as the DAC being the master type of solutions, especially if the absolute frequency of the clock is important

 

your friendly neighbourhood idiot

 

Link to comment

I'm surprised that nobody in this discussion has mentioned such a producer as MSB Technology. When I did choose DAC I had alike questions. This is what MSB Technology representative told me: „The unique feature of our DAC is our complete reclocking. We put the audio into a buffer on our DSP and clock it out using high-precisions oscillators (TCXOs). So with the complete ground isolation that our USB input has or that Toslink provides, combined with the reclocking system in our DACs, you can make a computer as good, if not better, than any other transport.”.

 

Of course, the question arose for me about possible buffer overflow or its emptying in a case if I’m listening to the disc without pauses between tracks. Here is the answer: „When we designed the buffer, we planned on CDs without pauses such as Pink Floyd. We also have other albums that are without pauses. If it does reach the end of the buffer, it would reset itself and there would be a small tick in the audio. None of our customers have experienced this problem and we’ve been shipping Platinums with the reclocking system for years.”

 

In my view the best solution (better than asynchronous transmission in which DAC plays a role of a host) is right like that used by MSB Technology. Of course, much depends on quality of implementation of the principle, but I do not doubt that in the case of MSB Technology.

 

 

Link to comment

So would it be fair to say (in agreement with Chord) that using the buffer removes to a fair extent the reliance on the transport and can remove a significant amount of jitter that exists; however if you can have a transport that it tracking the frequency of the DAC, i.e. via Word clock or an async connection, then that jitter doesn't exist in the first place so is even better.

 

I think the sizing of the Chord DAC64 buffer was designed so that a 1000ppm varience on a 74minute CD would be accounted for - it's only with computer audio that this no longer seams reasonable. In addition it must also use other methods to sync as you cam turn the buffer off for latency issues. (I'm unsure if the is increased with the new QBD76)

 

Eloise

 

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Eloise, you're post, as I've come to expect, is accurate and to the point - the Chord buffer does seem to have been chosen for precisely that reason.

 

As for nabadanga: How is having a DAC that ticks/clicks occasionally dependent on the source better than one that doesn't, that could use just as good a clock?

I know people like vinyl sound, but adding ticks is surely going too far?

 

your friendly neighbourhood idiot

 

Link to comment

I read this on the Naim website:

 

"The Naim DAC has more in common with Naim CD players than with conventional external digital to analogue converters. It overcomes the jitter issues of S/PDIF by reading the data into a “rotating” data RAM buffer independently of its timing signal and reading it out again clocked by one of ten extremely low noise, fixed frequency crystal sine-wave oscillators. In terms of system topology, the DAC’s rotating memory is analogous to a rotating CD feeding raw data to be re-clocked. The rate at which the memory fills and empties is controlled by the DAC automatically selecting the oscillator that matches the average incoming clock frequency. The data entering the downstream digital filtering and DAC chips is then completely isolated from the incoming S/PDIF jitter."

 

Which does rather confirm my growing impression that this particular buffering technique is taken from cd player design. Not really surprising given the manufacturers using it. Doesn't make it bad, of course, but it's helpful to know when you're putting together your setup. For example if you've gone down the route of building / optimising a computer dedicated to music playback (solid state drives, special playback software, stripped down os etc) you may be less interested in this.

 

My next question would be: Given that with a computer source there is no fixed maximum time for a piece of music (unlike cd), what are the audible effects when the dac 're-sets' it's buffer. Is it intelligent enough to know when there's a gap and so on. I imagine some people won't care about potential clicks (depending how frequent) while for others it would be a deal breaker.

 

Also, still wondering about latency. Not a big deal for music playback, but very important for video or games. Yes I know gaming is 'for kids' but speaking frankly as an adult who should know better, if I'm spending close to two grand I want to hear my Gran Turismo cars growl when I press the button.

 

Link to comment

Hi,

 

I'm afraid the "rotating data like a CD player" analogy reads to me that they are using a circular buffer :

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

 

Which is... used everywhere that you see a FIFO ( buffer )....

 

I don't mean to bash the Naim DAC, but it does seem to have a more concerted set of marketing technobabble than normal.

 

As for a buffer reset, this, depending on the implementation will either be a fairly large "click", or a repeat of a bit of audio. I can't believe that they could let this happen - what I suspect will happen is as the buffer approaches full, or empty, it will select a different frequency for the master clock. To me, this seems iffy, as (a) it is caused by the source, and (b)because they only have 10 "frequencies", the new oscillator must have a step change in frequency, which is probably not a good thing, and how often it has to do this will be affected by how big the buffer is ( e.g. you may have latency issues ), and the source. They haven't stated yet how big the buffer is, so I couldn't tell you if it will be suitable for your Gran Turismo/Rock Band usage...

 

Like I've said before about other things I can't tell you how it sounds, having never heard one, but I can tell you if I reckon the technical stuff sounds dodgy, or is not quite as radical as claimed. Again, this particular DAC probably doesn't work quite as the marketing describes it, the important thing is not to get carried away with all the hyperbole, and trust your ears,

 

your friendly neighbourhood idiot

 

 

Link to comment

Not all buffers are created equal, most as pointed out here, are still reliant on synchronizing with the input clock someway. Two products that have entirely independent output clocks are:

1. The Genesis Digital Lens

2. The PS Audio Perfect Wave Transport

The Digital Lens would indeed occasionally have dropouts when it ran out of buffer. This problem does not occur in my experience with the Perfect Wave Transport. I also believe that Empirical Audio's Pace Car, and related products utilize a large buffer with an independent output clock, and that Chord's buffer also operates this way, but I am not certain of this. Too bad Steve Nugent does not post here anymore, as I think he could shed some light on this discussion as someone who has a lot of experience actually designing and producing products that use buffers with independent clocks.

As a side note, the buffer in the Perfect Wave Transport is quite large, it is quite fun to demonstrate this: one can eject the disc and the PWT will continue to play for quite some time (up to 5 minutes or more with 16/44.1) before the buffer runs out.

 

 

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...