New DAC from Merging Technologies for Home Audio Market

dallasjustice · January 10, 2015

Dallas, I always like your posts. By why are you excited about the NADAC when Hapi already exists?

I rely on DSP filters for playback. To create the best possible filters, it's very important to use really good test gear. For my purposes, the HAPI is a better fit. So I don't plan on buying an NADAC at this time. However, it could happen in the future. It woud be easy, for example, to synchronously measure the sweep with the HAPI, and play it on the NADAC. They would be perfectly synchronous as long as they are attached to the same switch.

The idea here is flexibility. It's impossible for me to predict all the possible combinations one could have with multiple DACs, ADCs etc. The other thing to consider is the possibility to have a MCH system with "money" DACs on the R/L channels and lesser DACs on less critical channels, like subs. I know Dom talked about Merging producing a lower cost NADAC which has only ethernet input. It's a great way to future proof a system. If somebody bought a 2Ch NADAC today and a year from now wanted to add a pair of subs to make their system a true 4CH system with proper crossovers/delay, all they do is buy another AES67 DAC. Since Ravenna and AES67 is an open standard and all cross-compatible, it would be simple to just buy another AES67 compliant 2CH DAC. All the DACs would be perfectly synchronous without any crazy word clock cables or anything like that.

This is already happening with classical recordings. I know my Dallas Symphony Orchestra has several mics on a couple of HAPIs and a HORUS in the control room. The ethernet means really short analog cable runs with perfect synchronization between all the different devices.

Michael.

ted_b · January 10, 2015

Ok, met with Dom today and the message is now a bit clearer. the Nadac will indeed be marketed as thre different dacs, as above (2, 8, 16). Although thye are basically the same dac, Chris and I would get two different dacs, the stereo one having slightly better dynamic range, etc with 8 dacs in a parallelized 2 channel config, and me with each dac being a channel. They will not be field comfigurable as i first thought. My bad.

The Hapi will not have a 2 channel card. Merging will later have other boxes that will be 2 channel (and then likely added on to) but not in the current Hapi.

hifial · January 10, 2015

Ok, met with Dom today and the message is now a bit clearer. the Nadac will indeed be marketed as thre different dacs, as above (2, 8, 16). Although thye are basically the same dac, Chris and I would get two different dacs, the stereo one having slightly better dynamic range, etc with 8 dacs in a parallelized 2 channel config, and me with each dac being a channel. They will not be field comfigurable as i first thought. My bad.

The Hapi will not have a 2 channel card. Merging will later have other boxes that will be 2 channel (and then likely added on to) but not in the current Hapi.

Ted, thanks. By the way, did you confirm pricing for the 2 channel and 8 channel versions?

bmoura · January 10, 2015

Ted, thanks. By the way, did you confirm pricing for the 2 channel and 8 channel versions?

Audiostream reports that the 2 Channel NADAC will sell for "around $7,500". No mention of the price on the 8 Channel version. Or the 16 Channel version.

Merging Technologies NADAC | AudioStream

bmoura · January 10, 2015

I rely on DSP filters for playback. To create the best possible filters, it's very important to use really good test gear. For my purposes, the HAPI is a better fit. So I don't plan on buying an NADAC at this time. However, it could happen in the future. It woud be easy, for example, to synchronously measure the sweep with the HAPI, and play it on the NADAC. They would be perfectly synchronous as long as they are attached to the same switch.

The idea here is flexibility. It's impossible for me to predict all the possible combinations one could have with multiple DACs, ADCs etc. The other thing to consider is the possibility to have a MCH system with "money" DACs on the R/L channels and lesser DACs on less critical channels, like subs. I know Dom talked about Merging producing a lower cost NADAC which has only ethernet input. It's a great way to future proof a system. If somebody bought a 2Ch NADAC today and a year from now wanted to add a pair of subs to make their system a true 4CH system with proper crossovers/delay, all they do is buy another AES67 DAC. Since Ravenna and AES67 is an open standard and all cross-compatible, it would be simple to just buy another AES67 compliant 2CH DAC. All the DACs would be perfectly synchronous without any crazy word clock cables or anything like that.

Not sure I'd want "lesser DACs" on some channels. Best to have the same speakers and DACs on every channel to accurately reproduce Multichannel recordings.

