Topic: UFX3 and Madi clock synchronization

I just want to clarify: ufx3 works without problems. But I need to figure out the input status with MADI. From the Digico SD console, I feed MADI coaxial 96kHz in the 96frame hispeed format, but the UFX perceives it and sees it in the input status as 48kHz and 48frame. But when I switch the SD side to the 96kHz 48frame smux format, the UFX also perceives it as 48/48frame, and if I turn on 96/96 hi speed again, the UFX already perceives it as 96kHz and 96frame, and it works like this until the end of the show. In the specifications on the web link I see an explanation from RME and it only says smux and they don't say hispeed.. But whatever the MADI input status is, whether it's 48/48 or 96/96, the UFX works fine.  If I stay in SD at 96kHz and smux, then RME will never get out of the 48/48 MADI status.. Logically, it turns out that RME reads 96kHz at a frequency of 48kHz? I'm not talking about 48 frames, and only after switching after each turn on does it read it from 96kHz.  And I thought that maybe it was because of the combination of BNS MADI and Wordclock, but the same thing happens when I submitted from bigben 96khz to AES as synchronization, so the AES status says 96khz as clock but the MADI input behaves the same way... Tell me something, representatives of RME... Ramses, I read your explanations about clock in Tonstudio, .. But here's something different.... I could stay in Digiko with 96khz and smux2 as they write in RME, but then I will never see the MADI input status as 96/96, but only as 48/48.

https://rme-audio.de/fireface-ufx-3.html

2 (edited by ramses 2025-09-13 14:18:33)

Re: UFX3 and Madi clock synchronization

Not sure whether I can help. Please detail the setup.

I first need a (visual) overview, connection scheme, how the devices are connected for clock sync and MADI.

URL of product pages and manuals would be useful for non-RME products (Digico, Big Ben).

Which device is clock master? How does the clock distribution work from the master to the slave(s)?
Highlight it in the drawing, thanks.

It sounded as if it would run? What is the exact problem?
Or can you explain the steps what does not work and what the issue/your expectation is?

Please post a screenshot of RME driver settings when devices are set to 96k MADI frame and 96 kHz.
Maybe also when the error occurrs.
If the Digico has smth like a status overview, from that as well please. Thanks.

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent

3 (edited by mmcd 2025-09-13 19:56:34)

Re: UFX3 and Madi clock synchronization

This is not a problem of incorrect settings, this is a question for the programmer of the code for ufx3, Why is the 96khz/96 frame code perceived as 48/48. And only after switching on the SD side from hispeed to smux and then back to hispeed does the RME perceive it as 96/96. True, when I turn on the SD, for two seconds the RME perceives the MADI coaxial as 96/96 and drops to 48/48, then only in manual. My setup is normal: Apogee Big Ben word clock from which WC is distributed to all the necessary devices, digico also gets a separate WC channel, everything works at 96kHz, .  Now even UFX gets a separate WC through aes by bigben, only the fireface usb setting madi input status window shows Coaxial Sync by default 48/48 after switching it shows 96/96... If Digico were to cheat and actually work at 48kHz although it would show 96kHz in the settings, there would be 56 madi channels and not 28,,, What's more, Rme, which in 48/48 indicates 56 madi channels, which in 96/96 are 28. Logically, I assume that 96kHz comes from Digico and Rme calculates that it is 48kHz (but it works). Rme works, passes audio sound. There is no distortion.  Only when it mistakenly thinks that it is 48 kHz (or is programmed to save resources) does it somehow convert it there.... I would not like the 96 kHz signal to be read once at a frequency of 48 kHz, although it works. It is quite problematic to insert photos here on the site, I read how to insert them..

https://www.soundonsound.com/reviews/apogee-big-ben

There's no point in giving any web links about Digico SD, because you have to read a lot.

4 (edited by mmcd 2025-09-13 16:38:50)

Re: UFX3 and Madi clock synchronization

https://fex.net/uk/s/yecb1ba valid 7 day

