Behringer UMC204HD and UMC404HD

Installation & Configuration Linux
#1

Sorry for the long post :slight_smile:

There’s been a lot of discussion about Behringer UMC204HD on the forum lately. Some people are getting very low latencies with it. I already own Behringer UMC1820 and I’ve been very happy with it, so I thought “what the heck, I can’t have too many Linux compatible audio devices can’t I” and ordered both UMC204HD and UMC404HD :slight_smile:

I’ve had these devices just for one day so I don’t have much experience with these yet. Here are the first impressions.

The devices are smaller versions of the UMC1820 and they feel and look like it and the performance characteristics are probably about the same. You can get techical details of the devices for example from Thomann:

UMC204HD does not have a power supply, it gets its power from USB. UMC404 is powered by a separate power supply. Neither device has a power button, so they turn on when you plug power to them.

One “flaw” that I noticed was that when UMC204HD was connected and I rebooted the computer the device “disappeared” from Linux. Unplugging and plugging the USB cable returned the device to normal operation. This is probably some kind of a bug in the firmware of the device.

Behringer UMC204HD and UMC404HD are both capable of a very low latency. Both devices were able to go down to 64 buffer size and 3 periods without xruns (tested for about 1 hour). 64 buffer and 2 periods worked sometimes flawlessly and sometimes threw xruns. The test was done playing piano on fluidsynth. The DSP load varied between 25% - 30% when using buffer: 64 periods: 3, However after playing for a while the load sometimes dropped down to 5% - 10% and stayed there. I saw this behavior many times (but not always) and it probably indicates something is be wrong with the RT-kernel I used (or my system). The a-Fluidsynth “CPU Profile” showed the same load regardless if Ardour DSP load was 30% or 5%. I’ve seen other people having problems getting 204HD to work without xruns with 64 buffer, 3 periods so I guess the motherboard plays a role here.

The test was done with
Motherboard: Asus_ROG_STRIX_X399-E_GAMING_TR4
Processor: AMD Threadripper 2950X
Manjaro with realtime kernel: 5.4.61-rt37-MANJARO, Performance - governor turned on.
Ardour 6.3
Backend: Alsa
Sample rate 44.1 kHz, Buffer: 64, Periods: 3
One midi track with a-Fluidsynth loaded with “soundfont-fluid”. I played live with a midi keyboard connected to sound card Midi In.

Screenshot_2020-10-01_21-17-02
Screenshot_2020-10-01_21-17-021920×1051 248 KB

Behringer UMC204HD Supported sample rates and bit depths
cat /proc/asound/U192k/stream0

BEHRINGER UMC204HD 192k at usb-0000:41:00.3-1, high speed : USB Audio

Playback:
Status: Stop
Interface 1
Altset 1
Format: S32_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24
Interface 1
Altset 2
Format: S16_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 16

Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24

cat /proc/asound/U192k/midi0
UMC204HD 192k

Output 0
Tx bytes : 0
Input 0
Rx bytes : 0

Jack_iodelay latency measured 11 times, buffer = 1024, periods 3
(322+329+324+324+332+332+326+329+329+329+326) / 11 = 327.4545454545

Behringer UMC404HD Supported sample rates and bit depths
cat /proc/asound/U192k/stream0
BEHRINGER UMC404HD 192k at usb-0000:41:00.3-1, high speed : USB Audio

Playback:
Status: Stop
Interface 1
Altset 1
Format: S32_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24
Interface 1
Altset 2
Format: S16_LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 16

Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24

cat /proc/asound/U192k/midi0
UMC404HD 192k

Output 0
Tx bytes : 0
Input 0
Rx bytes : 17838

Jack_iodelay latency measured 11 times, buffer = 1024, periods 3
(312+299+301+301+308+305+296+316+307+301+312) / 11 = 305.2727272727

5 Likes
#2

I use the 204 AND an almost identical setup to you, except I’m running an Intel chipset on a little NUC. I feel like the 204HD has done it’s job with my first record, but I’m looking at upgrading my setup before I go for record number 2, partially so I can do the tracking for the band, and mostly to add some analog hardware pres for some sonic saturation on vocals.

That’s an awfully low sample rate for my liking - I had been running it at 48khz but have decided to up my resolution to 96khz after some testing with playing. My bandmates in my other project all swear by 44.1 though, so I can’t really stand on a high horse and say too much.

What does that round trip latency look like in milliseconds for us laymen?

I want to add, and I think this is true of most interfaces: don’t go in expecting a 2000$ mic pre sound. I HIGHLY recommend running a good mic pre before this unit, as it is adds ZERO sonic color on the input chain - something awesome if you’re tracking out of a Kemper or something like, but not as awesome if you’re tracking vocals with a mediocre mic and want some serious warmth and mid frequency saturation.

#3

With UMC204HD and buffer: 64, periods: 3 jack_iodelay reports the total roundtrip latency as:

581.674 frames 13.190 ms total roundtrip latency
extra loopback latency: 389 frames
use 194 for the backend arguments -I and -O

I would advice against using a sample rate higher than 48 kHz as in this case bigger is not better, and can actually make the sound worse. This has been discussed many times on the Ardour forum. Every piece of equipment (microphones, amps, speakers, etc) needs to be capable of reproducing frequencies higher than 20 kHz to get any benefit from 96 kHz sample rate. In fact if your amp can not do this, the higher frequencies might be aliased back on frequencies below 20 kHz creating distortion / dips in the frequency spectrum. To cut the long story short, you can not get better sound quality with higher frequencies above 48 kHz. Higher sample rates are there just to create the illusion for “bigger is better” and for the purpose of selling new equipment to people who already have good quality 48 kHz devices.

