1 Topic by infreq (edited by infreq 2022-03-12 10:21:54)

  • Registered: 2021-08-17
  • Posts: 5

Topic: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

UPDATE 12th March 2022 particularly for others interested in this hardware who might become doubtful after reading this thread: some good news.

Workaround to just be careful when switching sample rates or opening projects became a habit that avoided system crashes.

However, this morning I accidentally repeated the steps that cause this trouble, but the crash didn't occur. I was able to just correct the SR in the project, re-aligning it with the hardware's SR without resorting to a hard reset of my laptop, and it worked. This was never the case with MacOS 11.5.2, all audio just stopped working and a hard reset was inevitable.

I've finally been able to upgrade MacOS without breaking other plugins/software/etc. This problem is no more. Perhaps that confirms where the problem was. I no longer care, I'm just happy that it works as expected and the hardware is excellent.

I'll leave the forum post up in case it's of help to others who see a similar problem.


Original thread:


I'm experiencing a fair amount of trouble with the following and would appreciate any support or insight towards a resolution.

-------------------

M-1610 Pro (latest firmware: m1610_fw_ms_2.1.1_v69_20201207.swu)
Digiface AVB (latest firmware v239, latest driver v3.25)
MacOS 11.5.2 on MBP2020 16"
TotalMix 1.73
RME AVB Controller 0.9553
netifc (latest, downloaded this week, is definitely running)
Able to connect to and configure the M-1610 via http.

-------------------

Note, no switch -- this is a single M-1610 unit plugged directly into the Digiface AVB via ethernet, which is plugged directly into the Mac via a USB-A to C adapter. I was reassured this would be sufficient by a rep at your UK supplier, on that basis I'm confident it should work. The issues I'm seeing:


(1) changing sample rate on the Digiface AVB is a minefield. Max's post here (https://forum.rme-audio.de/viewtopic.ph … 74#p166374) from March describes it well and I've determined the same workaround, but note that my system is Intel based and the drivers now support Big Sur. Once I've run into this problem it seems as though the Digiface AVB driver has crashed(?), with any attempt to trigger playback (if the device is still selectable) not resulting in playback (taking the time to switch back to the MBP device restores playback, albeit it through the MBP device), and no amount of disconnecting and reconnecting prompts the Digiface AVB back to a functioning state. When things are stuck like this, if I attempt a MBP reboot the restart either times-out or I lose patience and perform a hard restart (power button for five seconds). In either circumstance the resulting crash logs include "Restart timed out in phase 'Notifying power plane drivers' and make reference to 'loaded kexts: de.rme-audio.driver.RMEFirefaceUSB' -- I'm no MacOS crash log expert though, so if you'd like me to privately provide the couple I've collected then I'm happy to.

I've seen this problem with Studio One and Bitwig. The workaround is strongly prone to error when frequently working at various sample rates, particularly when you're a loon like me who likes to use different DAWs for their respective strengths. If you get it wrong, the above scenario of the inevitable crash-restart becomes true.

Bitwig is somewhat amenable to the workaround because it has an 'Automatic' sample rate setting to take a steer from the hardware (note, only if I open Bitwig and not touch the sample rate, otherwise the above is true), but in Studio One this workaround is flawed. The process of using the MBP's coreaudio device to set an S1 project anywhere between 44.1kHz - 96kHz, saving the project, quitting the application, connecting the Digiface AVB, updating sample rates accordingly, opening the S1 project ready for work, isn't possible for 192kHz because the MBP coreaudio device does not support it. I'm unsure how to work at 192kHz in S1 using this approach, but I'd be happy to receive guidance if I'm not understanding something. To underscore the point, I'm finding that if at any stage the DAW's sample rate differs from the Digiface AVB's, the above is true.

Any insight or experience on how to make this less painful will be greatly appreciated, and I'm hoping -- given Max's post in March -- that this issue is already known and being resolved(?).

---------


In the scenario where audio is streaming:

