I am able to use the analogue outputs on the UMC1820 with camilladsp (on linux), but nothing seems to get through on either the electrical spdif or the optical toslink. Using an alsa loopback works fine to get audio to the UMC1820, but I really want to drive camilladsp with input from another computer, not the one running camilladsp.
The number of channels for analogue output also seems to vary, having worked with 8 channels, 10 channels and even 12 channels . Can't remember what the circumstances were at the time.
My current conclusion on this issue is that UMC1820 simply does not work properly with camilladsp / linux. Prior to this, I was using brutefir, mainly with other cards, but also with the UMC1820 - it fairs no better.
If someone could show me a config.yaml that will work to access the UMC1820 I would be very grateful. I have wasted literally weeks on trial and error tests.
None of these issues are helped by the complete lack of any detailed tutorials or instructions concerning any linux software. The instructions, such as they are, are always incomplete and seem to assume you are an expert in everything that the instructions do not cover.
Many thanks,
The number of channels for analogue output also seems to vary, having worked with 8 channels, 10 channels and even 12 channels . Can't remember what the circumstances were at the time.
My current conclusion on this issue is that UMC1820 simply does not work properly with camilladsp / linux. Prior to this, I was using brutefir, mainly with other cards, but also with the UMC1820 - it fairs no better.
If someone could show me a config.yaml that will work to access the UMC1820 I would be very grateful. I have wasted literally weeks on trial and error tests.
None of these issues are helped by the complete lack of any detailed tutorials or instructions concerning any linux software. The instructions, such as they are, are always incomplete and seem to assume you are an expert in everything that the instructions do not cover.
Many thanks,
Looking at the back panel, it says that spdif input is number 9 & 10. That would be 8 & 9 in camilladsp since it starts numbering from zero. Did you try capturing from those channels?
This device has adat, and that usually means that the total number of channels depends on sample rate. You can use aplay and arecord to help figuring out what to use, see the readme here: https://github.com/HEnquist/camilla...md#find-valid-playback-and-capture-parameters
This device has adat, and that usually means that the total number of channels depends on sample rate. You can use aplay and arecord to help figuring out what to use, see the readme here: https://github.com/HEnquist/camilla...md#find-valid-playback-and-capture-parameters
According to the manual and my experiences using these interfaces, the UMC1820 can be put into two different modes and this changes what happens with the optical (TOSLINK) and coax SPDIF inputs and outputs on the rear panel. The two modes are:
1. SPDIF MODE: there are 10 analog output channels plus 2 SPDIF outputs (channels 11 and 12) via both the TOSLINK and coax connector. Coax SPDIF input is disabled.
2. ADAT MODE: there are 10 analog output channels plus up to 8 ADAT channels via the optical connectors (at 44.1 and 48kHz). In this mode only the coax SPDIF output (and inputs) function. Channel assignments for these depend on sample rate.
These two modes are switched on the front panel, not from the software/driver side. See the manual for more info.
See page 12, item 13 of the user guide for info on how to switch modes and for details on the sample rate dependencies that I mentioned above. Changing modes is done using the small button labeled "OPT I/O" just below the phones level knob on the front panel. DO NOT change the setting while the unit is in opration - it reboots and this may include one or more loud pops on the outputs.
1. SPDIF MODE: there are 10 analog output channels plus 2 SPDIF outputs (channels 11 and 12) via both the TOSLINK and coax connector. Coax SPDIF input is disabled.
2. ADAT MODE: there are 10 analog output channels plus up to 8 ADAT channels via the optical connectors (at 44.1 and 48kHz). In this mode only the coax SPDIF output (and inputs) function. Channel assignments for these depend on sample rate.
These two modes are switched on the front panel, not from the software/driver side. See the manual for more info.
See page 12, item 13 of the user guide for info on how to switch modes and for details on the sample rate dependencies that I mentioned above. Changing modes is done using the small button labeled "OPT I/O" just below the phones level knob on the front panel. DO NOT change the setting while the unit is in opration - it reboots and this may include one or more loud pops on the outputs.
I use the 1820 and it works great, including optical and coax digital input.
Not at the same time though, both are input 8 and 9 like Hendrik says and you switch between them with a physical switch like Charlie says. Don't have it in front of me but it's near the headphone outputs, and the only button with a lighter grey box behind it.
Not at the same time though, both are input 8 and 9 like Hendrik says and you switch between them with a physical switch like Charlie says. Don't have it in front of me but it's near the headphone outputs, and the only button with a lighter grey box behind it.
Thanks for the help. YES - that works fine.
Although I still have many other problems.
1/. I set the sample rate for camilladsp at 96Khz but supplied a 44.1Khz sample rate signal, the result was a mangled signal but still recognizable as the source material. I tried changing the filter files (from rePhase) from 96Khz to 44.1Khz and that fixed that problem, yet I had supplied a "resampler" directive in the camilladsp config file - wondering why this did not seem to work.
CONFIG FILE: (
devices:
samplerate: 96000
resampler:
type: AsyncSinc
profile: Balanced
enable_rate_adjust: true ).
I tried with and without the "enable_rate_adjust: true" but that made no difference. I believe it should not be there. Not sure what you have to do to get reampling to work. The tutorial does not seem to indicate that anything else must be done.
2/. Both my references to (capture and output) the UMC1820 card are in the form of "plughw:UMC1820". If I take out either or both of the "plug" prefixes out and just use "hw:UMC1820" I get a message saying "Capture error: ALSA function "snd_pcm_open" failed with "No such file or directory (2)".
Any help very much appreciated.
Although I still have many other problems.
1/. I set the sample rate for camilladsp at 96Khz but supplied a 44.1Khz sample rate signal, the result was a mangled signal but still recognizable as the source material. I tried changing the filter files (from rePhase) from 96Khz to 44.1Khz and that fixed that problem, yet I had supplied a "resampler" directive in the camilladsp config file - wondering why this did not seem to work.
CONFIG FILE: (
devices:
samplerate: 96000
resampler:
type: AsyncSinc
profile: Balanced
enable_rate_adjust: true ).
I tried with and without the "enable_rate_adjust: true" but that made no difference. I believe it should not be there. Not sure what you have to do to get reampling to work. The tutorial does not seem to indicate that anything else must be done.
2/. Both my references to (capture and output) the UMC1820 card are in the form of "plughw:UMC1820". If I take out either or both of the "plug" prefixes out and just use "hw:UMC1820" I get a message saying "Capture error: ALSA function "snd_pcm_open" failed with "No such file or directory (2)".
Any help very much appreciated.
@maglevrabbit Every audio interface that I am familiar with does not detect (natively at least) the sample rate of an SPDIF input. You have to know that in advance, and then the entire interface must run at that rate. There is no onboard ASRC. That has nothing to do with CamillaDSP, but rather the problem is that the interface thinks the bitstream coming in is at the rate that you set it to (96kHz) when actually it is at another rate. This sort of "wrong" interpretation of a digital audio bitstream cannot be "fixed" by any software later on down the chain, not ALSA and not CDSP.
Just wanted to add... I have faced a similar problem in the past with my own DSP app (GSASysCon), although it is not really app dependent. I use GSASysCon and a computer as a preamp for an audio system. There are analog inputs and digital inputs (CD player and digital radio but I want to run my DSP processing and the output audio interface at 96kHz. To get around this, I bought an additional digital to USB interface to handle the CD and radio at 44.1k Hz. The main audio interface is run at 96kHz for analog inputs and analog outputs. GSASysCon does sample rate conversion when there is a digital source playing. This costs more (I had to buy an additional digital audio interface) but it works great.
How does the UMC behave when fed spdif input at a different rate than the one it expects? For example what is the result of recording with the UMC set to 44.1kHz and feeding it with a 96 kHz spdif signal? And with the opposite, set to 96 kHz and fed with 44.1?
If it handles both cases well, it might be possible to switch the camilladsp config automatically with a little scripting.
If it handles both cases well, it might be possible to switch the camilladsp config automatically with a little scripting.
@HenrikEnquist Hmmm, I don't follow you above. If the interface is set to accept 96kHz digital audio in SPDIF format it expects the frame to arrive in that format and data at that bit rate. So I assume that when you instead send some other rate like 44.1k Hz the interface will dutifully apply the 96kHz decoding and the resulting audio data will be "wrong" e.g. possibly noise plus some hints of the original signal. For example, from earlier in this thread:
I do not think that some sort of "recovery" of the original signal in software after this has happened is possible, do you?
I do not think that some sort of "recovery" of the original signal in software after this has happened is possible, do you?
It depends on the device. Many (probably most) behave as you describe. But some devices are able to correctly record an spdif signal that has a lower sample rate than the device is set to. When this happens, the client simply gets data at a lower rate than expected. CamillaDSP measures the rate and can stop when this happens. I'm not aware of any device that can capture at a higher rate than it's configured for.
There are many devices which have no support for detecting the incoming samplerate (basically all I2S-slave interfaces, majority of SPDIF receiver implementations). Samperate is a required part of the open-device call, hence something must be used. Such device will fetch data to the alsa client at whatever pace it receives them, regardless the actual rate requested at hw params. There is not much else to do. Of course if a complex client expects some absolute samplerate (like CDSP does as it uses timers for some sleeps), issues arise. But normal capture will just create a file with incorrectly marked samplerate.
There are some (few) devices with HW/driver support for monitoring the incoming samplerate and they limit the hw_params rate options for the client to use, even close the current stream (even playback stream if the whole device is switched to the external clock) if running at incorrect frequency after new one arrives at the receiver. THen there are device which do nothing to the stream, but at least report the current samplerate via some side channel (alsa ctls etc.)
There are some (few) devices with HW/driver support for monitoring the incoming samplerate and they limit the hw_params rate options for the client to use, even close the current stream (even playback stream if the whole device is switched to the external clock) if running at incorrect frequency after new one arrives at the receiver. THen there are device which do nothing to the stream, but at least report the current samplerate via some side channel (alsa ctls etc.)
Thanks for all the help, but I am giving up on this - it's simply too hard and wastes too much time. Trying to string various bits of hardware together with bits of software, all of which are essentially "black boxes", where you cannot tell what is going on inside, is a nightmare. If I source my spdif output from a PC running JRiver Media Center, and I tell it to send spdif digital output at 96000hz, I have no idea if it actually is doing that. The sound card won't tell me. I do know that when i send spdif output at either 44,100 hz from Jriver MC via a creative GC7 sound card, into my Yamaha amplifiers Toslink input, it sounds fine. If i then fire up Camilladsp configured to accept a toslink input at 96000hz, i get no output whatsoever - complete silence. The only time I got any output from an spdif hookup was when I sent it from an MP3 player (FIIO X5), which I guess was at 441000hz. . Sound from the tweeter and the midrange of my active speakers (sourced from Camilladsp) sounded fine, but the woofer output bottomed out my Yamaha sub-woofer with it's volume at a minimum, suggesting to me a low frequency square wave.
What I really need for this kind of setup is a sound card with hardware buttons on it to set the sampling rate, and a display to confirm the output is at that sampling rate. I don't currently have one, and doubt there is such a device for sale.
My current opinion is that the Linux sound architecture is an abomination of bits and pieces (OSS, ALSA, Pulseaudio, Pipewire) none of which are particularly good. I'm guessing that Jack might be the only exception. But life is too short for me to become an expert in any of these bits of software, none of which has any decent documentation. ALSA is yet another abomination. I wonder which is worse - the actual software of the documentation. One of the pieces of documentation on the Alsa web site actually criticizes it's own documentation!!
So far I can get Camilladsp to work well using a loopback input, so I will stick with that for now. I would never have stopped using Brutefir had it not been for the fact that I could not get the delay function to work. I much prefer Brutefirs syntax (I hate Python and any language that uses non language syntax (carriage returns, spaces, tabs or line feeds) as part of the code. I also hate the number of lines needed to specifiy a Camilladsp configuration. The config file i was using for Brutefir would fit in one page - the same thing in Camilladsp takes up 7 or 8 pages, causing me to spend so much time scrolling the screen.
If some company were to come up with a piece of hardware that could do FIR filters, like my Driverack PA2, which only does IIR, I would pay anything to get it. Hardware is always MUCH more reliable than software. There is the Minidsp, but the hardware is so weak you cannot get anywhere near the number of taps that a raspberry PI can do.
Anyway, end of rant and end of message. Thanks once again for the help!
What I really need for this kind of setup is a sound card with hardware buttons on it to set the sampling rate, and a display to confirm the output is at that sampling rate. I don't currently have one, and doubt there is such a device for sale.
My current opinion is that the Linux sound architecture is an abomination of bits and pieces (OSS, ALSA, Pulseaudio, Pipewire) none of which are particularly good. I'm guessing that Jack might be the only exception. But life is too short for me to become an expert in any of these bits of software, none of which has any decent documentation. ALSA is yet another abomination. I wonder which is worse - the actual software of the documentation. One of the pieces of documentation on the Alsa web site actually criticizes it's own documentation!!
So far I can get Camilladsp to work well using a loopback input, so I will stick with that for now. I would never have stopped using Brutefir had it not been for the fact that I could not get the delay function to work. I much prefer Brutefirs syntax (I hate Python and any language that uses non language syntax (carriage returns, spaces, tabs or line feeds) as part of the code. I also hate the number of lines needed to specifiy a Camilladsp configuration. The config file i was using for Brutefir would fit in one page - the same thing in Camilladsp takes up 7 or 8 pages, causing me to spend so much time scrolling the screen.
If some company were to come up with a piece of hardware that could do FIR filters, like my Driverack PA2, which only does IIR, I would pay anything to get it. Hardware is always MUCH more reliable than software. There is the Minidsp, but the hardware is so weak you cannot get anywhere near the number of taps that a raspberry PI can do.
Anyway, end of rant and end of message. Thanks once again for the help!
Last edited:
The config syntax of brutefir was actually one of the reasons I decided to build something new 😀
A brutefir config gets quite small, but imo it is very hard to both read and write. I usually ended up keeping the documentation open while doing any work on the config, and scrolled around in that one instead. It's of course a matter of taste, but I much prefer a config file I can read on it's own.