Behringer says 204 and 404 Input frequency response is: 10 Hz – 50 kHz (0 / -3 dB) and output: 10 Hz – 43 kHz (0 / + 0.3 dB). What is considered good sound is quite a subjective matter. What I personally believe is that some 30 years in development in AD - converters and IC’s has brought the price of these down so low that even cheap interfaces can have quite a “good or transparent sound”. Some may consider specific colorations (= defects) in audio reproduction to sound good. I do that too because I’m a guitar player and a good guitar sound is very much the product of the defects in the amplifiers / speakers ability to correctly reproduce the original sound.

#4

To piggy back on a comment you made, I own a Behringer UMC1820 that I have connected to two different laptops running the same OS. The difference I experience in xrun behavior between the two machines has lead me to believe that low latency performance is affected by motherboard design moreso than software. Similarly, I used to own a desktop with an added PCI card of USB inputs, and my audio interface never produced xruns when connected to that card despite frequent xruns when connected to the built-in ports on the same machine. On laptops, you get what the manufacturer gives you when it comes to USB ports, and it is hard to know before buying how capable a particular laptop is of low latency via USB.

2 Likes
#5

This is an important observation, thanks for bringing it to our attention.

1 Like
#6

I agree with your point in the context of “standard” music creation. But the possibility to record samples at 96 kHz (or more) that are then played half-speed is a fascinating creative tool. And the more content you have in high frequencies, the better. For this you just need a capable audio interface plus a microphone that goes well above 20 kHz (amps and speaker do not need any special capability in this scenario).

1 Like
#7

I use UMC204HD and never had the issue of the firmware. My UbuntuStudio recognizes it just fine every time. Sometimes when I plug or unplug something from the interface it disappears. But it’s very rare. Most of the time it will work fine.

#8

There’s some truth to this but I don’t think it’s the full picture.

I’ve seen the sample rate debate on the internet a few times and the sticking point is ‘you can’t hear it’. That’s correct, you can’t, and that’s the reason to use a higher sample rate.

You’ve heard of over-sampling, right? Using a concrete example I recently downloaded an analogue tape model – CHOW DSP

It has the option of up to 4x oversampling. Why would it have that if high sample rates are a con? It’s free software – they aren’t trying to sell anything.

Because it is a non-linear model artefacts can be produced and using 4x oversampling means the artefacts are not audible. The reason to record at a higher sample rate is not that any more will be captured in the recording process, but that artefacts introduced by non-linear processing will be at frequencies that are not audible.

#9

My comment you talk about was deliberately a little provocative. I was a bit surprised nobody challenged it until now :slight_smile: Anyway this is what I believe until somebody proves it wrong.

Yes you are right, there are some edge cases where higher sample rates can be used, but it is probably very hard to get some frequencies to appear in the 20 kHz - 96 kHz range since most equipment (microphones, preamps, amps, speakers) simply can’t reproduce those.

In the case of the plugin you mention the higher rate might be used to get some benefit in the calculation / emulation model. The output of the plugin probably gets sampled back down.

The mathematics in the plugins theoretical paper is a little over my head but it says oversampling is needed to get rid of some errors that appeared in audible frequency range. Excerpt from the paper:

If no oversampling is used, the system will be unstable for input signal at the Nyquist frequency, due to limitations of the trapezoid rule derivate approximation used in eq. (21). To avoid this instability, early versions of the real-time implementation used a lowpass filter with cutoff frequency just below Nyquist. However, due to aliasing caused by the nonlinearity of the tape hysteresis model, oversampling is necessary to mitigate aliasing artifacts [8].Further, the system must be able to faithfully recreate not only the frequencies in the audible range but the bias frequency as well. Since the TC-260 uses a bias frequency of 55 kHz [14] and the minimum standard audio sampling rate is 44.1 kHz, a minimum oversampling factor of 3x is required. However, since the biased signal is then fed into the hystersis model, even more oversampling is required to avoid aliasing. With these considerations in mind, our system uses an oversampling factor of 16x.

By the way, its a very interesting plugin, thanks for pointing this out :slight_smile:

1 Like
#10

Honestly it is primarily because I don’t feel a need to rehash things. Yes there are specific cases where higher sample rates make sense, particularly in procedurally based generation plugins (Synths, Verbs, etc.). As mentioned oversampling can also make a difference there.

It can also make a slight difference in as far as aliasing and mixing signals together to created aliased artifacts etc. but that is more of a corner case that 99% of people don’t need to be worried about.

Finally the one place it DOES make a noticeable difference for maybe 20% of listeners is in that it allows for a more gentle LP filter to be used in the conversion process (The signal has to be LP for sampling -> nyquist reconstruction) which means less resonance and generally a slightly better sound. Again majority of people won’t recognize the difference, and I would even venture a guess that 90% of artifacts are above what most people’s damaged hearing even allows them to hear, but can make a difference.

Finally as mentioned when dealing with specific effects like time warping it can make a difference depending on the algorithm used.

   Seablade
#11

This by the way is just wrong, see my comment about LPF slopes in higher sample rates.

   Seablade
#12

It’s vastly different to use it internally in a plugin to work around digital computational limitations. This is the correct way to deal with effects that do analog modelling.

Do use a reasonable (44.1kHz, 48kHz) sample rate for I/O, and let individual DSP modules upsample as needed, but do not run the whole engine with a higher rate (those DSP modules will still have to upsample internally, even then).

2 Likes
#13

I have the 404HD. It comes with a separate power supply, but can also be powered over USB. I use the USB power and it works fine for me. I guess it depends on how much power your USB sockets can produce.

#14

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.