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

[Miska]

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.

 

[Miska]

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:

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

 

[Miska]

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.

[Miska]

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.

 

[Miska]

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

 

[Miska]

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.

 

[Miska]

4 hours ago, PeterSt said:

I don't see you talking about how to get in that data over Ethernet; it needs to be "pulled".

 

Peter, there are many different ways to transfer audio over Ethernet. These can be very different, as we can see from the ones currently on market. Different kind of approaches for different purposes.

 

[Miska]

Things like AES67/Dante/RAVENNA and AVB are distributing clock on the network. Because their concept is that network has many DACs and/or ADCs.

 

Like RAVENNA may be used on a stadium rock concert where each speaker block around the stadium is connected to the network, with their own DAC, but part of the same RAVENNA network.

 

While AVB is used for example throughout automotive industry. Where network is used to distribute audio and video between the IVI system and front and back seats of your car. You may have multiple speakers, headphone sockets and video displays in the backseat. And subwoofer in the trunk.

 

Then you have various things in your home network. Like Apple's AirPlay where each connected device generates their clock from the incoming data packets using PLL. This allows multiple networked speakers in a multi-room configuration.

 

Etc, etc...