[RESOLVED: user error, see Marc's first reply for the simplest of trouble shooting advice]
2) the M-1610 only functions using secondary streams, and is flashing the red power ring to warn of either (a) No Data or (b) Domain Boundary, even as the audio is streaming successfully. If I make connections using its Primary streams (for inputs or outputs) it instead warns only of Domain Boundary (reboots or reconnects don't resolve this, and I'm not using a switch), and the streams do not function. All required formats and sample rates match, success literally depends on whether a primary or supplementary stream is used. Two obvious problems: I can't use 8 primary streams of the M-1610, and the device is constantly flashing red even when it's streaming.

From what I've been told and understand I don't see how, but is this a consequence of not using a switch? Why else could this be happening? I also have Hive installed so, as above, I can provide logs or details from that privately if it's helpful.

---------
[RESOLVED: appears to have cleared up by using the correct port]
3) strange aliasing artifacts audible at 96kHz. I've not dug as deep into this problem (i.e. perhaps it's happening at other sample rates as well) chiefly because I'm a bit weary from issue (1).

---------

I've also experienced odd behaviour that I've not been able to replicate yet, like the Output Format of the M-1610 becoming frozen at 96kHz (not just taking a few seconds longer to update, just staying at 96kHz). A reboot and rest of the system resolves it, but perhaps if it crops up again I can investigate.

These are the big few issues. Faulty unit? Faulty user? Somewhere in the middle? Some sanity checking and response would be greatly appreciated.

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

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Hi,

just to sort out the most basic thing: When you tried to use the primary streams, you plugged the ethernet cable into the primary port and secondary port for secondary streams, right?

  • Registered: 2021-08-17
  • Posts: 5

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Cheers Marc, issue (2) is a good example of making something foolproof and a bigger fool coming along to prove it wrong. Yes, I'd absent-mindedly plugged the ethernet cable into the SEC port and, being amongst the weeds of issue (1), not "made the connection" to solve the M-1610 issue I was seeing. I've now corrected the port connection and it's functioning smoothly, thanks for providing a dose of clarity.

I'll amend my original post to highlight user error for (2) in case anyone else stumbles down this path. Also (3), changing the port appears to have cleared up the 96kHz distortion/aliasing issue, so perhaps the aliasing was a result of me trying to operate it through the secondary port without a primary connection, or my secondary port is askew somehow. I guess I'll find out if I ever need to connect the secondary port, for now it's fine.

It all just leaves issue (1), which rereading had become a bit of a tired vent, so my apologies. If possible I'll amend the title of this post to reflect that the main issue I'm working around is with the Digiface AVB.

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

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Good to hear that you're making progress!

Regarding the first issue: How is your system clocked, i.e. who is clock master?
It could help to clock the M1610 off the Digiface, setting the Digiface's clock source to "internal".

  • Registered: 2021-08-17
  • Posts: 5

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Yep, I'm afraid that's how they're configured. Only detail perhaps worth noting is that the M-1610 receives clock source through AVB Stream 1.

I'm assuming (in my layman's armchair) that the Digiface AVB only supports a sample rate update from AVB controller software and because the DAWs are not AVB controllers there's some kind of conflict/discrepancy that the driver isn't handling?

To quickly add to the M-1610 output format/sample rate freezing: I saw it again yesterday but couldn't determine behaviour leading up to it. I now know that temporarily switching its clock source to internal frees it to change, then when switching clock source back to the Digiface AVB all is well.

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

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Can you elaborate a bit on this freezing thing:

1. How do you set the new sampling rate? RME AVB Controller, Hive, M-1610 Web Interface or Display UI?

2. What exactly does "freeze" mean? The device is not responsive anymore? Or just: it should be 48 kHz but it sticks with 96 kHz?

What happens if you try it again? What happens if you try another way of setting the rate (see above)?

7 Reply by infreq (edited by infreq 2021-08-20 18:47:28)

  • Registered: 2021-08-17
  • Posts: 5

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Sure thing --

1. I typically set the sampling rate by RME AVB Controller, but I have also been able to use Hive, the Web Interface and the unit's display.

2. Apologies for ambiguity, by freeze I mean your second option. The sample rate will not update from e.g. 96kHz to 48kHz, but only for the M-1610's output format, the input will update. The unit remains functional.

[Edited to answer both final questions]
If I try to alter the sample rate again the same thing happens, the input format will update accordingly but the output format does not update.

I didn't think to use one of the other methods before temporarily resetting the clock source to internal. If it happens again I'll try the other options and log the results here.

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

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Hi,

please update your M-1610 to fw 2.2.0 (released today).
Download here: https://rme-audio.de/downloads/m1610-2.2.0.zip

We fixed some stuff regarding sampling rate changes via Web and Display UI.
This could already improve things.

In general: Switching sampling rates in audio networks (...Dante is no exception here...) is more tedious than in older p2p-technology. The reason is that you have centralized control over all devices in the network.
That seems weird at first, the contrary should be the case, right? (...less tedious...)
However, Milan requires some precautions before changing sampling rates, so one cannot accidently mess things up.
One of them is that outgoing streams must be disconnected and incoming streams must be stopped. Moreover, as sampling rate converters could be involved, there is a difference between device and stream rates.
So the process boils down to: stopping/disconnecting all streams, changing the device rate, changing all stream's rates, starting/connecting streams again.
All of this must be done by the controller, but not every controller implements all of this (at the moment). Hive for example doesn't touch stream rates, so you'll have to do that manually afterwards (including the stopping and starting).
Our controllers (RME AVB Controller, web interface, display) usually do all of this, but handling DAWs that arbitrarily try to change rates, when so many steps are involved, is just no easy task.
However, we are already working on mechanisms to improve this. Thus, feedback like yours is immensely valuable, thanks for posting this!

  • Registered: 2021-08-17
  • Posts: 5

Re: [Resolved] Trouble with Digiface AVB, MacOS, M-1610

Hi Marc,

Thanks for that, I'll install the (swift!) firmware update and see how it goes.

Your explanation on the general AVB approach is helpful for providing steps to avoid some of the pitfalls of working with Milan network audio, I appreciate that and will bear all of it in mind. The possibilities of it are great, the hardware sounds terrific, and with these workflows embedded in habit I'll certainly be a happy camper.

I also appreciate and accept that DAWs shouldn't necessarily be the source of a sample rate change, and the complexity of integrating that kind of functionality is problematic given the other factors you've explained.

However, I don't follow why it's therefore also necessary to accept that my computer steers into an inevitable crash-restart scenario if a DAW's sample rate differs from whatever is set in the Digiface AVB. I am curious to know whether you're able to reproduce this problem or if it's something specifically related to my type of system. I still have the macOS crash-restart logs if you think they'd be useful.

More generally, (I note the following is littered with assumptions) I'm also curious to know whether it's necessary for the Digiface AVB to use the same USB driver as other RME USB interfaces if its requirements for sample rate changes differ significantly in the way described. i.e. is it possible to have a dedicated AVB USB driver that ignores sample rate changes from any software that isn't a controller, but still "reports" its sample rate for DAWs/OS/software to work with? Or should I understand your note about handling DAW sample rate integration in an AVB system as being no easy task to also mean that this isn't easily possible, and perhaps implicitly that this kind of integration between DAW and AVB devices is (hopefully) one for the future as the industry adapts?

Apologies if these are tricky questions to answer on a public forum, I don't mean to be a nuisance. I'm enjoying the quality of the hardware and the workarounds are generally effective. I'm just an end user who doesn't want to steer my system into a crash-restart if I accidentally open up the wrong project file, who is trying to make clear sense of why that is currently the case, and who would like some idea of whether or not there is a better solution than just the understanding to be careful --  something that can easily wane at 10pm with a deadline looming.