I just looked at the photo where it says 48/48, the RME says it's 56 channels, but the routing of both TM and LP is 28 channels, so even though the RME shows 48/48/56, it actually works as 96/96/28.         digico sd is routed as 28 channels...
So another card, the madiface PCIe 34 , gets 28/96khz channels ufx3 via fiber and is synchronized to it, after which the ripper records these 28 channels at a frequency of 96 kHz... although the UFX3 will show 48/48/56 until I switch.

5

Re: UFX3 and Madi clock synchronization

I have checked the behaviour of the UFX III in a setup similar to yours (except for the Digico) and could not find any fault. There is no obvious reason why the MADI input status panel in the Settings dialog should not show the simple truth - that the Digico does send 96 kHz MADI as SMUX (48k Frame mode), unless you toggle its state so that it starts to send out the correct format (96k Frame).

Is there any proof that this could not be the case? I did not find such in the above posts. You would need another MADI capable device with status display to verify the signal sent from the Digico is right or wrong.

Regards
Matthias Carstens
RME

Re: UFX3 and Madi clock synchronization

Before buying ufx3, digico worked with madiface that with e34 connection, and worked well at 96kHz, It worked with 96kHz with 48 frame (smux) and in hispeed 96khz 96frame mode.. Now ufx3 also works without problems in smux and in hisped, but the USB settings window shows, when you start digico in the rme window after empty (nothing) for two seconds it shows 96/96/28, and then the rme drops to 48/48/56 and shows like this (photo) ... but everything works fine, and all other devices and even TM are routed to 28 channels, and it's not 56 channels as the rme ufx shows and with a frequency of 48kHz,,,48 kHz is simply impossible, because it would not be synchronized with everything else, the sound would not pass, I know that for sure.  But since the RME itself shows that it perceives it as 48kHz, it probably automatically adjusts and converts and distributes everywhere with a frequency of 96kHz, especially since it also received 96kHz via AES WC... And then I don't change anything in the wiring or routing of anything, but only in the digico window by default hispeed I switch to smux and immediately hispeed then the RME countdown shows 96/96/28 and not 48/48/56... I think that many people with digico do this, but they don't look at the settings later, the sound passes, then it's enough for them, it's happiness for them, I myself accidentally noticed this... the only thing you need somewhere is a digico sd (not quantum) with the latest firmware v2025, ... This is something RME thinks that it is 48/48/56, although the TM itself does not switch to the 56-channel layout,,, because I know how  this, it confuses all the channels in places, but I say that everything works fine, only the RME window shows 48, so it is logical to assume that it somehow converts something again, etc. and maybe the quality, but I didn't notice it, because I didn't check, although it's hard to distinguish 48kHz or 96kHz by ear,... Therefore, whether the reading order is smux frame or hispeed frame, I don't care, but the fact that RME perceives it as 48kHz already worries me, does the quality drop, because otherwise there is no point in 96kHz if somewhere something passes this signal through 48kHz,, It's something similar if you convert an MP3 audio file of 320 kb/s to wav...

Re: UFX3 and Madi clock synchronization

I don't know the algorithm for measuring the input signal of the MADI in the RME, but I logically see that the measurement is based only on Frames, and not on the actual input frequency sample rate. Therefore, when the RME changes the decision after two seconds that it is not 96frame but 48frame, then based on 48frame it logically and not measuredly shows that it is 48kHz and 56ch. Because when I switch to smux (48frame) in the digico window, the RME does not change anything and continues to show 48/48/56, although in fact it is 96/48/28. And only when I turn on the 96frame hispeed in the digico again, only then the RME sees that the frame has changed, and logically decides that it is already 96/96/28... That is, the measurement is based on the frame. Because only the frame changed, but neither the frequency nor the number of channels changed.  In reality, only the programmer of this input code can know how the measurement is carried out and what decisions are based on this.. As In my opinion, it is necessary to introduce another measurement algorithm, and this is for the input frequency, and then based on two parameters, this is frame and khz - decide what kind of input data it is. But why does everything work at least a little? - Because the code algorithm that is responsible for the actual output/output state is well designed, .