Jump to content
IGNORED

We need a new standard in transferring digital signals between audio equipment.


R1200CL

Recommended Posts

Those I2S over HDMI cable implementations just have one major flaw. Clock is at the source side, not at the DAC side like should be.

 

And the connection is synchronous...

 

I personally prefer network connection where DAC has the master clock as it should and data transfer is asynchronous. Doing it over TCP/IP stack allows various different physical interfaces without having impact on the audio transfer functionality. Also works over WiFi. And even internet in case you want to have server and endpoint on opposite sides of the globe.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
8 hours ago, davide256 said:

I don't want to see IP application complexity /overhead dragging down a virtual point to point connection, making DAC designers step outside their black box. For the DAC designer this should be a firmware chip managing an Ethernet port that behaves to them with data flow logic similar to Toslink/coax/USB and where the distant end uses a device driver designed for WAN connection handshake and data flow to their DAC Ethernet chip.

 

Think of a  network printer... you can print anywhere if the IP address is accessible and you have installed the device driver for the printer.

 

Network printers using IPP/CUPS have full TCP/IP stack (using discovery similar to NAA and RAVENNA, using Avahi/Bonjour/ZeroConf) plus PostScript language processor. So certainly not "a chip doing all the magic". It is lot of software.

 

But for example NAA can certainly run on a small hardware module, this is smallest currently available one I'm using:

aria_new.jpg

And this can be connected directly to the DAC. But many hardware manufacturers don't like it because it is too expensive (28€/piece in small quantities).

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
7 minutes ago, Miska said:

 

Network printers using IPP/CUPS have full TCP/IP stack (using discovery similar to NAA and RAVENNA, using Avahi/Bonjour/ZeroConf) plus PostScript language processor. So certainly not "a chip doing all the magic". It is lot of software.

 

But for example NAA can certainly run on a small hardware module, this is smallest currently available one I'm using:

aria_new.jpg

And this can be connected directly to the DAC. But many hardware manufacturers don't like it because it is too expensive (28€/piece in small quantities).

 

Hello Jussy,

Where to buy?

Quote

Ethernet::4x Bonn Silent Angel 8P, Afterdark Emperor Doublr  Crown Masterclock and Cybershaft 75 Ohm,Mini Circuits convertor,Uptone EtherRegen with 75Ohm. SOTM Cat CAT 7.

Audio: Auralic Vega G2.1, Cambridge Edge W, Kef Reference 3 speakers.  
Power: Farad super 3 (2x) , Keces P8 ( 2 Uptone LPS1.2 ) Afterdark 5V: 

Cables:Meicord Opal, SOTM Cat7 with filtering, Ghent Audio DC , Farad Level 2, Sharkwire speaker cable

Link to comment
4 hours ago, Miska said:

But for example NAA can certainly run on a small hardware module, this is smallest currently available one I'm using:


So any Rendu will have something like this inside ?

And so must a Pii have on a Hat ?

 

Can NAA be used on both Ethernet and USB ?

Link to comment
6 minutes ago, R1200CL said:

So any Rendu will have something like this inside ?

 

Rendu has something similar but more powerful inside. But Rendu is primarily for USB output, although it could have something else too.

 

7 minutes ago, R1200CL said:

And so must a Pii have on a Hat ?

 

Yeah, I have for example Pi4 + HifiBerry DAC2 HD. This has even enough power to run full HQPlayer Embedded with PCM upsampling.

 

8 minutes ago, R1200CL said:

Can NAA be used on both Ethernet and USB ?

 

For NAA, any suitable audio output works, preferably it would be direct I2S connection to the DAC itself, inside the same box. But most of the time it is used with USB connection though, because not many DACs have a NAA inside.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

A (typical) DAC chip is going to need I2S and great clocks nearby. Plus very clean power.

 

A (typical / ideal) network player / digital transport / streamer needs an Ethernet input (maybe WiFi) and great clocks. Plus very clean power.

 