As for HAPI vs. NADAC, the NADAC seems very high priced vs. HAPI. That may steer more folks towards HAPI. Who knows, that could be part of their plan!

matthias · January 10, 2015

The Hapi will not have a 2 channel card. Merging will later have other boxes that will be 2 channel (and then likely added on to) but not in the current Hapi.

Ted,

thank you very much for asking.

Matt

Miska · January 10, 2015

All the DACs would be perfectly synchronous without any crazy word clock cables or anything like that.

There's no such thing with distributed clocks. Word clock doesn't provide as good synchronization as asynchronous clocking either, because it runs at word clock speeds. Especially with chips like Sabre you need up to 100 MHz very low jitter master clock. With discrete DSD DACs like DSC1 you only need DSD bitrate clock, so for DSD256 12.2 MHz would be enough.

I'm curious to see jitter plots for these multi-DAC setups, and I'm not expecting very good results.

Miska · January 10, 2015

...to be more precise, I expect jitter performance around similar figures as HDMI without the asynchronous feedback option...

MikeJazz · January 12, 2015

...to be more precise, I expect jitter performance around similar figures as HDMI without the asynchronous feedback option...

This is why I suspect this is more geared towards professional applications, big rooms, where more jitter is not critical.

Some vendors already distribute signal to the speakers via ethernet, such as Linn with Exakt products...but they distribute the digital signal and there are dacs located at each driver and dedicated amp..

I was excited by this technology by the way, but the few auditions I had left me cool...

Hiro · January 12, 2015

Audiostream reports that the 2 Channel NADAC will sell for "around $7,500". No mention of the price on the 8 Channel version. Or the 16 Channel version.

Merging Technologies NADAC | AudioStream

So, their DAC for home use will sell for more than their converter made for professional studio environments ?

dallasjustice · January 12, 2015

...to be more precise, I expect jitter performance around similar figures as HDMI without the asynchronous feedback option...

I am talking about the advantages that AES67 and PTPv2 offers over the current way ethernet is being used in this niche industry.

In the context of AES67, you are talking about multiple DACs all sync'd together over IP in large distributed systems. Even if timing is off one nanosecond in the sync, it won't be audible and it's not jitter in the way we typically define it in 2CH playback. The sync timing is different from the jitter in each DAC's conversion. There's nothing about how ethernet is used in this context which causes jitter in the playback of each device. The data packets are checked on both ends, so the data each DAC receives is exactly the same as the data the server sends. The timing of that data is irrelevant to the conversion inside each device.

Another major advantage AES67 offers is that it can support MCH setups much better than DLNA. I'm not aware of any high end audio quality DLNA renderer with an ASIO driver or anything more than 2CH.

Miska · January 12, 2015

In the context of AES67, you are talking about multiple DACs all sync'd together over IP in large distributed systems. Even if timing is off one nanosecond in the sync, it won't be audible and it's not jitter in the way we typically define it in 2CH playback. The sync timing is different from the jitter in each DAC's conversion. There's nothing about how ethernet is used in this context which causes jitter in the playback of each device. The data packets are checked on both ends, so the data each DAC receives is exactly the same as the data the server sends. The timing of that data is irrelevant to the conversion inside each device.

You need to somehow adjust the timing on each of the DACs based on the time protocol. If you don't do anything with the timing data it is pointless to have it in the first place...

Problem becomes precisely when you need to adjust something. In asynchronously clocked system where DAC is timing master, there's never need to adjust anything. However, naturally you cannot have more than one timing master at the same time and that's the issue.

Two alternatives are that you pull PLL frequency based on the microsecond-accuracy PTPv2 timing data - which causes jitter by itself. Or you adjust ASRC ratio based on the PTPv2 timing data - which embeds the jitter into sample data itself.

So yes, the data is the same, but what does the DAC do when it sees that it is falling one sample behind or running one sample ahead? When you have multiple clocks you will never have two clocks running exactly at the same speed. If you have more than two, you have a system where you have many clocks each running at slightly different speed. Eventually they'll be one or more samples off, especially when sample rate is 192k or something like 12.2 MHz.

With typical clock frequency, you slip by sample in 128 seconds at 192 kHz sampling rate and 0.2 ppm OCXO. At DSD256 that'll happen in just two seconds.

