The topic of automatic sample rate changes is "special". It is something we all would wish for, but it is not so easy, because the usual protocols for carrying multiple channels do not support it well. There is something missing in the protocol header that makes it possible to identify the sample rate easily. This is not an RME-specific problem; this is based on audio standard definitions of the past.

In network-based setups (AVB, Dante), there is, to my knowledge, still no simple solution for automatic sample rate switching, and it requires this reconfiguration effort that you describe. I am also not sure whether this is easily possible by the nature of network streams between devices. If you have to handle projects with different sample rates, this involves a lot of manual work.

In this respect, I see the advantages of AVB and Dante mainly in setups where the sample rate does not change or at least not so often. The amount of work also depends on how many devices are involved.

The topic of automatic sample rate changes is not so easy in general.

Clear detection and automatic switching between single, double, and quad speed is only possible if the clock slave can be connected via a digital port that does not use channel multiplexing for higher sample rates, such as AES and SPDIF (optical and coaxial). With some devices you could use their AES ports for syncing (e.g. Octamic XTC).

Also with MADI, it's not that simple. Even when using 96k frame, this frame type is only used in double-speed mode. Single and quad speed still use the same SMUX protocol (with quad speed using four multiplexed SMUX channels).

Therefore, with MADI, only the switch from single or quad speed to double speed is defined and can be performed reliably. While we are at it, another bit is there to distinguish between 88.2 and 96 kHz (or 44.1/48 at single speed, same for quad speed).

As soon as the clock master switches to single or quad speed, then SMUX protocol is again in use. SMUX/4 at quad speed is not another protocol type with another distinguishable header, it simply means four SMUX channels are being multiplexed to achieve the higher bandwidth for audio data which is necessary for quad speed. So, you can't distinguish SMUX/4 from SMUX. Its the same data stream of audio with the same header structure.
So if the clock master changes to single or quad speed, then the MADI clock slave only sees 64 channels with audio data in SMUX format but it has no clue whether it should change to SMUX or SMUX/4 (single or quad speed).

With Word Clock, a clear distinction between single, double, and quad speed is also not possible.

The advantage of a MADI (or clock master / slave) based setup is here, that the change from single/quad speed works perfectly.
And once you need to switch back you only have to change the sample rate to either single or quad speed on each of the devices.

I made a proposal, that RME might think about, to default to switch from double to single speed if SMUX is being detected.
This would at least enable a seamless switch between single and double speed which (I think) most of us use regulary.
I would regard this as very useful, because only few devices have something like AES I/O that could be used as sync port.

Thanks for the reply. two-way setup ?   From the units one can subsc
ribe to the CRF stream from Digiface AVB, but not the other way around as the is only one slot in the Digiface AVB (stream 9). I guess this is not necessary-
Else using the Minan Manager and reload workspaces on the Digiface AVB make life somewhat better. But since I am using Nuendo I have started to resample projects and will probably standardize on 48kHz, more or less.
Other DAWs does not have the same problem, seems like.