1 Topic by mruebsamen (edited by mruebsamen 2023-01-07 13:55:25)

  • Registered: 2019-04-21
  • Posts: 160

Topic: I don't understand clocking in an AVB network :(

Can somebody explain why the RME avb devices don't follow the clock set in the AVDECC controller? Is this really true that I have to set the clock on every single device? This sounds crazy and could easily result to errors.
In ADAT times the RME converters adjusted to new sample rates immediately by themself. In a recording session this means that I have to set the right sample in my project, in the AVDECC, on the m32ad pro and on the m1610pro... Let's not even think about large live sessions :-/

2 Reply by MC

  • MC
  • MC
  • Administrator
  • Offline
  • From: Germany/Thailand
  • Registered: 2007-04-06
  • Posts: 25,615

Re: I don't understand clocking in an AVB network :(

That's why in networks you usually NOT change the sample rate at all - it's a big mess. The very complicated reconfiguration of all entities and network participants is fundamentally different to a simple clock slave as with digital audio. The manual of the DF AVB explains that the unit won't follow sample rate changes of an ASIO host for this reason.

Regards
Matthias Carstens
RME

MC's Website

  • Registered: 2019-04-21
  • Posts: 160

Re: I don't understand clocking in an AVB network :(

Thank you Matthias for the answer. It‘d hard to believe that this is the one answer for this problem. I always thought this is the reason why we have AVDECCS and clock domains.
In the studio the complexity is far lower than on large live events, but it is important and relevant. Not all of our productions have been recorded by us, which means that clients throw their audio in all formats ans sample rates to us. So we switch sample rates quite often. This is a real pain if you have to change the sample rate in 4 to 5 different places. Could it be possible to implement a „legacy mode“ in which the new AVB devices would behave like the ADI pro or ADI8Qs  and some others listening and following the clock in the ADAT, AES, SPDIF, MADI (or best case even i the AVB) stream?

  • Marc S
  • RME Developer
  • Offline
  • Registered: 2019-06-11
  • Posts: 110

Re: I don't understand clocking in an AVB network :(

I disagree that live events are more complex with regards to clocking. On the contrary, it's way easier. The system is fixed at either 96 kHz (most of the time) or 48 kHz (in "budget" environments). Most "96 kHz units" also have sampling rate converters, so they will happily take whatever they get. The only critical point is setting the clock master.

As the live sector has been and is the driving force behind Milan/AVB, this has been resolved in a fairly easy way:
Hive, for example, offers a media clock setup where you assign all units to a media clock domain and select the master device. As long as all units are Milan complient, i.e. have dedicated CRF in- and outputs this really just works.

However, in the studio, where you are trying to avoid sampling rate conversion and have to deal with 44.1 kHz and 48 kHz and multiples thereof up until 192 kHz, things are more complicated.
Not due to the fact that every device's clock domain has to be set to the correct sampling rate - that's the easy part.
The hard part is that for all stream in- and outputs on every device the stream format has to be set up according to the sampling rate. This is done by the RME AVB Controller (and our device's web interfaces), but only per device.
Hive, that is able to control multiple devices as described above, doesn't set stream formats along with the rate. It doesn't know if a device supports sampling rate conversion or not, and if so if the user wants conversion, so it just doesn't touch formats at all...
We already discussed this issue with Hive's main developer, so this might improve in the future.

As for "simply following one device": As Matthias already said, reconfiguration is complicated. All streams have to be stopped, clock domain and stream formats have to be set up, streams have to be restarted again. As AVB uses stream reservation, the reserved bandwidth has to be changed along with the format, which takes up to 20 s in a legacy AVB network. It's not just "simply toggle a bit to set another rate", like with MADI or ADAT.
Btw, the same is true for other Networks like Dante, where you have to select each device in the Dante controller, go to the Device Settings tab and manually change the rate.

To conclude with something positive: It's not impossible to do it, but it's not just an extension to existing devices or software. Ideally there would be a specialized AVDECC controller for studio environments that is somehow tied to the DAW, but clearly gives feedback to the user what just happens and, if in doubt, let the user decide what to do. And as AVB and Milan are open standards/specifications, this piece of software doesn't necessarily have to come from device or DAW vendors. But of course it might, see Aneman in the AES67 world for example.

5 Reply by ramses (edited by ramses 2023-01-08 20:08:54)

  • ramses
  • DAW Mastermind
  • Offline
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 13,229

Re: I don't understand clocking in an AVB network :(

Marc S wrote:

Not due to the fact that every device's clock domain has to be set to the correct sampling rate - that's the easy part.
The hard part is that for all stream in- and outputs on every device the stream format has to be set up according to the sampling rate. This is done by the RME AVB Controller (and our device's web interfaces), but only per device.

Hello Marc, happy new year. Thanks for the detailed answer.

One question from my side. Instead of waiting for another manufacturer to offer a 3rd party solution.

Wouldn't it be possible in the RME AVB controller to combine the configuration of multiple devices in a kind of "work set" or "workspace", with the goal to automatically store and recall the configurations of multiple devices in one go?

Anything that can be individually configured and stored should also be automatable without too much difficulty so that everything can be done in one go.

For an RME-based AVB network, it could also be an advantage to get this reliably under your control. This would also be advantageous for the customer in terms of fewer (EDIT) support contacts for such generic things concerning the setup and operation of an AVB network.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14
  • Registered: 2019-04-21
  • Posts: 160

Re: I don't understand clocking in an AVB network :(

Thank you Marc for the detailed answer. I'm just afraid that even though everything is absolutely correct you just said, that this too much potential trouble for a studio.
Unfortunately we have to upgrade our audio system in the studio now (because Apple has dropped Firewire support so our Prism based, distributed audio system doesn't work anymore) and I'm really worried that things get too complicated. (By the way I'm working in the audio industry since 30 years and have an IT and math background)
Anyways I'm pretty sure that we are not the only ones who need to have distributed converters for different monitoring setups, mastering chains and more converters for the different recording rooms all hooked up together in one system, running one clock.
Don't get me wrong: I love RME products, since we switched a couple years ago from expensive Prism gear to the m32ad pro and m32da pro for live recordings (together with a Digiface avb and a MADIfacepro (that we sold (which was totally stupid (what a great backup interface)) And when I got the ADI2 Pro I was blown away how easy and powerful this little box is. Especially setting the sample rate in the DAW (within a second Digiface USB and ADI2pro just switched :-)
So first of all a big thank you for pushing new technologies like AVB and supporting them smile