Another major advantage AES67 offers is that it can support MCH setups much better than DLNA. I'm not aware of any high end audio quality DLNA renderer with an ASIO driver or anything more than 2CH.

I wouldn't compare AES67 and UPnP because they are conceptually completely different. AES67 is about streaming bare audio while UPnP is about playing media from a server and controlling the playback.

I have UPnP renderer capable of all the normal multichannel media.

dallasjustice · January 12, 2015

You need to somehow adjust the timing on each of the DACs based on the time protocol.

That's the way PTPv2 works. It is constantly checking all devices on the network against the reference master. PTPv2 is able to even take into consideration the travel time down the network and through the switch. This way, there's no chance of a clock drift in the way you speculate.

This is a technology that's been used already in some of the finest recordings we have. For example, I know 2L and Channel Classics record with the same technology over distances MUCH further apart than any consumer playback scenario could contemplate. Those firms produce some of the finest DSD and PCM recordings available.

matthias · January 12, 2015

So, their DAC for home use will sell for more than their converter made for professional studio environments ?

Yes, the Hapi with the Premium-DSD-DAC card costs in Europe 4000 Euro incl. VAT.

Miska · January 12, 2015

With typical clock frequency, you slip by sample in 128 seconds at 192 kHz sampling rate and 0.2 ppm OCXO. At DSD256 that'll happen in just two seconds.

I probably shouldn't be calculating and writing these in fever... At least those numbers are wrong.

New take in a different way.

Crystek CCHD-957 low-jitter oscillator is 20 ppm and thus 0.002%. 0.002% of 192000 samples per second is 3.84 samples so it goes off by one sample in 0.26 seconds. OCXO's are usually around 0.2 ppm which is 0.00002%, where that's 0.0384 samples so going off by one sample takes 26 seconds.

Hope this is correct now...

Miska · January 12, 2015

That's the way PTPv2 works. It is constantly checking all devices on the network against the reference master. PTPv2 is able to even take into consideration the travel time down the network and through the switch. This way, there's no chance of a clock drift in the way you speculate.

Yes, it's like NTP used to adjust computer clocks, which can also take into account those delays. I've written NTP server and client myself in the past. The problem is when you do something with the information! To prevent clock drift you need to adjust the clock depending on feedback, this adjustment creates jitter. There is no way to check/adjust something and not do it at the same time! Best accuracy figures for PTPv2 implementations I've seen have been in nanoseconds. This is not enough for achieving good jitter figures below 10 picoseconds.

If you look at Figure 2 here:

Clock Quality

all the variation in the plot is called jitter. It is not a straight line.

Plus if you want proper performance from PTPv2, you need a special network card...

This is a technology that's been used already in some of the finest recordings we have. For example, I know 2L and Channel Classics record with the same technology over distances MUCH further apart than any consumer playback scenario could contemplate. Those firms produce some of the finest DSD and PCM recordings available.

Unfortunately lot of professional recording gear has much worse jitter figures than audiophile gear.

I know 2L uses DAD AX24 which doesn't use any network audio, but uses MADI instead (optical cables). And Channel Classics uses Grimm AD-1 which is not networked either but uses SDIF.

This clocking is not an issue if you have single converter which is also the Grand Master Clock at the same time, but it becomes issue if you have more than one converter because you cannot have more than one such clock.

AES67 has been designed primarily for broadcast use (radio/TV) and not for audiophile stuff. I've checked through the contents and I'm less than enthusiastic about it.

Miska · January 12, 2015

And I would also assume that many people using Hapi or Horus are using just single unit configured as clock master? In this case, the PTPv2 network time synchronization shouldn't be necessary at all, or at most used to slave the computer to the converter's clock.

PeterSt · January 13, 2015

I will try to rephrase what Miska "in fever" already all said, but I think it needs some emphasis here and there to understand it;

First of all we talk about skew and not about jitter (this is what Dallas tried to say ). So channel to channel skew and it is present with 2ch also. Do we hear that ? I say yes, because with my DAC I can choose between something like 0.001us (1ns) and something like 2us. I forgot the timing data, but the difference in (phase) degrees is 0.00 (no more digits available in my analyzer) and 0.02 degrees. Watch out, at 1000Hz because phase (timing) data depends on frequency. It expresses (vastly) in the L/R bass separation. So again, this is skew and not jitter.

