“when Dante first started picking up, one of the selling points WAS interoperability with AVB…”
Figure 5 on page 16 of that white paper seems to be saying to me that Dante can be extended in the future to use additional protocols. That is Dante currently is not interoperable with AVB, but that it can be made interoperable with AVB by future extensions to the protocol. Probably not really a concern right now, I think the only production gear I have seen using AVB is the new Mark of the Unicorn network gear (which uses AVB to connect between units, but until recently only connected to the computer with USB or Thunderbolt. A news release on the MOTU web page says that Ethernet connectivity between a Mac and those units is now supported with the latest firmware).
“Which suggest it may not be all that difficult to get [Ravenna and AES67] running [on linux]”
The transport protocol is actually the easy part, there are several applications which can already play RTP streams, so I don’t think the RTP/RTCP/TCP/IP portions of the stack would be much problem. The biggest thing I’ve been trying to wrap my head around is how to integrate disparate network pieces into the usual audio stack. For example, synchronization is through IEEE 1588 (kind of a high performance network time protocol). That would seem to require that you are running either ptpd or linuxptpd to synchronize time. The network time can either be a separate clock domain, or can be used to discipline the system clock like is usual for ntpd, so potentially configuration options there, or force the users to setup all of the required time synchronization pieces outside of ALSA setup. So now ALSA may have a dependency on the system having ptpd or linuxptpd installed for network audio devices (but obviously not PCI or USB). Or ALSA would have to incorporate the equivalent of ptpd into an ALSA network audio driver, which besides just being a lot of useless duplication of effort might cause conflicts if you were also really running ptpd on that same machine. I suspect that the Windows and Mac virtual soundcard drivers do put the equivalent of ptpd into the audio driver so that the audio clock domain can stand alone and not have to worry about trying to force the system clock to sync to the network clock. I would be interested to know what happens if you try to run the Ravenna virtual soundcard driver on a Mac that is already running ptpd.
And that is just the plumbing, before you even get into questions about how to present devices. Would every device discovered on the network show up as an ALSA device? Would you want to use a configuration utility of some kind to discover devices, and group channels together to be presented as ALSA devices?
Might be easier to try to make a jackd backend first, and after everything is working decide if it should be incorporated into ALSA. Might be analogous to the situation that happened with FFADO, create a stand alone implementation to get everything working, and if it seems solid it can be merged into ALSA later.