We make a streamer that outputs I2S on an HDMI cable. We make a DAC that accepts it. The best sound I've gotten from the pair is when the player lives in the DAC chassis, and instead of the required 3.3V TTL I2S > LVDS (over an HDMI cable) > 3.3V TTL I2S, the player feeds the DAC board. (There's galvanic isolation in play, of course)

 

A "purist" might scream that Ethernet = PC, and that no PC parts are allowed in an Audiophile Grade DAC. (To that, I'd suggest that USB = PC... and camera, and printer, and a ton of other garbage, and USB is almost always in there... but I digress)

 

You can mitigate the PC issues with multiple power supplies / regulators and proper galvanic isolation.

 

The gain is 2 fewer signal translations (to LVDS for the HDMI cable and back to TTL for the DAC chip), and a clock "right next to" the DAC chip.

 

What we have then is a DAC with an internal streamer... a Network DAC.

 

What am I missing?

Listening Room: Musica Pristina A Cappella III (R&D model) Streamer > i2s (HDMI LVDS) > Musica Pristina Virtuoso DAC > Quad II Eighty Amps > Quad ESL 2905 Speakers > Very Happy Ears
DIY Owens Corning Room Treatment
ManufacturerMusica Pristina

Link to comment
7 hours ago, Miska said:

 

Network printers using IPP/CUPS have full TCP/IP stack (using discovery similar to NAA and RAVENNA, using Avahi/Bonjour/ZeroConf) plus PostScript language processor. So certainly not "a chip doing all the magic". It is lot of software.

 

But for example NAA can certainly run on a small hardware module, this is smallest currently available one I'm using:

aria_new.jpg

And this can be connected directly to the DAC. But many hardware manufacturers don't like it because it is too expensive (28€/piece in small quantities).

 

Theres a lot going on in IP protocol stack and streamer GUI that doesn't need to be in a DAC interface. As long is it buffers correctly to avoid signal interruption

and timing integrity loss I'm good with whatever standard could be evolved to work with an IP server audio application.

Regards,

Dave

 

Audio system

Link to comment
9 hours ago, kdubious said:

A (typical) DAC chip is going to need I2S and great clocks nearby. Plus very clean power.

 

A (typical / ideal) network player / digital transport / streamer needs an Ethernet input (maybe WiFi) and great clocks. Plus very clean power.

 

We make a streamer that outputs I2S on an HDMI cable. We make a DAC that accepts it. The best sound I've gotten from the pair is when the player lives in the DAC chassis, and instead of the required 3.3V TTL I2S > LVDS (over an HDMI cable) > 3.3V TTL I2S, the player feeds the DAC board. (There's galvanic isolation in play, of course)

 

