I’m not sure if I am getting this. I thought this is old news?
Over 200 pages already in that thread.
I can’t find anything on the Zman there.
That’s just like sharing a link to a thread about electric cars that don’t mention a word about a Tesla, then saying a thread dedicated to Tesla’s is the same thing.
Since you are selling a Tesla, then you should have mentioned the word Tesla in the subject of your thread. It just say electric cars.
The word you’re looking for is Ravenna. Just one of the several AOIP protocols mentioned in that general AOIP thread. Before the Zman, the Merging NADAC was the only consumer audio product using it.
It’s hard for me to surmise from all the hype exactly what this little board does. What goes in and what comes out? How is this revolutionary? Networked DACs have been around for a while, including networked DACs that are Roon Ready.
The Melco N1 uses Ravenna so would this work with the NADAC?
Yes. This is why they are pictured together. Also will with with any Zman equipped product. Dozens in the works.
Hi Mike,
Would this able roon to work in this configuration
Roon ROCK will support Ravenna. That’s what I would use. Unless the NUC case isn’t fancy enough for you.
Unfortunately AES67/Ravenna distributes clock itself over ethernet and then it is reconstructed at the DAC side using DPLL. Because there can be only one master clock. So it is not jitter-immune in that sense. Unlike for example NAA that doesn’t distribute any clock over network, but that poses limitation that there can be only one DAC with a local master clock.
But I can play 8 channel DSD256 to my exaSound e28 over NAA connection without problem. But AES67 and NAA are completely different kind of protocols, practically nothing in common.
1 Like
Each unit still is clocked by its own master. You’re confusing the master with the grandmaster. The PLL is only for the IEEE1588v2 clock sync feature. And it doesn’t add jitter. It only syncs up the clock to clock “skew”. Besides you only use that feature when syncing multiple boards together. For any single box application like RAAT or NAA is designed for, this feature isn’t utilized.
Yes, and no I’m not confusing. Any adjustment for skew adjusts either clock or data and thus is not jitter immune. You know, you cannot adjust without adjusting, and adjustment changes spectral properties of the combination… 
Some systems do it with DPLL, some systems do it with ASRC (ESS Sabre chips), or both (ESS Sabre with S/PDIF inputs).
And for those cases, AES67 doesn’t offer any advantage, just huge amount of extra complexity compared to NAA. I don’t know enough about RAAT to say anything about it.
What you said was you can only use a single master clock with Ravenna. Which is false. Unless you have tested these boards with something like the Keysight 5052B like Merging has, you’re not in a position to claim the IEEE1588v2 feature causes jitter.
You mean there’s ultra high end boards on the market with NAA built in? If so how do I use them with Netflix? Every commercial implementation I’ve ever seen involves an old fashioned streamer like my Superstream, and USB.
Yes, it is called the grand master. In any synchronized audio environment there can be only one master clock, all other clocks are slaved to it.
WTF is “ultra high end”? Probably something only very few people have which is not what I’m interested in.
Not that I would have slightest interest on Netflix or any video stuff in first place. HQPlayer Embedded can use pretty much any stream from anywhere. At the moment I’m using it with Chromecast Audio through optical S/PDIF and from Mac Mini through AES/EBU. Anything that goes out through CoreAudio on Mac can go through it.
That’s not how the system works. With Ravenna each endpoint has its own master. It’s the “Grandmaster” that syncs each clock. Much different from a master clock in a traditional pro system which uses a external master, and syncs each DAC via the word clock input. In that situation, yes the master is what clocks each DAC.
However this is only a concern in multi-endpoint applications.
Your particular interests aren’t what this board is targeted at. Some folks like the flexibility of being able to send audio from any application that can run on Linux, OSX and Windows. YouTube videos, Netflix, Bluray’s etc. They also like to do this without any intermediate boxes in the picture. Just a simple NUC, switch, and Ethernet cables. With the Zman connected to the same network as the server, it populates in the sound devices just the same as if it was a sound card installed in the computer.
Ultra high end certainly doesn’t include the I2S outputs on a Raspberry Pi, Chromecast SPDIF etc.
Blaah, it uses standard protocols like PTPv2:
Plus UDP/RTP etc for the audio data transfer with all the related challenges. And it used RTSP too? I still get shivers from the old days when I had to use those protocols (we did VoIP and video calls over internet in Nokia devices 10+ years ago).
Ultra high end includes crap quality like Netflix and YouTube? 
Not that I would really care. Chromecast Audio works well for me because both Tidal and Spotify can work through it straight from iOS and Android devices and it costs 30€. S/PDIF is not a problem because the clock from there is not really used for anything in my system. Yeah, good old CD-spinners work just fine too. Output is 12.3 MHz DSD256 at the moment.
I’m not really clear on why you have a problem with this technology? After all it can still be used with HQP. In fact with this board HQP can finally be experienced in its full glory with Acourate convolution running a pair of active 3/4way speakers using the HQP convolution engine for xovers/room correction on native DSD. The active speakers could have pure 1 bit DSD DAC’s for each channel. No other board can allow a system like this.
I don’t have a problem with it. It is just yet another IP based audio transport. It is designed for low-latency networked multi-converter infrastructure, like providing audio for a stadium rock concert. And for large scale studio and broadcast installations. It is probably very good for what it has been designed for. I’m almost 100% sure that the AES67 requirements didn’t list audiophile things like “provide timing jitter in sub-picosecond range on all networked converters”.
Some other protocols like RAAT and NAA are designed against different requirement set with different strengths and limitations. At least it is just about as different as protocol can be, compared to NAA.
So what I personally want is to keep feet on the ground and see real implementations in action. When I can get a Ravenna DAC for 1 - 2 k€, I may buy one and measure it. Until then, it is just another curiosity as technology for me. Dante boxes (practically based on same AES67, but different variant) are already available in that price range from Focusrite.
In a single DAC scenario, like using one NADAC on the network, the clock synchronization shouldn’t be a disturbance source, because the DAC’s built-in clock should be the grand master clock and it doesn’t need to synchronize to anything.
But I would be curious to see how it compares in synchronized multi-DAC scenario for example to a regular USB into Holo Spring DAC.
I’m sure people would be more than happy to see results posted here! 
So was USB originally designed for high end audio only? At least Ravenna was designed solely for Audio, and Merging took it an extra level to make the Zman specifically for the high end consumer audio market. They now have 7 years experience fine tuning the protocol for high end audio. And the Zman is the end result of the sum of these 7 years of experience and millions of $ of investment capital. Let alone 1000’s of proven products in the field.