Diretta audio protocol

[The Computer Audiophile]

Let's keep this thread on topic. I think this is definitely a worthwhile thing to look at. UPnP / DLNA has its issues, even if you don't consider sound quality. Options are always good. I applaud people for coming up with new methods to transport audio.

 

Would love to know more about this. 

[The Computer Audiophile]

6 hours ago, R1200CL said:

They prefer FB.

That's like preferring Walmart over a boutique HiFi shop. 🤮

[Patatorz]

20 hours ago, R1200CL said:

https://support.diretta.link/doku.php?id=usb-dac
 

However the Diretta site seems to mix several products, as well as ways of transferring data. One sketch indicates a master clock in a separate line as well, but it seems it has been removed the last hour.

 

The mix of USB and ethernet, and lack of UPnP, is confusing for me.

What about zones ? Is it supported ? 
 

I have requested Diretta to participate in this tread. If they doesn’t show up, it’s maybe just another scam equal to MQA. 
 

Very few it seems 😀

But I would like to understand limitations and requirements.

YouTube DirettaSviluppo

This explanation how software and use of IPv6 can reduce noise is interesting. 

Yes you are right : very few :-) perhaps it will go nowhere. Let’s see

[R1200CL]

1 hour ago, Patatorz said:

Yes you are right : very few :-) perhaps it will go nowhere. Let’s see

If what is claimed is true, this protocol may have something quite useful for audio.

Their diagrams of reducing noise showed on website, should be quite “easy” to reproduce. 
 

 I hope Diretta change their mind, and join AS. This FB is horrible 😀

 

Here is their second answer to me:

“We are open to collaborate with hifi equipment manufacturers.  This is our original target.

If you could introduce us to them and they contact us, we will be able to start a discussion in B2B relationship”.

 

I’m a bit reluctant to help [email protected], as if they would participate here and enlighten us more, it’s easier to ask, Sonore, UpTone, Signalyst, and several others to look into this and also verify the lower noise levels, etc. 

 

The listening test done, seems very promising. 
Maybe someone in the Novel tread is interested in review this.

 

http://patatorz.com/2021/01/02/english-diretta-protocol-an-improvement-in-digital-streaming/?fbclid=IwAR0PxFbvNPk7yoqI_1gBsRt1voHy5ZN7lL3aP_I58WjpLDO4llD1T-ek-Ws

 

[Patatorz]

I fully understand your points and yes the improvement is real. You can find much more feedbacks on French board (forum-hifi.fr). Diretta is focusing on FB, this is their choice. They already integrated their solution with some manufacturers like Spec. Spec is using their Lucia module in the Spec USB target (https://www.spec-corp.co.jp/e/pdf/DIRETTA_V092.pdf).

Take care 

[R1200CL]

Hi @FredericV

Is this protocol something you would be interested in looking into ?

 

[FredericV]

On 1/5/2021 at 9:03 PM, R1200CL said:

The listening test done, seems very promising. 

Maybe someone in the Novel tread is interested in review this.

 

http://patatorz.com/2021/01/02/english-diretta-protocol-an-improvement-in-digital-streaming/?fbclid=IwAR0PxFbvNPk7yoqI_1gBsRt1voHy5ZN7lL3aP_I58WjpLDO4llD1T-ek-Ws

 

By splitting the data into smaller packets, there will be more interrupts, and based on our testing this causes more software jitter as the cpu is interrupted more frequently to handle the incoming packet. This radiation is leaking inside the enclosure of the streamer and this can be measured.

With our own DSP, the DSP actually sounds a lot better when working on larger chunks instead of very small chunks. The smaller the chunks, the more context switches, and more noise generated by the cpu.

In a former life I was a network engineer for Alcatel, so looking at their approach they have to convince me why it would sound better sending a lot of small chunks instead of larger packets.

Furthermore in the screenshots I see LGPL, but is their protocol open source or not (as they want to license it to manufacturers), and how would it work with open source players such as MPD and Logitech Media Server - LMS already having a bitperfect protocol for this purpose.

Also to solve the noise issue on a LAN, all these isolators and optical solutions are not going to prevent ingress packets to arrive, causing an interrupt generated by the NIC, and every interrupt and potential context switch generates RF noise which is emitted from the CPU.

On CPU's interrupt handlers and userspace code actually fight for the same resources, and the more switching the more software jitter.

 

[Patatorz]

Thanks for the quick assessment. 

[jabbr]

On 1/7/2021 at 6:51 AM, FredericV said:

By splitting the data into smaller packets, there will be more interrupts, and based on our testing this causes more software jitter as the cpu is interrupted more frequently to handle the incoming packet. This radiation is leaking inside the enclosure of the streamer and this can be measured.

With our own DSP, the DSP actually sounds a lot better when working on larger chunks instead of very small chunks. The smaller the chunks, the more context switches, and more noise generated by the cpu.

In a former life I was a network engineer for Alcatel, so looking at their approach they have to convince me why it would sound better sending a lot of small chunks instead of larger packets.

Furthermore in the screenshots I see LGPL, but is their protocol open source or not (as they want to license it to manufacturers), and how would it work with open source players such as MPD and Logitech Media Server - LMS already having a bitperfect protocol for this purpose.

Also to solve the noise issue on a LAN, all these isolators and optical solutions are not going to prevent ingress packets to arrive, causing an interrupt generated by the NIC, and every interrupt and potential context switch generates RF noise which is emitted from the CPU.

On CPU's interrupt handlers and userspace code actually fight for the same resources, and the more switching the more software jitter.

 

 

Err ... sorry this isn't how modern NICs work. My Mellanox ConnectX-4 and 5 NICs ***most certainly*** don't generate a CPU interrupt for each packet.

In ancient days, perhaps, but modern networks just don't do this and the topic is far too complex for a robust discussion here ... see RDMA, ROCE

Also look at how an FPGA processes Ethernet.

 

A lot of these things is frankly why I'm hesitant to look at Diretta without access to a highly technical whitepaper. It's just handwaving to me otherwise.

[Holzohr]

I am on the fifth day of my Diretta trial. I use it with Roon and also have tried it with HQPlayer (and Roon). Amazing what software can do. Usually I am using Roon under Euphony and their Stylus endpoint feature. Diretta makes the sound somehow more full, more present. I am bad in describing things in English.

 

Thanks to ipv6 I could use the second ethernet NIC of my mainboard with Diretta. Interesting the throughput with Diretta to my NUC as Target compared with HQPlayer when used my NUC as NAA via this second ethernet NIC:

 

 

 

 

 

It's nice you can remove the USB stick after booting up.

[Miska]

46 minutes ago, Holzohr said:

I am on the fifth day of my Diretta trial. I use it with Roon and also have tried it with HQPlayer (and Roon). Amazing what software can do. Usually I am using Roon under Euphony and their Stylus endpoint feature. Diretta makes the sound somehow more full, more present. I am bad in describing things in English.

 

Thanks to ipv6 I could use the second ethernet NIC of my mainboard with Diretta. Interesting the throughput with Diretta to my NUC as Target compared with HQPlayer when used my NUC as NAA via this second ethernet NIC:

 

 

 

 

 

It's nice you can remove the USB stick after booting up.

 

Yeah, NAA traffic pattern is that way by design, on purpose. You also see somewhat lower overall bandwidth usage due to less protocol overhead.

 

I specifically don't want the pattern Diretta has, it too much mimics the problems of USB Audio Class.

 

[Miska]

On 1/9/2021 at 6:45 PM, jabbr said:

Err ... sorry this isn't how modern NICs work. My Mellanox ConnectX-4 and 5 NICs ***most certainly*** don't generate a CPU interrupt for each packet.

In ancient days, perhaps, but modern networks just don't do this and the topic is far too complex for a robust discussion here ... see RDMA, ROCE

Also look at how an FPGA processes Ethernet.

 

A lot of these things is frankly why I'm hesitant to look at Diretta without access to a highly technical whitepaper. It's just handwaving to me otherwise.

 

If protocol uses very small packets, it'll certainly have very frequent wake-ups. Something I specifically want to avoid with NAA. When NICs bundle several MTUs together, it just makes protocols relying on small packets suffer (for their own good).

 

[jabbr]

1 hour ago, Miska said:

 

If protocol uses very small packets, it'll certainly have very frequent wake-ups. Something I specifically want to avoid with NAA. When NICs bundle several MTUs together, it just makes protocols relying on small packets suffer (for their own good).

 

In summary: the entire TCP/IP stack can be implemented on the NIC:

 

https://shelbyt.github.io/rdma-explained-1.html

https://community.mellanox.com/s/article/what-is-rdma-x

 

in any case my point is that the CPU “wake up” issue is not inherent to TCP/IP and the idea that an arbitrary protocol is “better” than TCP/IP is not in following with modern network implementations. 

 

[Miska]

34 minutes ago, jabbr said:

In summary: the entire TCP/IP stack can be implemented on the NIC:

 

https://shelbyt.github.io/rdma-explained-1.html

https://community.mellanox.com/s/article/what-is-rdma-x

 

in any case my point is that the CPU “wake up” issue is not inherent to TCP/IP and the idea that an arbitrary protocol is “better” than TCP/IP is not in following with modern network implementations. 

 

Yeah, for gaming, the popular Killer NIC has also been doing that to reduce latencies and CPU load. I have bunch of Gigabyte motherboards with Killer NIC. Intel has also pretty good offloading support even on the cheaper NICs integrated to the motherboards.

 

HQPlayer NAA protocol (built on top of TCP and UDP) is trying to utilize these features

 

[jabbr]

1 hour ago, Miska said:

 

Yeah, for gaming, the popular Killer NIC has also been doing that to reduce latencies and CPU load. I have bunch of Gigabyte motherboards with Killer NIC. Intel has also pretty good offloading support even on the cheaper NICs integrated to the motherboards.

 

HQPlayer NAA protocol (built on top of TCP and UDP) is trying to utilize these features

 

I know that Intel implements Data Direct IO (DDIO) in Xeons and their NICs to improve power performance and reduce latency on small packet tasks.

[luisma]

As Miska is saying the offload feature on the NICs will take care of processing the packets and dealing with packet fragmentation and reassembly releasing the CPU of doing any extra work. Using larger packets are useful with routers as the tax on routers contrary to what the manufacturers try to sell you is not transfer speed but pps (packets per second) but here we are talking switching with one less encapsulation / de encapsulation process to perform at the network level), let me get back on track.

 

During all my life I have been a Network Engineer, Miska and others have mentioned NOT using smaller packets, now I'm familiar with why using jumbo frames 9000 and 9012 IIRC on networks, mainly for handling larger files, like large FTP transfers, VMs served over iSCSI and such but I recall (spending 12 years or so with VOIP) that one requirement for voice (audio) protocols is to have the smaller packet sizes, RTP is 12 bytes plus overhead and codec type employed.

The reason of these smaller sizes as you might know is to keep voice fluent, since UDP protocol is used and it connectionless and no retransmits and could be potentially dropped the idea is that words and syllables sent over IP would suffer the less during this transmission using smaller packets. Voip done well has an incredible low jitter.

My point and I am obviously asking as audio IMO is very very similar like voice wouldn't the small packet work well without having to resources to extra long packets? I mean the 1536 MTU size is standard, the only thing I can think off is voip obviously is real-time (not really but let's assume) and audio is usually buffered. Is that why a larger packet is preferred?

[luisma]

I'm going to answer my own question, there is an advantage indeed using larger packets as big audio files will be transferred in less time more efficiently since these are still buffered. Using smaller packets still will do the job but not as efficiently.

 

So Miska should I enable jumbo frames on my home network and that could be another tick box in HQPe? 😉

Joking of course

 

[Miska]

On 2/6/2021 at 7:29 AM, luisma said:

My point and I am obviously asking as audio IMO is very very similar like voice wouldn't the small packet work well without having to resources to extra long packets? I mean the 1536 MTU size is standard, the only thing I can think off is voip obviously is real-time (not really but let's assume) and audio is usually buffered. Is that why a larger packet is preferred?

 

I know VoIP side well too, after having been working at Nokia specifically on voice and video calls... ;)

 

VoIP uses small packets for couple of reasons:

1) Usually it uses 8-bit samples and 8 kHz sampling rate, although nowadays you can find 16 kHz and 32 kHz sampling rates as well. And then everything goes through a lossy voice codec. So the output bit rates are really low, like 16 kbps.

2) Latency, since the network introduces latencies already, you don't want to have lot of additional latencies in the device stack. Lot of latency makes fluent conversation hard.

3) Because UDP is used for RTP protocol, packets may arrive out of order and you need some amount of buffer to reorder the packets and deal with packet arrival time jitter as necessary.

4) Smaller packets make it easier for PLC (Packet Loss Concealment) algorithms to make lost packets sound less annoying.

 

 

While music streaming is lossless, so re-sends and everything else is in use, typically built on top of TCP protocol instead of UDP. Since music playback is not latency sensitive, maximal buffer sizes are used to buffer as much data as possible to avoid drop-outs due the varying network conditions. In addition, lossless streaming of audio and video (4K or similar) use a lot of bandwidth and is primarily quality sensitive.

 

On 2/6/2021 at 7:29 AM, luisma said:

My point and I am obviously asking as audio IMO is very very similar like voice wouldn't the small packet work well without having to resources to extra long packets?

 

No, it works especially badly.

 

On 2/6/2021 at 7:47 AM, luisma said:

So Miska should I enable jumbo frames on my home network and that could be another tick box in HQPe?

 

That is way below the OSI Layer HQPlayer operates on... ;)

 

But I'm pretty certain NAA work just as fine over the internet between Europe and US as within home network. ;)

 

[The Computer Audiophile]

18 minutes ago, Miska said:

I'm pretty certain NAA work just as fine over the internet between Europe and US as within home network. ;)

That would be a fun test!

[luisma]

47 minutes ago, Miska said:

Nokia specifically on voice and video calls... ;)

Amazing background

 

47 minutes ago, Miska said:

So the output bit rates are really low, like 16 kbps

Yep, codec plus payload, G.729 closely to what you are describing, 24Kbpps total

 

54 minutes ago, Miska said:

3) Because UDP is used for RTP protocol, packets may arrive out of order and you need some amount of buffer to reorder the packets and deal with packet arrival time jitter as necessary.

Yeah, packet loss, jitter and latency, I worked with several VOIP platforms and PSTN, nothing cellular, none corrected jitter, when it was present all the voice was garbled, all I could do was to "manually" reroute all traffic using BGP routes to alternate links

 

Miska thank you so much for taking the time to such elaborate explanation, nothing short of impressive.

 

[luisma]

50 minutes ago, The Computer Audiophile said:

That would be a fun test!

It would, in today's networks it should work flawless, the 150ms of fiber light speed latency won't matter as long as buffering is present, such a blessing to have buffers

[Qhwoeprktiyns]

On 1/5/2021 at 9:28 PM, Patatorz said:

I fully understand your points and yes the improvement is real. You can find much more feedbacks on French board (forum-hifi.fr).

 

Well, this one just published is interesting: http://forum-hifi.fr/thread-542-post-475971.html#pid475971

 

The author gave up on Diretta - too complicated, and no clear sonic benefit after extended comparisons. He concludes (google translate) "the differences that I seemed to hear were purely subjective and probably related to a psycho-acoustic bias".

 

I have followed this guy's posts on the forum for some time (I used to be a member), and always appreciated his feedback (measured, no hyperbole). He has a good system as well.

[Patatorz]

Your summary is not translating the subtlety of the original post. 
anyway this is a very good testimony as you mentioned done by a very balanced and skilled person.

[Qhwoeprktiyns]

On 3/13/2021 at 7:39 PM, Patatorz said:

Your summary is not translating the subtlety of the original post. 

 

I read the entire post, I am a native French speaker (so I did not miss any of the subtleties) and I summarized it accurately, IMO.

 

The way you describe the imrovements   (http://patatorz.com/2021/01/02/english-diretta-protocol-an-improvement-in-digital-streaming/) is very different from his - you don't need to read between the lines to understand that! 

These types of "tweaks" are probably not universal. If the improvements were completely random, I would assume high-end companies in Japan would not have bothered integrating this solution and offering them in 2000$ products, as they are not out to swindle their customers (though audiophiles can be an easy target!). 

 

So maybe there are some benefits, but its always good to avoid "hype" and present all points of view. 

 

 

[matthias]

@Patatorz

@hopkins

 

Is there some feedback in French forums about the new ZERO LINK connection between transport and DAC which is also promoted by Sforzato?

 

https://www.whatsbestforum.com/threads/zero-link-a-new-technology-from-sforzato-and-soulnote-in-japan-with-sample-wavs.32449/

 

@Miska What do you think about this?

 

Thanks

 

Matt