Dante defaults to unicast, supports multicast as an efficiency improvement if there are multiple listeners for a stream.
AES67 mode is multicast by default, (I think) can support unicast if both devices advertise that they support unicast mode.
Dante defaults to unicast, supports multicast as an efficiency improvement if there are multiple listeners for a stream.
Drumfix has made a kernel patch for us using Motu AVB devices and it is currently being tested so there is hope Linux AVB networking will soon be a great combo. At least that’s what I am hoping for.
For those who are interested:
This is not set up for computer to computer links and is specific to ravenna HW in many ways. The kernel driver is a start though and with the right NIC a local PTP master is probably a possibility.
That is cool they finally announced it publicly. I have had a private copy for a while, but I never managed to acquire appropriate hardware to make use of it.
I did however verify it could be detected in a Ravenna patching application running on a Windows computer.
The driver requires a couple of small patches if using a kernel from the last 6 or 8 months, but I have not verified those yet, so I haven’t submitted them back to Merging yet. If someone can make use of this and is running 4.18 or later let me know and I’ll speed that up.
I do not see why it would not work for that though, it is just a network protocol, it doesn’t really matter how the protocol is implemented.
I am toying with the idea of making an implementation of the closed source configuration tool (what they call the Butler daemon) based just on the interfaces in the GPL driver so that the driver can have a GPL configuration tool to go along with it. I would gladly accept a loan of any Ravenna hardware to help in testing that.
I’m not sure what you mean by that, it is just a network protocol, it is essentially hardware agnostic, you can use whatever means you want to get the correct packets onto the network. The GPL driver will run on any NIC which can support timestamps. You could run at lower latency if your NIC also has a hardware PTP clock implemented, but as long as the NIC driver supports timestamps you can run with a software synthesized PTP clock.
You can use quite a few different NICs as a PTP master, but you give up some accuracy if using software timestamp, so you would likely want hardware timestamping of PTP packets. I use a BeagleBone Black running Debian as a PTP master, but I don’t have a good way at the moment to objectively measure how well it runs in that role.
You could in principle run software timestamps everywhere (well, not in an audio interface, but everywhere you are using audio software) with the trade off that you will need to use higher latency settings to accommodate any offset or shifting offsets between endpoints.
By the way, if anyone is interested in experimenting with Ravenna compatible hardware, this is the lowest cost I have found so far. Based in Finland, but has an eBay store for purchasing in North America:
I was considering purchasing one of those to use until I win a game of chance and can purchase one of the Merging Technologies systems with my winnings.
Audinate also has some new low cost Dante adapters which can be put in AES67 mode and so should be compatible with this driver (the AVIO series). Those are in the same price range as the Hasseb devices.
Speaking of Dante, is Seablade around? I’m trying to find someone who has used Yamaha Rio or Tio series stage boxes, to see if they could run stand alone (without a Yamaha mixer). Those seem like relatively low cost Dante I/O module (relative to other Dante modules, still around 3x a comparable USB interface). If those can be put into AES67 mode I might be willing to get one of those, they would be around 16% of the cost of a comparable Merging Technologies system. I think Audinate is kind of sniffy about people implementing Dante drivers without paying for a license though, so it would have to be usable in AES67 mode.
The whole implementation requires a master clock is all. I guess what I mean is that it is not a full featured end point.
That was my first thought as well… not that I would do that (at least not at this time) but “someone” would.
My NIC does have that possibility, yes.
That is definitely the lowest cost aes67 end points I have seen anywhere. This one: http://hasseb.fi/shop2/index.php?route=product/product&product_id=65 would not only give i/o but also allow me to sync my current card via s/pdif. Product 64 would add two mics at a time. However, unlike the first one does not have a built in switch. I will go look at the Audinate offerings next.
I’ve used RIO boxes. You can run them standalone and control routing with the Dante Controller. The one thing you need to control that isn’t possible with the Dante Controller is the head amp gain levels, and Yamaha provides a small application that allows you to do that.
Just be aware that you must have a PTP master clock available for them to lock to. They have no internal clock. Usually that is provided by the console.
Oh sorry, yes Seablade is around.
For the record, you can set a Rio box to be the master clock on the network in Dante Controller, so I believe they do in fact have an internal clock, but haven’t looked into this very thoroughly.
But as Reuben mentioned yes they can be used standalone, and in fact the Tio boxes in particular become pretty financially saavy for basic IO breakouts on stage for that reason:)
That being said I currently have a 3224 acting up I gotta f*#)($ with until I get it working again soon… But generally they are pretty solid, just sometimes they can be picky about their sync and the Refresh/Resume settings. The preamps are clean, not great but certainly not bad. The pad at around +18dB on them makes a large difference to noise floor, so it can be better to cheat them up until they overcome that if you can (The pad is automatic, not manual, and kicks out at 18dB of gain IIRC).
Also as mentioned headamp control without a console is through R-Remote, along with firmware updates on the newer firmwares. I have never tried running R-Remote on Linux through wine, it is very possible it may work given that Yamaha writes their own stuff and most of their UIs look like they are from the late 80s still, so I don’t think they have changed UI toolkits in a while honestly. I run the CL editor fine on Wine and can connect and control a mixer, but even if R-Remote did work under wine I am not sure I would do a Firmware update under Wine for the record.
And speaking of Firmwares, make sure it is up to date if you are looking for AES67 compatibility.
Beyond that I haven’t had a chance to even look at the Merging Tech driver linked to above, but am curious about it. Part of this has to do with I am currently running Linux on my Pixelbook via Crostini with no audio support so I am holding off on much on that end until that hits (Which it looks like will be in about 3 releases now as they just pushed a big commit until the code for it).
If I ever get around to testing that driver I will let you know if/how the Rio boxes work with it by the way. And also for the record keep in mind those boxes are literally just IO, there is no mixing or DSP capability in them, and while supposedly they are capable of 96k the CL and QL series don’t, so I haven’t personally tested that, though I think the Rivage series can do that, I just forgot to look into it while I had a show running one recently (Steely Dan I think while they were teching is running on one IIRC).
Yep a quick glance at the manual confirms they can act as word clock masters on a Dante network. Not sure how that plays into AES67 though if that will translate at all, it has been to long since I looked into the particulars of it to know if it can transfer Word Clock as well.
I was going to ask about that and you beat me to it thankfully. I haven’t looked for the full user manual yet, but the Yamaha product page really only discusses using the Rio stage boxes with a Yamaha digital mixer, so no discussion of whether they can be set to AES67 compatible mode, work with other network audio devices, etc. Pretty crazy, some systems sell just a Dante I/O card to add to an existing system for over $500, and you can get these at every retailer for $1000, and I have seen one as low as $800.
What I would really like is 4 or 8 really quiet, low distortion pre-amps. Kind of like you can get in a Merging Technologies Hapi for…$5000.
Maybe “clean, not great” will have to do.
It has some limitations currently, I think it only instantiates 8 channels. It relies on a closed source user-space app to setup the driver and make connections, it has a EULA which the usual prohibitions against reverse engineering, so I am trying to avoid installing it if at all possible, and it also mentions the user space app phones home so they can tell how many installations are running that driver. I wouldn’t even mind the phone home “feature,” but avoiding reverse engineering just goes against my nature.
The alsa driver is GPL and open. So anything that works with that is not reverse engineering. The butler is closed, true, but giving gpl code what it appears to need, does not need the butler to even be installed. True that is where all the discovery resides, but that part is already described in the documentation. The rest is in the spec…
Exactly, which is why I am trying to avoid installing the butler, to avoid even the appearance of violating the user agreement for the butler. I would like to see how they implemented it and what extra features it has, but there are headers in the GPL source describing what messages the driver responds to, so as you say it is not really necessary to install the butler. There are python libraries for mDNS, avahi bindings, bindings for various network protocols, so it seems that in principle it should be possible to create a portable, open implementation relatively quickly. As someone I know often quips, it’s just SMOP, “simply a matter of programming.”
There is AES67 compatibility, you see it in the Dante Controller application when you have those devices on the network. But honestly I have not had a chance to really test it or it’s capabilities, as I often am just using straight Dante or straight AVB depending on the situation (And far more often Dante, AVB generally when I am doing more hands off systems using BiAmp etc.)
Yes the Yamaha Pres will give that no problem, they will generally be pretty neutral, as opposed to some pres that will give a character to them.
Sadly I am currently suffering the downsides of gig economy, in that I just injured myself last night and am out of work as a result on this next show at least (Annoying as this show was pretty much my income for the month), it is unlikely I will be able to look more into the AES67 side of things until I am back up and walking around.
You are not missing anything at the moment. I loaded up the driver, and it shows up in aplay -l and in alsa-info.sh, but when I tried to start jackd:
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: mmap-based access is not possible for the playback stream of this audio interface
ALSA: cannot configure playback channel
I wish they had gotten Paul or Takashi or someone with some real linux experience to write their driver. I had to bug them about some netfilter changes a while back, and I just had to submit a patch for post-4.18 kernels because of the 2038 timestructure work that has been going on, and after I finally got a version which will compile and run on a recent kernel it turns out that it is not even usable with jackd or ardour. I’m not sure what the use case is, but I guess they have only been testing hi-fi playback with their DAC’s or something, it isn’t usable for music production on linux in the current state.
Out of curiosity, try a period of 512(And other period sizes as well)? Dante is picky about this IIRC and only runs at 512/2 on other OSes, it wouldn’t surprise me much if AVB was similar.
Is there actually a aes67 device connected and configured? If not you may have 0 channels. In other words, I expect the workflow is something like:
- Connect to device 1 with 4 inputs,
- Connect to device 2 with 2 inputs and 2 outputs,
- use butler to set up alsa pseudo device with 6 inputs and 2 outputs
- start jackd (or use zita-ajbridge)
That will be something useful to try later, but right now the error is very obvious. Jackd, ardour, and zita-ajbridge all return an error if the ALSA device cannot be opened with MMAP access. The Merging Ravenna driver currently does not set the MMAP enabled attribute in the driver, and some of the source files have comments to the effect that MMAP access is on the list of features for “later.” Conceptually I think I understand what would be required for memory mapped access, but I do not the the API details to do that. Most drivers that use MMAP are mapping hardware resources into memory space, this would be a software driver emulating a synthetic hardware device, and exposing memory buffers for MMAP use by user space. Maybe the usb-snd driver does something similar I could check as an example. ALSA lib had a placeholder for a long time named VMMAP which I think was going to be virtual memmap, that may have at one point been intended to be some kind of helper function for things like this, but it was never implemented and the place holder was removed last year sometime.
Merging Technologies has a Linux/ALSA AES67 driver available for download here is the link to the page; https://www.merging.com/products/alsa_ravenna_aes67_driver
The personnel use build only supports 8 ch. of i/o but it will work with any AES67 compatible device and ALSA sees any AES67 device connected via Ethernet as an available ALSA audio device
Uhm…yes, that is what the last 13 posts were discussing.
But without MMAP support, so you can’t actually use it with Ardour.
Have you tried it using direct ALSA access and not Jack?
I haven’t dug far enough into the code to know if that will make a difference honestly, but if aplay is working with it it wouldn’t surprise me if it did. These days I rarely use Jack except in more complicated setups.