Same with the multichannel long-distance several DACs ?

No. So assumed each channel runs on its own clock then at first there's skew again. "At first" because this needs to be degraded to jitter and this is because the channels require adjustment now and then. This is the PLL thing Miska talked about. The jitter now explicitly occurs in those channels which needs adjustment, which will be all but one (the master). Depending on the drift this can be audible and it should be a flanger-like thing. Look back at Miska's "out of fever" data for how fast it will happen but with the notice that the change is minor when the frequency of observing the necessary adjustment is high enough (but is often as low as 1Hz hence 1 time per second for other good reasons). So when fast enough to cover for one sample difference, we can calculate the frequency difference (change) occurring say that once per second (now I am in fever). And notice that mentioned flanger-like now actually is vibrato-like.

Remember, I was talking about listening to one of such channels only, and how that will be subject to low frequency jitter changes and which can be audible. Now :

Back to my perceived bass difference (L/R), such a thing will be happening all over, but worse. So it is not only the skew between the channels, but also the changing skew (at low jitter rate - the once per second correction).

In other words : If the skew is there in the first place (virtually not there in my DAC and which is what I am used to) then sound will already be poor. But if that also changes continuously I can expect it to be very very poor and I think I would go mad. With 2 channels (one of them always changing) I would go mad, and I am not sure whether 21 (out of 22) doing that will imply such a mess that nothing is noticeable any more or that all keeps on buzzing around which even might cause oscillation in the room.

Peter

Miska · January 13, 2015

In short form it works like this, from slave clocked DAC's perspective:

- OK, looks like I'm running a little bit too fast and getting ahead, better slow down my clock

- Damn, it was almost right, but I slowed down the clock a bit too much, so I'll make a tiny bit faster

- Almost right, now just a notch slower

- It is really hard to keep this in perfect sync, because the resolution is about the same as my clock cycle length so it could be entire cycle off

- I would really need 0.17 ps accuracy to achieve DXD signal resolution

Same adjustment can also be done using ASRC, like TI SRC4193, AD1896, CS8421 or ESS Sabre's built-in. Only difference is that instead of adjusting clock frequency, the rate conversion ratio is adjusted based on perceived frequency difference between two clocks (remote and local).

miguelito · January 14, 2015

What makes EMM Labs different is that they don't use off-the-shelf converter chips. AFAIK, Merging and Prism have so far been using such.

The MDAC "chip" in EmmLabs' DACs is actually a discrete component DAC. I don't necessarily equate effort and expense with results, but these guys clearly know what they are doing.

dallasjustice · January 14, 2015

The MDAC "chip" in EmmLabs' DACs is actually a discrete component DAC. I don't necessarily equate effort and expense with results, but these guys clearly know what they are doing.

I also don't equate parts and effort with "quality." I've owned both discrete resistor DACs and chip DACs. IME, there's no correlation with sound quality either way.

Miska · January 14, 2015

The MDAC "chip" in EmmLabs' DACs is actually a discrete component DAC. I don't necessarily equate effort and expense with results, but these guys clearly know what they are doing.

I thought I said it like that. In a way similar discrete converter like Playback Designs, dCS and my DSC1 too...

But I was wondering if the Merging is discrete...

Miska · January 14, 2015

I also don't equate parts and effort with "quality." I've owned both discrete resistor DACs and chip DACs. IME, there's no correlation with sound quality either way.

Yeah, but at least it can justify some of the price... I have hard time understanding $10k+ DACs that use COTS DAC chips.

barrows · January 14, 2015

Yeah, but at least it can justify some of the price... I have hard time understanding $10k+ DACs that use COTS DAC chips.

Yeah, agreed... There is a lot less engineering cost associated with using an OTS DAC chip Vs. implementing a self designed conversion solution. Does Merging write their own filters/OSF?

wappinghigh · January 15, 2015

Ha, it's the new DAC to play with the mystical Emotion playback software that we have been waiting for years to surface.....?

hahaha Exactly.

New DAC from Merging Technologies for Home Audio Market

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Create an account or sign in to comment

Create an account

Sign in