Fireface UCX support #16
Comments
|
As the readme states: Only UCX II is supported. What (probably means) the registers also differ... So, you would have to capture the traffic, have look in the other units issues and the wiki, especially protocol and capture. |
|
I tried to compile so that it would look for "Fireface UCX" instead of "Fireface UCX II" in oscmix and the web frontend. Turns out things are a little bit more complicated 😂 |
|
As the UCX and UCX II should be quite similar... Before trying the capturing traffic thing, maybe an idea would be to check first, if the basic register addresses work with your UCX, too. I mean as described in the wiki protocol page (which is for UCX II). if you did not compile it yet, you can compile it via: Then run: If this works, it could be an indicator that your UCX registers are quite similar to these from the UCXII. |
|
With a bit of guessing I found |
|
Interesting. Then it looks like the register address scheme is based more similar like (my) Fireface 802 (see the wiki). When listening USB traffic using TotalMix on macOS or Windows - your unit will have to use USB mode (instead of cc) to be able to communicate with the mac/win App. You could use and modify the lua script dissector and add your product id (see tools folder) for use with wireshark... but this way is a bit more complicated to get the registers. You have to be quite savvy with wireshark in general. A more easier way would be if you have an ipad (and use your unit in cc mode), while capturing as described in the wiki (possible via a rpi4 or rpiPico W). Anyhow - getting the registers is just the first step. The next step would be to add the code for your device (device_ffucx.c). See the "generic" branch how michael (and me) tried to include this. You can also check my fork of this repo. Here i addad my 802 (which is still in wip state, due lack of time - but basically works). Feel free to ask here - i will try to do my best if i can help. |
|
Ok I understand and I'm willing to try. I need to borrow most of these things, but it might happen soon. The capture wiki section looks also straightforward. Thank you! |
|
I got my hands on a rpi4 and an USB-C iPad. I modified the script so that it corresponds to my Fireface UCX in cc mode. I have the impression the pi is detected by default as an Ethernet device. I've been trying to change |
|
You do have to enable the UDC by setting I think there must be something in your OS setup auto-enabling the ethernet gadget that is using the UDC. Can you show your |
|
You are right, I pasted inside As for My friend will bring her ipad on new year's eve, it will be a fantastic opportunity to test again while being half drunk and surrounded with a lot of noise |
|
I'm interested in helping with this. I don't have an iPad nor a Raspberry Pi but I am willing to have a go at Wireshark, although I have just installed it for the first time. I was able to get it to peek USB traffic on my macOS laptop:
There are packages constantly flowing around but I suspect that the relevant ones are the smaller ones with 40 bytes, sent from 'host' to '20.2.5'. How can I be sure? Do the lua scripts also support the RME USB packets or only the CC ones? |
TotalMix on Windows and macOS use a different protocol (the "USB" mode) than the iPad app and oscmix (the "CC" mode), but I suspect there are enough similarities in the address space to get started.
At least for the UCX II, the most relevant packets were those sent and received on bulk endpoints 12 and 13. The basics are described in
The To start, you could try adding the USB IDs for your device to https://github.com/michaelforney/oscmix/blob/main/tools/rme.lua#L455, setting up wireshark to filter out the addresses that you're not interested in (the ones you see going back and forth when you're not doing anything), and then you can observe what gets sent when you change specific controls in TotalMix. Once you identify a particular register address and value format for some control, you could document it in the wiki in a new page for the UCX. I suspect there will be a lot of similarities with the UCX II, which is currently documented in the "Protocol" page in the wiki. |
|
On my side, the pi4 was correctly recognized as a Fireface UCX by Totalmix. Sadly I'm struggling to find an USB-C iPad I could borrow for more than a few minutes and actually capture sysex traffic. I continue looking around |
|
I changed the rme.lua script like so, around like 453: Then I added it to my personal Wireshark plugins folder but I don't think it is doing much. I am now using TShark (command line for Wireshark) on my Windows 11 like so: It seems that the 12 destination endpoint is where writes happen. I tried toggling the 48V on Mic 1 and it doesn't look obvious to me where the change is happening. I am attaching a dump log of packet dissections without the Lua script loaded, but with filter
The fader packets are the longer ones but I can't really find anything interesting on the 48V. I'm not savvy with Lua, but I might be able to progress if I can get at least something working. |
One quirk I seem to remember is that the usb.product dissector table doesn't work unless it saw the USB descriptors when the device was plugged in. You might try the same thing, but make sure wireshark is capturing when you first connect the UCX.
That's good to observe the differences. I'm guessing the 48v is either filtered out or hidden in the noise. I also suspect that you notice the packet size difference when you use the fader since it adjusts several parameters at once (mic 1 level for output left and right channel). Once you get the rme dissector working, you should be able to filter out addresses specifically using
Thanks. It's hard for me to make sense of the hex dump. Are these the full USB packets, or just the data payloads on endpoints 12/13? Could you do that same test again, but this time save the pcap file so that I could load it into wireshark myself? |
|
I tried again by starting wireshark capture before switching on the UCX but I don't see differences. I am attaching a pcap with the same test from last time and another where I only turn the UCX on and off. |
Yes, that should be how it works. I took a look at your capture and noticed that your device's USB IDs differ from @tempete99's (2a39:3fc9 vs 0424:3fb9, see idVendor/idProduct in packet number 26 in your I updated rme.lua to include 2a39:3fc9, which worked for me to get the RME dissector working. I also noticed that rme.lua wasn't compatible with the latest version of lua, so I fixed that as well.
This looks good. Here's the filter I used to filter out the noise: 
It looks like 0008 is Mic 1 48v, and 14e0 is the mixer for Mic 1 to whatever output you were on. Later on, I see you also adjusted some parameter 14a0. Perhaps the mixer for a different output? It only had one value at a time instead of the two for 14e0, so perhaps a mono channel? Try fiddling around with the controls and build up a mapping of control to register address and value format. |
|
I am doing some slight sanity checking before I dive deep into the map. Sometimes I get a Lua Error on the call to
This happens only when I move faders. The error goes away if I remove the call to Previously, you mentioned that several values are written at once. Sometimes changing the fader on mono channels shows packets with 3 addresses (the first 2 being the same).
Here is the same fader moved after restarting as above and without the call to
I'm suspecting something is a bit off in the dissection process. Maybe packet parsing needs to be different for the UCX? |
|
I had some more time to fiddle with this.
It looks like |
|
Ok, I think I was misinterpreting some of the input controls on TotalMix (I don't use the hardware inputs that much). Some of the toggles write more registers because of the way the channels are grouped together. Also, some controls don't generate packets either because of the current signal gain/routing settings. Still, sometimes Wireshark misses a packet here and there, but most of the times it catches it upon retrying. I also noticed that some of the bytes change between the raw packet data and the register field. It looks like this is because of the bitwise AND with 0x7fff on line 429. This explains why some the 0x9xxx were turning into 0x1xxx, etc. I will try to find some quiet time over the weekend to write a first attempt at the UCX register map. |
|
Sounds like you are making good progress!
Ah, yeah. I think that the mixer (levels, pan, mute) is one of the harder things to figure out since it sometimes involves several registers, or repeated writes to the same register. What I ended up doing is starting with one mono input routed to one mono output (and -inf on all other outputs), making sense of that, then going from there.
My understanding is that the solo function is purely a TotalMix construct. At the device level, it's just muting the other channels. So if no other input is active, nothing needs to be done.
I think this is due to the packet filtering we're applying and the ones getting "skipped" getting written in the same USB packet that we're filtering out. I'm not sure if there's a better way to structure the dissector, but the rme.register and rme.value fields are lists, and the You could try something like
This is expected. The high bit is a parity for the whole address and value. When you see 0x9xxx vs 0x1xxx, that just means there are an even number of bits set in the 1xxx and yyyy (value). See the example here:
Cool, sounds good.
This is another Lua compatibility thing. 5.3+ use But anyway, this is just for nice presentation of the registers/values specific to the UCX II. For the UCX, it's probably just misleading. My suggestion is to comment out Lines 434 to 452 in fc5a085 then build up from what you observe on your device.
I think it is right. My guess is that this is TotalMix uploading its state to the device. This is probably useful as a progress meter. If your dissector can make sense of that whole packet, then you probably have a pretty complete mapping of the address space. BTW, it is more helpful to me if you send pcaps instead of screenshots, since I can't scroll around or expand fields in screenshots.
I've seen things like this before. For example, the UCX II uses address 2000 for both for setting the device LCD UI's input 1 -> output 1 volume and pan fields, depending on the high bit of the value. For example, 8010 means set pan to 16 right, but 7FC4 means set volume to -6.0dB. Probably not the exact same thing here, but see if you can figure out any pattern with the values when one address is written multiple times at once. |
|
I think this might the whole map: I tried to follow the same naming conventions as in the wiki page for the UCX II so it makes things easier when writing an eventual, dedicated UCX wiki page. Some of the controls do not exactly follow a linear map. Other controls do steps of +/-5 (meaning +/-0.5 dB). Frequency settings do 1 Hz steps from 20 Hz to 200 Hz, then in 10 Hz steps from 200 Hz to 2000 Hz, then it's 100 Hz steps up to 20000 Hz. I might be missing some details here and there. What's the next step? |
Nice work! Thanks for doing this.
To clarify, you are talking about the TotalMix UI, right, not the 16-bit value format? I assume this is just for the UI to make adjusting values easier depending on the unit.
It looks good to me, but one thing we're missing is the mixer functionality. Try routing a mono input to a mono output, making sure that input is set to -inf on all other outputs. Then set the volume to various values like 0dB, -3dB -6dB, -12dB, -18dB. My expectation is that the value format is something like the "Decibel to register value" formula in https://github.com/michaelforney/oscmix/wiki/Protocol#mixer-volume-formulas. So for 0dB -> 0x8100, -3dB -> ~0x8B53, -6dB -> ~0x8805, -12dB -> ~0x2027, -18dB -> ~ 0x101D Another thing which we need to figure out is how to dump the device state. It seems to vary from device to device, but usually, when TotalMix starts up, it writes a particular value to some address causing the device to dump its state. TotalMix can then compare this state to its last known state, and if it differs, prompt the user to choose which they want to use. Do you see anything like this in your packet capture? Look for any packets with a large number of registers sent from the device to the host. If you find this, then look just earlier for what the host sent to the device that looks unique.
You could try confirming whether that all this translates to the CC mode as well using Put your device in CC mode, then try running Another thing you could try is running |
Hello !
I've been trying to make oscmixer work with a Fireface UCX (first generation, latest firmware), unfortunately with no success.
Here is what I get when I run lsusb on it:
aconnect -lshows 3 MIDI ports. Only the 3rd one shows SysEx activity.Running
aseqdump -p 20:2I get mostly a repetition of :20:2 System exclusive F0 00 20 0D 10 00 00 34 00 78 03 F7And sometimes some of these messages as aseqdump starts :
I'm not sure I'll be able to make this work as I'm mostly musician and only fiddling with computers occasionally. But it would be great to be able to control this interface when it's on class compliant mode ! Fingers crossed, if anyone has time to help 🤞
The text was updated successfully, but these errors were encountered: