Diretta audio protocol

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

 

[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

 

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

 

[Miska]

13 hours ago, Exus said:

Then I also have the problem all the time that HQPlayer won't start properly because it somehow fills up the log. Maybe @Miska can help me here.

 

I think one issue here may be that, HQPlayer needs to get know physical properties of your DAC and Diretta ASIO driver is hiding those behind some obscure figures. One of the very important primary features for HQPlayer is to be able to figure out as much detail as possible about the actual D/A conversion hardware. And any extra layers between damage that goal. One of the reasons why I developed NAA protocol with the goal to expose the actual D/A and A/D hardware through as-is with maximum details.

 

HQPlayer then adapts it's processing to those hardware details.

 

[Miska]

14 hours ago, Exus said:

After I switched to ASIO driver in HQPlayer and try to restart HQPlayer, both processes, the one for HQPlayer and the ASIO driver are frozen.

 

I kind of totally fail to see why would one use Diretta with HQPlayer...

 

Seems like Diretta claims the hardware to have some 40+ channels which is unlikely the case.