Documentation ?

[agfline]

Hi, thanks for your effort opening Dante protocol !
I've been working on some reverse engineering projects too and I'm also interested in Dante. I'd like to work on the sending audio capability, however I mostly work in C and know nothing about Rust... So I was wondering if you had any note or documentation about Dante and your findings, so it could help me to start a low level C library ?

[teodly]

Audio transmitting is already done in transmit branch as a PipeWire virtual device, but when using it sometimes audio drops out especially when used with a more complicated audio app such as Ardour, and I don't know whether my app or PipeWire is to blame (because PipeWire isn't yet mature and is sometimes unstable). Currently I'm working on ALSA virtual device because ALSA plugin API is less complicated and more mature so I hope it will be more stable.

If you want to send/receive audio in your application, I bet you should use a library like PortAudio. This way it will be compatible with my alpha-quality PipeWire virtual device, with the future Inferno ALSA virtual device and with many other audio devices, physical or virtual, e.g. AES67 Linux Daemon (also compatible with Dante!).

If you want to implement a C library for Dante from scratch, I suggest to implement a C interface for Inferno, unless you want to avoid Rust or have a different vision on implementation.

There is currently no well-written documentation of the reverse engineered protocol, but there are comments describing (guessed) fields in packets, such as in https://github.com/teowoz/inferno/blob/transmit/inferno_aoip/src/arc_server.rs . However when I'm finished with the ALSA plugin, I will write a detailed 'tutorial' on how to send & receive audio to make it easier to develop alternative implementations (e.g. for embedded systems)

[agfline]

Good to see the project is still active and thanks for those helpful links.

AES67 is not an option for me, since my hardware is too old to be AES67-compatible (took time to find that out, despite a documentation saying the opposite...). Hence the interest in Dante protocol. A C implementation could make possible a future kernel-space driver, just like AES67 Linux Daemon. This would greatly increase performance and stability especially with embedded devices.

I've just began to learn Rust and try to look at your code, but I'm quite busy and it'll surely take time...

Thanks for your work anyway, I will monitor it closely ;)

[Mo-way]

@agfline Here's a quick writeup of the audio packets: https://ritcsec.wordpress.com/2020/04/28/reverse-engineering-and-vulnerability-assessment-of-the-dante-protocol/

The control protocol is best explained by Chris Ritsen, e.g. here:
https://gearspace.com/board/music-computers/1221989-dante-routing-without-dante-controller-possible.html
https://github.com/chris-ritsen/network-audio-controller/wiki/Technical-details

Out of curiosity: Which aspect exactly prevented you from running AES67 on a device? Apart from PTPv1 and PTPv2 there's basically no technical/performance difference for Dante vs. AES67, AFAIK.

[teodly]

I guess @agfline is talking about a device that manufacturer stopped supporting years ago, so there is no AES67 firmware update.