A "purist" might scream that Ethernet = PC, and that no PC parts are allowed in an Audiophile Grade DAC. (To that, I'd suggest that USB = PC... and camera, and printer, and a ton of other garbage, and USB is almost always in there... but I digress)

 

You can mitigate the PC issues with multiple power supplies / regulators and proper galvanic isolation.

 

The gain is 2 fewer signal translations (to LVDS for the HDMI cable and back to TTL for the DAC chip), and a clock "right next to" the DAC chip.

 

What we have then is a DAC with an internal streamer... a Network DAC.

 

What am I missing?

All in ones may be the way to go. When will yours be available? 

Link to comment
16 hours ago, davide256 said:

Theres a lot going on in IP protocol stack and streamer GUI that doesn't need to be in a DAC interface.

 

Can you elaborate what are you talking about?

 

16 hours ago, davide256 said:

As long is it buffers correctly to avoid signal interruption and timing integrity loss I'm good with whatever standard could be evolved to work with an IP server audio application.

 

Building things on top of IP stack is closest to being standard and not reinventing the wheel. That is what most of the protocols do, like AES67/RAVENNA/Dante (all based on same stuff), NAA, RAAT, UPnP, AirPlay, Chromecast, AVB (the IP variant).

 

But there are big differences in implementation. For example NAA and UPnP don't transfer any timing or clock data, while for example AES67/RAVENNA/Dante and AVB does. Thus for example NAA and UPnP doesn't need any clock recovery either. While for example AES67/RAVENNA/Dante, AirPlay and AVB do, but for example with RAVENNA it depends also on your configuration who is selected to be the master clock.

 

Different protocols are intended for different use cases so they have differing feature sets and trade-offs. I don't think there is much point in trying to have just one kind of interface or transfer method, because it will never be perfect for all the different use cases.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
16 hours ago, kdubious said:

A (typical) DAC chip is going to need I2S and great clocks nearby. Plus very clean power.

 

A (typical / ideal) network player / digital transport / streamer needs an Ethernet input (maybe WiFi) and great clocks. Plus very clean power.

 

No, the ideal network endpoint doesn't need great clocks. DAC (chip) does need, nearby, closer the better.

 

16 hours ago, kdubious said:

We make a streamer that outputs I2S on an HDMI cable. We make a DAC that accepts it.

 

No, this is where it goes horribly wrong. Because the current "standard" of I2S over HDMI is having clocks at the wrong side (source). While the clocks should be going opposite direction than the data. Clock should be coming from DAC to the source.

 

16 hours ago, kdubious said:

A "purist" might scream that Ethernet = PC

 

No, ethernet and PC doesn't have anything to do with each other. Computer maybe, but not all computers are PCs.

 

16 hours ago, kdubious said:

What we have then is a DAC with an internal streamer... a Network DAC.

 

Yes, that's the point. :)

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

@Rexp We had one based on the Burr Brown PCM1794. But 24/192 is a little behind the times in the mind of most people. I can't decide whether to build on the ESS SABRE DAC chip (which I typically do not love the sound of) or to create a ladder DAC. Then there's DSD and MQA to contend with, too.

Anyhow, it would be 6+ months before Musica Pristina has an "Ethernet DAC" or a "Network DAC" or a "Streaming DAC."

Listening Room: Musica Pristina A Cappella III (R&D model) Streamer > i2s (HDMI LVDS) > Musica Pristina Virtuoso DAC > Quad II Eighty Amps > Quad ESL 2905 Speakers > Very Happy Ears
DIY Owens Corning Room Treatment
ManufacturerMusica Pristina

Link to comment
1 hour ago, kdubious said:

@Rexp We had one based on the Burr Brown PCM1794.

 

Take the PCM1704U-K then (24/768).

😜

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
5 hours ago, Miska said:

 

Can you elaborate what are you talking about?

 

 

Building things on top of IP stack is closest to being standard and not reinventing the wheel. That is what most of the protocols do, like AES67/RAVENNA/Dante (all based on same stuff), NAA, RAAT, UPnP, AirPlay, Chromecast, AVB (the IP variant).

 

But there are big differences in implementation. For example NAA and UPnP don't transfer any timing or clock data, while for example AES67/RAVENNA/Dante and AVB does. Thus for example NAA and UPnP doesn't need any clock recovery either. While for example AES67/RAVENNA/Dante, AirPlay and AVB do, but for example with RAVENNA it depends also on your configuration who is selected to be the master clock.

 

Different protocols are intended for different use cases so they have differing feature sets and trade-offs. I don't think there is much point in trying to have just one kind of interface or transfer method, because it will never be perfect for all the different use cases.

 

Part of my prior day job used to be parsing feature enhancement requests from fortune 500 companies to add global router support for things in RFC's that weren't

enabled... a balancing job of what's the benefit vs whats the hit to network performance/cost of hardware upgrades.  So yes, theres a lot in the IP RFC's, some of

which has nothing to do with audio file transfers and some of it is unfriendly to applications that need real time performance.

 

You don't use/enable timing data at the IP protocol level. That's a DTE function, part of your data format/protocol before and after removal of the IP layer.  How

clocking worked would have to be part of the device driver coding at the server and the data handling logic of the DAC Ethernet boards firmware. I see no reason

why a standard couldn't be made that would accommodate any clocking scheme that was part of the protocol  handshake in the data packet information. DAC designers

would have to option/test such a board for their implementation and petition to add to the standard any different protocol handshake that wasn't currently included

Regards,

Dave

 

Audio system

Link to comment
1 hour ago, davide256 said:

How clocking worked would have to be part of the device driver coding at the server and the data handling logic of the DAC Ethernet boards firmware.

 

It is already there... In Linux kernel, I'm pretty familiar with that code.

 

1 hour ago, davide256 said:

I see no reason why a standard couldn't be made that would accommodate any clocking scheme that was part of the protocol  handshake in the data packet information

 

That is specifically something that is not part of my protocol, very much on purpose. It is unnecessary and it doesn't belong there. And not in UPnP for example either.

 

1 hour ago, davide256 said:

DAC designers would have to option/test such a board for their implementation and petition to add to the standard any different protocol handshake that wasn't currently included

 

That is usually something you'd get from the module vendor. But point of standards is that you don't keep changing them all the time. Especially you don't break the existing implementations.

 

For example my NAA protocol has changed from v2 to v3 and to v4. But both sides are interoperable with previous versions. And well, nobody else even needs to know what has changed inside.

 

 

Quote

to add global router support for things in RFC's that weren't enabled

 

RFCs are separate standards or extensions to already existing standards, on purpose. You don't change the existing ones. You create new ones. This retains the backwards compatibility.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
6 minutes ago, Superdad said:

I seem to recall that you (at Phasure) own nearly all the world's remaining PCM1704 stock.

 

Haha, Alex, true. At least back then I bought everything I could. But at some stage I may not know where to go with it all.

That's why this advertisement. 😬

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
31 minutes ago, PeterSt said:

But at some stage I may not know where to go with it all.

 

Hey Peter, make a 6- to 8-channel NOS1... and playback software with digital crossover functionality.

 

Easy 😉.

 

Mani.

Main: SOtM sMS-200 -> Okto dac8PRO -> 6x Neurochrome 286 mono amps -> Tune Audio Anima horns + 2x Rotel RB-1590 amps -> 4 subs

Home Office: SOtM sMS-200 -> MOTU UltraLite-mk5 -> 6x Neurochrome 286 mono amps -> Impulse H2 speakers

Vinyl: Technics SP10 / London (Decca) Reference -> Trafomatic Luna -> RME ADI-2 Pro

Link to comment

@miska 

Quote

No, this is where it goes horribly wrong.

"Horrible"? Should I assume you've never heard a USB DAC?

Listening Room: Musica Pristina A Cappella III (R&D model) Streamer > i2s (HDMI LVDS) > Musica Pristina Virtuoso DAC > Quad II Eighty Amps > Quad ESL 2905 Speakers > Very Happy Ears
DIY Owens Corning Room Treatment
ManufacturerMusica Pristina

Link to comment

@Miska I feel like I'm missing something that you are trying to say. Can you point me to some details on NAA?

Listening Room: Musica Pristina A Cappella III (R&D model) Streamer > i2s (HDMI LVDS) > Musica Pristina Virtuoso DAC > Quad II Eighty Amps > Quad ESL 2905 Speakers > Very Happy Ears
DIY Owens Corning Room Treatment
ManufacturerMusica Pristina

Link to comment
17 minutes ago, kdubious said:

Seven hundred sixty eight what from that chip?

 

Sure. For more than 10 years by now and always on (24/7). And 10+ years more, but nobody knew.

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
5 minutes ago, PeterSt said:

 

Sure. For more than 10 years by now and always on (24/7). And 10+ years more, but nobody knew.

And now you have chips to sell? Or DAC boards?

Listening Room: Musica Pristina A Cappella III (R&D model) Streamer > i2s (HDMI LVDS) > Musica Pristina Virtuoso DAC > Quad II Eighty Amps > Quad ESL 2905 Speakers > Very Happy Ears
DIY Owens Corning Room Treatment
ManufacturerMusica Pristina

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...