You are not logged in. Please login or register.
RME User Forum → Linux → Digiface USB class compliant on Linux
The fresh updated user manuals reveals a surprise for the Linux comunity.
First time a screenshot of a Linux application takes place in the user manual of the Digiface USB on page 30
Good news...
so i hope, the firmware update tool has this CC setting... in my memory, it is just updating without this question.
Good news...
so i hope, the firmware update tool has this CC setting... in my memory, it is just updating without this question.
It is updated 2 weeks ago, the new FUT has this option.
Also take a look at the NEWS page on the RME website.
mmhhh...
have upgraded... but how can i switch to SPDIF now on the Digiface USB? Is it maybe fix to ADAT now?
This is what i can find in the manual:
"How can I use the Digiface USB under Linux?
Flash the Digiface USB into CC mode using the firmware update tool. The default settings for
this CC mode are: Clock Internal, Output ADAT format. The most important setting now is the
Clock Source (Internal, Optical 1-4). This setting can be accessed via the Alsa mixer"
Default settings ADAT means to me: you can change it, but there is no setting in the Mixer to change it.
If you use just the first two channels of an Adat port it is the same as being SPDIF, you can switch sample rate and it keeps working.
The driver setting switch from Adat to SPDIF is redundant.
Oh... this are good news! will try!
But now, where i have updated to newes firmware, i can not go back. It seems, that Flash Tool is not recognizing the Digiface USB in CC mode ;(
Anybody with same problems?
It needs a computer with a working driver.
Try reinstall driver.
What computer is it ? Win or Mac ?
Windows
And the driver version you have installed ?
Driver is installed, and it is the same PC what i have used to update the firmware to cc mode.
But now, when i start the fut.exe i get only the screen all available hardware devices for the update. If i click OK, everything gets closed.
By the way: is it normal, that i can not post a picture/ screenshot?
Driver: driver_madiface_win_09845
ok... updated to newer driver, and i can make the "downgrade" without CC mode 
THX a lot for your help... and sorry for using old driver. I thought its just for madiface, because Digiface USB is not listed on the download instructions
x64 / Arm 64 bit driver for Windows 10 and up, MADIface USB series
Driver for Windows 10 / 11, Intel x64 and Arm, version 1.0.15. Supports Intel Windows 10 or up 64 bit, and Windows 11 Arm systems, with both WDM and ASIO. Updated installer. See readme for details.
Your computer and the FUT should work, I can't see a mistake, I can't test myself because Mac only here.
Screenshot needs to be uploaded to the internet first with a public image service like imgbb or imgur
open the link in your browser
right-click image
copy image-address
paste image-address between img tags in the forum post
direct upload of image into the forum is not possible
mmmhhhh
I am trying to use the Digiface on a raspberryPi with camillaDSP. It was allready running without cc- mode, but after some time (minutes or days) i get crackling sound and distortions like phasing.
So i hoped, that in cc-mode it will get better, but i don't get any Sound out of it on camillaDSP with cc-mode
Now, with new Firmware and without cc-mode, maybe distortions are gone... we will see
In Bitwig on Arch I am only able to see 16/16 io with Digiface USB CC mode. Ableton Push 3 standalone does not recognize it at all. Am I doing something wrong? Is there more than just flashing the CC firmware?
Doublechecked: the ALSA driver mode shows 34 channels, presumable 32/34 IO, and the last pair as the headphones. Just Jack does not show everything.
In Bitwig on Arch I am only able to see 16/16 io with Digiface USB CC mode. Ableton Push 3 standalone does not recognize it at all. Am I doing something wrong? Is there more than just flashing the CC firmware?
Doublechecked: the ALSA driver mode shows 34 channels, presumable 32/34 IO, and the last pair as the headphones. Just Jack does not show everything.
The count of IOs depends on sampling frequency. I am using 96kHz and so I have 16 inputs, 18 Outputs (16 for ADAT and 2 for the Headphone)
ok... updated to newer driver, and i can make the "downgrade" without CC mode
THX a lot for your help... and sorry for using old driver. I thought its just for madiface, because Digiface USB is not listed on the download instructions
x64 / Arm 64 bit driver for Windows 10 and up, MADIface USB series
Driver for Windows 10 / 11, Intel x64 and Arm, version 1.0.15. Supports Intel Windows 10 or up 64 bit, and Windows 11 Arm systems, with both WDM and ASIO. Updated installer. See readme for details.
It says MADIface USB series, and the Digiface USB is part of that series.
I know this can be a bit confusing, but developed historically and can not be changed anymore.
Can the Digiface USB be used/configured in CC mode as a SPDIF 2-channels in - SPDIF 8 channels out device using the optical Toslink connectors?
Would this configuration work in all MUX cases - SingleSpeed/44.1/48 - DoubleSpeed/88.2/96 - QuadSpeed/176.4/192?
If such a setup would work, then the Digiface USB might be used as a digital stereo 4-way loudspeaker crossover.
In this usecase
- 4 x SPDIF DACs would be connected to the outputs of the Difigace USB, each sync'ed by the (synchronous) 4 SPDIF streams.
- DSP would be performed by a small Linux host interfacing by USB.
THIS WOULD BE GREAT !!!
Nota bene ADAT is of no interest for this SPDIF-only application.
Can the Digiface USB be used/configured in CC mode as a SPDIF 2-channels in - SPDIF 8 channels out device using the optical Toslink connectors?
No, the connectors are inputs or outputs they can not change.
It is 4 input and 4 output.
In CC-mode all are Adat.
Thank you for the quick and clear answer.
So then, CC does in fact cripple the Digiface USB. No SPDIF at all while running in CC mode ... ??? Is that for technical, or for other reasons? Other reasons in terms of product placement strategy and the like?
I am heavily disappointed, having hoped that a long-awaited CC mode might instead enhance the versatility of the Digiface USB. As mentioned before in my first post, e.g. by allowing for 1 (or even up to 4) SPDIF == 2ch in and 4 SPDIF == 8ch out.
In the end and as is, it becomes quite clear that the Digiface USB is no hardware option for speaker builders wanting to set up multiway DSP xover solutions.
Just not in CC-mode
It is a computer audio interface, use it with a computer that works.
Just not in CC-mode
May I ask for tech interest why SPDIF is not supported in CC mode?
Use the first two of the 8 channels, voila stereo digital.
You can see Adat as an advanced SPDIF, one SPDIF plus additional channels depending on sample rate setting.
Use the first two of the 8 channels, voila stereo digital.
You can see Adat as an advanced SPDIF, one SPDIF plus additional channels depending on sample rate setting.
ADAT and SPDIF formats are not compatible, you can not feed ADAT into a device that only understands SPDIF.
As for switching, one screenshot seems to suggest that it's possible, but I must admit I'm not sure and I don't have a suitable Linux system to try it out.
ADAT and SPDIF formats are not compatible, you can not feed ADAT into a device that only understands SPDIF.
Then the RME ADI-2 is an exception.
From there I thought it is normal, optical inputs reading SPDIF or Adat 1/2
Thanks for clearing this up.
User may just test the inputs, there is no danger, either it works or not.
Is someone here able n this forum to answer these two very basic questions in a competent way:
- Is the Digiface USB in CC mode able to simultaneously receive an optical (ch1,2) SPDIF input while sending out an optical (dh1,2) SPDIF output?
- If so, then up to which SPDIF sampling rate?
Yes sample rate up to 192 kHz
Yes input and output at the same time Adat or SPDIF if you can configure this, I don't know.
May I have this also confirmed by an official RME Support voice?
SPDIF in / out at SR 192kHz in CC mode?
Then the RME ADI-2 is an exception.
From there I thought it is normal, optical inputs reading SPDIF or Adat 1/2
Thanks for clearing this up.
Not really an exception, it can read both formats, like many other RME devices, where at least one input can either be manually switched or automatically detects the format. But AV receivers, Hifi DACs or similar devices do not accept ADAT format, regardless of the number of channels.
CC mode: the Digiface USB will accept both ADAT and SPDIF at its inputs as that is done automatically in hardware, per input. The outputs are set to ADAT as default.
There is no routing from input to output (no TotalMix), that has to be done in the DAW.
Can the Digiface USB be used/configured in CC mode as a SPDIF 2-channels in - SPDIF 8 channels out device using the optical Toslink connectors?
No SPDIF out at this time.
Would this configuration work in all MUX cases
SPDIF does not use 'MUX' at all. So if the output format would be changed and some app routes one input to all outputs then it would work.
daihedz wrote:Can the Digiface USB be used/configured in CC mode as a SPDIF 2-channels in - SPDIF 8 channels out device using the optical Toslink connectors?
No SPDIF out at this time.
daihedz wrote:Would this configuration work in all MUX cases
SPDIF does not use 'MUX' at all. So if the output format would be changed and some app routes one input to all outputs then it would work.
No SPDIF at this time… is there any plan to get it later?
And maybe you should change the user manual and add, that there is no way to switch the output to SPDIF. To me, „is set by default die ADAT“ implements, that it can be switched to SPDIF.
My conclusion of this 30-post-thread:
- Digiface USB in CC mode allows ch 1,2 SPDIF-in, but no SPDIF out. SPDIF out never will be.
Comment/Rationale: "No SPDIF out at this time", as M.Carstens writes, shall realistically be interpreted as "No SPDIF out". Otherwise RME would have certainly also implemented SPDIF out while designing the CC mode firmware. Because there simply is no reason to implement SPDIF in, but not SPDIF out when designing software meant to expand functionality. Unless the designer suffers from a severe neglect.
And I join criss0212 with his call for transparency concerning the user manual. Calling No SPDIF as "default ADAT" simply is a no go. RME has lost two points of credibility in doing so, at least for me.
The difference you overlook is that at the input, the receiver can automatically detect the signal format in hardware or the firmware and pass it on to the computer or other device. As for the output format, you as user need to decide what you want and then you need a way to actively change it. Since there is no hardware switch, this will have to happen in software. But there is nothing that's comparable to the USB settings dialog... Apparently, there is also no existing Linux application that can access this setting at this time. We'll have to see if and when that changes. I'm fairly sure that this is not an issue of the firmware itself lacking the capability.
Thank you for your anwer
Then why not releasing two versions of your CC firmware? The one "defaulting" ADAT out, the other one "defaulting" SPDiF out?
And regarding you post No. 23 ... please ... set up a Linux testbed at RME. It will make you look more credible while answering to posts in the Linux part of the forum.
Flashing firmware just to switch format seems a tad overdone. And if you want to find out whether Alsamixer can somehow get access to this setting, perhaps contact Alsa and see what is possible or perhaps upcoming.
Objection. You missed the point. Either someone is in an ADAT world, or then in an SPDIF world. You will not change ADAT vs. SPDIF vs. ADAT v.s SPDIF ... setup like your pair of socks. Furthermore, your statement is in contradiction to the whole CC option. It is RME which advocates flashing between "Regular" and "CC" mode. So you make RME's approach itself "tad doverdone". Where is your logic ???
Nevertheless, I quit. Ist mir zu doof.
Not the same, obviously... Some people may even want to use both formats...
... so CC might provide SPDIF out also. Explicitly for all these dual format users. And it's RME who might make the effort. Not Linux/ALSA, not Android, nobody but RME.
Bye, this time for good.
You didn't read what I said. Changing the format requires software access. There is no suitable control software, or at least none that supports this. Don't misinterpret everything I say....
I did read what you said, and I was quite disappointed about what I read. In post 34 I suggested an alternative CC approach which would provide SPDIF in-out right of the box, not needing any further control software. I would have expected a technical comment.
Maybe let's better M.Carsten comment on tech options for making SPDIF in - SPDIF out possible. I mean SPDIF in-out in CC mode, without any need to wait for others than RME to provide this modus.
Even if there are only a few users who regularly want to switch between SPDIF and ADAT… wouldn’t it be better to have a somewhat cumbersome solution for them than no solution at all?
I honestly can’t follow the logic that’s being applied here.
On top of that, the user manual is written in a way that almost gives the impression it’s meant to be misunderstood.
I was trying to point out that switching the output is not as simple as just having the automatic detection at the input — and that I don't expect that a solution with separate firmware is likely to be considered a good idea by the developers. If you are working in an environment that requires CC, the last thing you want to do is find a PC with the driver just to change the output format. "At this time" also seems to indicate that a solution is technically possible at some point.
Either someone is in an ADAT world, or then in an SPDIF world.
Maybe let's better M.Carsten comment on tech options
Only thought comes to mind, this must be a troll or new generation Ai robot
Thank you for attesting some intelligence to my posts. Two things:
1. You are wrong. I am not an AI robot. As an answer to your post you may read me here sincerely saying "Hey, waedi mi liebe, chumm obenabe, bissoguet" and then decide if you change your interpretetions or not about AI generated of not. I guess AI will be up to such kind of answers within 5 years or so. But not yet nowadays.
2. You are right, I understand your misunderstanding. Maybe I should have introduced myself and my motifs before asking about SPDIF and the Digiface USB CC mode. I will now: I am a hardware tinkerer and having fun with nice nifty projects. The Digiface USB has long been one of my favourites to be included in such a project along a Raspberry PI and a cluster of 4 SPDIF-in DACs, the Digiface being controlled by a raspberry Pi running Linux. Do you copy now why I was excited when I read about CC mode for the Digiface USB? If so, then you might also understand why I was interested to have some valuable and trustful tech infos about it's SPDIF in-out. I am new here, ok, but I am used to stroll around at the diyaudio.com forum (under the same alias Daihedz), where I am used to high-value tech infos given there, e.g. by phofman in the CamillaDSP thread. I hoped to meet the same competence here. Regarding my audio past, I formerly set up quite a bit of LS setups along with different RME products and always running Linux. These setups did run perfectly well. So no need for me to be rembered to use a "comupter that work" as you did in your post no. 20. By the way, this very post of yours might reflect your own trolling momentum. Is this further info apt to convince you that I am neither an AI bot, nor interested in trolling?
This much for your understanding of my pertinence. Mabe, maybe not, it will not change the world's fate. Anyway and basically, your thread has answered my questions I had concerning the CC mode: Nope for this one project. This CC mode does not work for me. So thank you for your thread, also.
The Digiface USB's four outputs can be switched to ADAT or SPDIF even in CC mode, but that needs some special commands, talking to a special interface. But that's quite easy to do. Here is a demo program that does this. Calling
./usb_vendor 1 0 0 0
will set ADAT1 out to SPDIF format and ADAT2 to 4 out to ADAT format See code:
#include <stdio.h>
#include <libusb-1.0/libusb.h>
#define VID 0x2a39 // Vendor ID RME
#define PID 0x3fb2 // Product ID Digiface USB class-compliant
// control register Digiface USB
#define DFUSB_SPDIFOUT0 0x00000001
#define DFUSB_SPDIFOUT1 0x00000002
#define DFUSB_SPDIFOUT2 0x00000008
#define DFUSB_SPDIFOUT3 0x00000010
#define USB_REQUEST_SET_CONTROL_REG2_MFXT 18
int main(int argc, char** argv)
{
libusb_device_handle *handle;
int r, i;
uint16_t control2, mask2;
int spdifOut[4] = {0, 0, 0, 0};
if (argc >= 2 && argc <= 5) {
for (i = 1 ; i < argc; i++) {
if (argv[i][0] == '1')
spdifOut[i-1] = 1;
}
}
r = libusb_init(NULL);
if (r < 0)
return r;
handle = libusb_open_device_with_vid_pid(NULL, VID, PID);
if (!handle) {
printf("Device not found\n");
libusb_exit(NULL);
return 1;
}
control2 = 0;
if (spdifOut[0]) control2 |= DFUSB_SPDIFOUT0;
if (spdifOut[1]) control2 |= DFUSB_SPDIFOUT1;
if (spdifOut[2]) control2 |= DFUSB_SPDIFOUT2;
if (spdifOut[3]) control2 |= DFUSB_SPDIFOUT3;
mask2 = DFUSB_SPDIFOUT0 + DFUSB_SPDIFOUT1 + DFUSB_SPDIFOUT2 + DFUSB_SPDIFOUT3;
r = libusb_control_transfer(
handle,
LIBUSB_REQUEST_TYPE_VENDOR | LIBUSB_RECIPIENT_DEVICE | LIBUSB_ENDPOINT_OUT,
USB_REQUEST_SET_CONTROL_REG2_MFXT, // bRequest
control2, // wValue
mask2, // wIndex
NULL, // data
0, // wLength
1000 // Timeout ms
);
if (r < 0) {
printf("Vendor OUT failed: %s\n", libusb_error_name(r));
}
libusb_exit(NULL);
return 0;
}In case opening the USB device does not work you might have a rights issue. Try a test with "sudo ./usb_vendor ..." to check.
Download the above as text file: https://www.rme-audio.de/downloads/usb_vendor_c.zip
As a Linux user you know how to compile this into an app.
Thank you. It might be useful to include this info into the CC section of the Digiface USB manual.
@ M.Carstens:
Sorry ... An additional and important info is still missing for me:
Is a SR of 192kHz allowed even if all 4 SPDIF out are enabled in CC mode by ./usb_vendor 1 1 1 1 ?
or
4 or 3 SPDIF outs allow a max. SR=48kHz,
2 SPDIF out allow a max. SR=96kHz,
1 SPDIF out allows a max. SR=192kHz?
Also this aspect might be included into the CC manual infos.
read me here sincerely saying "Hey, waedi mi liebe, chumm obenabe, bissoguet
You are right, apologize, danke das mir nöd bös bisch.
Scho guet :-)
Swiss or austria?
RME User Forum → Linux → Digiface USB class compliant on Linux
Powered by PunBB, supported by Informer Technologies, Inc.