RME UFX+ vs. MSP - discontinuities caused by time-shifting?
Hi,
I've just upgraded my system to include an RME Fireface UFX+ used with a MacBook Pro (Retina, 13", early 2015, 10.13.6).
When I use the UFX+ as an audio input device to Max/MSP (v 7.3.5), I get discontinuities in the audio signal. It looks like a problem I've seen in the past where an I/O block is lost somewhere - so you get a sudden jump in time without a dropout in the signal. An example of the artefact in a 2 kHz sine tone, recorded using the sfrecord object is shown in the attached png file. (MSP is running at 44.1 kHz, with I/O and signal vectors of 1024 samples)
This happens in a burst of errors for roughly 5 - 10 seconds every 10 minutes or so...
Interestingly, the problem does not occur when I use other software. For example, I just recorded a file with a signal coming from the same sound card in the same session using Audacity, and I get no errors in 60 minutes.
So: the questions are:
- is anyone else experiencing a similar problem with RME and MSP?
- any thoughts on how to fix this?
Thanks
-geoff
Oops... forgot to mention:
I've tried this with both the fancy USB 3 cable that came with the UFX+, and with a normal old-fashioned USB-B cable that I had lying around. I have not tried it with a Thunderbolt cable - I'd have to buy one first...
However, since Audacity is behaving, I suspect that the problem does not live in the cabling.
Cheers
-geoff
Sounds like a clock problem... Is your UFX the master clock (I like to set it as the master)?
Yes - it's the master clock. I checked that first, since this is a typical mistake (for me, at least..) :-)
Interesting.
Max 8 is supposed to be ready soon ( https://cycling74.com/products/new-max-version-8 ), it will be interesting to see if you still have this behavior with this version.
Agreed. And I will certainly try it. However, a basic problem like this makes me quite concerned. I principally use Max/MSP for testing and measurements of other equipment and systems - which is one of the reasons I went for the high-end sound card. Unfortunately, until I can get this fixed, I'm quite stuck...
Cheers
-geoff
One thing to investigate would be if the glitch happens with different signal or I/O vector sizes...? Looks like you had a 16-sample I/O vector size for the picture? Not easy/fast to test, though.
Hi again,
I tried a bunch of different combinations of I/O and Signal vector sizes. It's the same problem in all cases I tested (although I admittedly did not test all possible combinations...)
It's easy to test - but not fast.. I'm just doing an old-fashioned THD-type measurement. Sending a sine wave into the UFX+'s analogue input, notching that frequency out, and looking for jumps in the level of the remaining signal. Since it takes no more than 5-10 minutes before I get a burst of errors, it doesn't take very long to figure out that it's not working. :-(
Cheers
- geoff
what other apps did you try beside audacity? did you already try other apps using asio/coreaudio?
No... The only other one I've tried is Matlab - but that has known problems with the UFX+ due to the number of available channels, according to those-who-have-tried-before-me...
I'll give it a try with other applications to see if I get similar issues. Thanks for the suggestion!
For the benefit of anyone else with a similar problem to mine:
I made the mistake of coming to Cycling74's page first instead of RME's... Roman's ASIO / CoreAudio pointer was the clue. Turns out that the problem MIGHT be caused by Apple's "Smart Battery Manager" interrupting the ASIO stream... (Audacity uses CoreAudio - not ASIO for commercial reasons as described on this page.)
There's a discussion between persons with similar issues on this page in an RME forum. I'll jump through some of the hoops listed there to see if I can clear things up. More info to come!
Interesting, thanks for the information!
A quick update;
I've done everything described in the page on the RME forum that I linked above. I've tested the system with the following configurations:
1. with the battery manager disabled
2. #1+Bluetooth turned off
3. #2+WiFi turned off
4. #3 ISO mode turned on in the RME control panel
5. #4 with the UFX+ in Class Compliant mode
6. #4 with the UFX+ forced into USB2 mode
7, 8, 9: Repeated #4, #5, & #6 using the USB port on the other side of the MacBook Pro.
In all of the above cases, the same error occurs - albeit at different rates.
The best I've been able to achieve is a continuous run of a little more than 500 seconds before I get a burst of errors. The worst case was 30 seconds (I start timing when I turn on the ADC) however, it could be that these durations-before-error are merely random numbers, unrelated to the configuration. I am not going to do repeated testing to get statistics describing how long I can trust the system. My only interest is whether I can trust it or not - and it seems that, using a USB connection to the UFX+, I can't.
So, now I've completely given up on using USB and purchased a Thunderbolt - to - Thunderbolt cable. I'll run the same tests with that configuration and report back when I have more info ASAP...
As a sidebar, it's fun to read RME's manual for the UFX+, particularly the discussion about USB vs Thunderbolt on pages 115 and 116. It's pretty clearly inferred there that USB cannot be trusted. By comparison, they explicitly state that "Connecting a UFX+ to any Thunderbolt port will just work – period". I'm looking forward to proving that statement to be correct...
Cheers
-geoff
I'm happy to report that I have found the fix to the problem! I'm unhappy to report the fix - partly because it's so simple, and partly because I need the system to work in the configuration that it doesn't...
Preface: I'm now connected via Thunderbolt instead of USB - so I can only confirm that the system behaves as tested... I'll try with USB again in the future.
I was getting the error bursts when my input device was the Fireface UFX+ and my output device was the Mac's Built-in Output. By setting the output device to also be the Fireface UFX+, I have now gone 7800 seconds (over 2 hours) continuously without a detected error (44.1 kHz, I/O and Signal vectors set to 1024 samples)
So, I don't really know who to "blame" - but it seems that there is a clocking conflict (as you originally guessed, Jean-François) between the UFX+ and the Mac.
Unfortunately, I would really like to use the Mac as the output device in some test setups (e.g. as an AirPlay, Chromecast Audio or Bluetooth transmitter) - but I'll call that a secondary problem for now... Maybe some playing around with the "Aggregate Device" option on the Mac could work... that's the next step.
Hope this helps someone else to save some time in the future...
Thanks for the report, this is good to know!
My last report to file:
I've combined the Mac's built-in output, the microphone, and the UFX+ as an Aggregate device in Audio MIDI setup.
If I use that Aggregate Device as the Input Device and the Output Device in Max AND the UFX+ is set to be the Master Clock (in Audio MIDI Setup), then the error occurs.
However, if I use that Aggregate Device as the Input Device and the Output Device in Max AND the Mac Output is set to be the Master Clock (in Audio MIDI Setup), then the error has not occurred after more than 1 hour of continuous testing.
So, it appears that the moral of the story is that, if you must use the UFX+ AND the Mac's output from Max, then you'll need to create an Aggregate Device of the two, and then set the Mac Output as the master clock.
I have not tested this configuration with USB - and I won't... Thunderbolt is working, and I need an excuse that justifies the money I spent on the cable. :-)
Once again, I hope this helps someone else to avoid doing what I've been doing for the past week or so.
Over and out.
Cheers
-geoff
Thanks for the feedback, very interesting. It is still quite impressive how flexible/powerful Aggregate devices are. Also, congrats on all of your dedicated testing!