Behringer X32: Crackling playback at 48 kHz

[dstra2]

Hi,

I'm using a Behringer X32. The mixer supports two sampling rates: 44.1 and 48 kHz. Via the firewire connection (JACK audio server with firewire backend), both recording and playback at 44.1 kHz work without any problems. But at 48 kHz only recording works, playback is heavily disturbed (digital artefacts).

When the mixer is connected, it is (correctly) recognised as
BEHRINGER X_UF (id:6, rev:0), GUID 00156400000082f5 at fw1.0, S400
and the following modules are loaded: snd_bebob snd_firewire_lib

The problem occurs with both tested kernels:
4.15.0-167-lowlatency (Kubuntu 18.04)
5.13.1-051301-lowlatency (Ubuntu Studio 21.04)

I would appreciate any help to solve this problem.

[takaswie]

Thanks for filing the issue.

I've been waiting for any report about Behringer X-UF expansion card since it uses ArchWave AG (formerly known as BridgeCo AG) DM1500 ASIC to which ALSA bebob driver is bound.

Behringer X-UF expansion card

• https://www.behringer.com/product.html?modelCode=P0AQK

I think you just tested with ALSA bebob driver in stock kernel up to v5.13 in Ubuntu official repository. For some BeBoB based devices (not all of them), previous driver causes the simillar issue of playback noise. The driver got changes in v5.14 kernel in its packet streaming function to improve the issue:

• Changes in ALSA firewire stack at Linux kernel v5.14 release
  • https://lore.kernel.org/alsa-devel/f8c93441-2f24-48d3-b6e8-76dac7441b41@sloti41n14/

In Ubuntu distribution, the future Jammy Jellyfish (22.04) release includes the newer driver. So you can not test it instantly.

Instead, would I ask you to install baCkported driver in the repository according to instruction in README.

Cheers.

[dstra2]

Thanks for the feedback. I managed to install the drivers from the Github repository and do some testing. The findings are:

• Playback now basically works with both 44.1 and 48 kHz.
• Unfortunately, the mixing console can now only be operated reasonably stable in 16 input/output mode (instead of 32) and with a large JACK buffer (>= 512). With a smaller JACK buffer or in 32 input/output mode, continuous xruns occur.

I suspect that the driver now generates a higher CPU/DSP load, resulting in the xruns. Is there a way to reduce the CPU/DSP load of the driver?

[takaswie]

Hi,

Thanks for the feedback. I managed to install the drivers from the Github repository and do some testing. The findings are:

Thanks for your test.

• Playback now basically works with both 44.1 and 48 kHz.
• Unfortunately, the mixing console can now only be operated reasonably stable in 16 input/output mode (instead of 32) and with a large JACK buffer (>= 512). With a smaller JACK buffer or in 32 input/output mode, continuous xruns occur.

Some users report the similar issue in default settings of jackd service. I'd like you to try below
additional configurations:

• Enable --sync / -S option for normal mode (synchronizing to output device explicitly) to suppress flush mode
  • https://github.com/jackaudio/jack2/blob/develop/common/JackServerGlobals.cpp#L162
• use 3 or more for --nperiods / -n option
  • https://github.com/jackaudio/jack2/blob/develop/linux/alsa/JackAlsaDriver.cpp#L726

However, it appears that hardware vendors added any customization to BeBoB firmware even if they use the
same ASIC. If the additional configurations bring you no improvements, we shall need to dive into packet
streaming for your extension card.

I suspect that the driver now generates a higher CPU/DSP load, resulting in the xruns. Is there a way to reduce the CPU/DSP load of the driver?

In my opinion, users of jackd tend to judge that any XRUN comes from higher load of something
including driver issue, however it is not necessarily adequate to diagnose the issue. Especially, in my
understanding, implementation of jackd is not preferable ALSA application nowadays. We have
experienced paradigm shift for audio data processing in this two decades, but the basic design
of jackd has not been changed during the term. In this meaning, I reccomend users to migrate to PipeWire.

Anyway I'm waiting for your report about the additional two options.

---

As another topic, I collect the content of configuration ROM for devices connected to IEEE 1394 bus.

• https://github.com/takaswie/am-config-roms/

The collection is used to generate systemd hardware database to configure udevd to make expected
access permission of Linux firewire character device (/dev/fw[0-9]+):

• https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb

We already have the entry corresponding to X-UF card for Behringer X32:

• https://github.com/systemd/systemd/blob/main/hwdb.d/80-ieee1394-unit-function.hwdb#L162

However in case, it is better to store data of ROM for your device. You can pick it up via sysfs node,
typically:

$ cat /sys/bus/firewire/devices/fw1/config_rom > behringer-x-uf.img

[dstra2]

Thanks for the instructions.

use 3 or more for --nperiods / -n option

All tests (including the previous ones) were performed with 3 periods.

Enable --sync / -S option for normal mode (synchronizing to output device explicitly) to suppress flush mode

The xruns have disappeared and the JACK buffer can be set much smaller again (both in 16 and 32 input/output modes). After a while, however, noise reappears (not xruns). The time it takes for the noise to reappear is irregular (a few seconds to several minutes; I have not yet been able to see a pattern). A change in the mixer configuration, for example switching the samplerate from 48 to 44.1 kHz and back again, so that the audio backend of the Linux system is updated/reconfigured, and a subsequent restart of JACK in most cases cause the noise to disappear temporarily.

However in case, it is better to store data of ROM for your device. You can pick it up via sysfs node,
typically:
$ cat /sys/bus/firewire/devices/fw1/config_rom > behringer-x-uf.img

Here is the file: behringer-x-uf.tar.gz

Kind regards

[dstra2]

I closed the issue by mistake and therefore reopen it...

[takaswie]

Thanks for the instructions.

use 3 or more for --nperiods / -n option

All tests (including the previous ones) were performed with 3 periods.

Enable --sync / -S option for normal mode (synchronizing to output device explicitly) to suppress flush mode

The xruns have disappeared and the JACK buffer can be set much smaller
again (both in 16 and 32 input/output modes). After a while, however,
noise reappears (not xruns). The time it takes for the noise to reappear
is irregular (a few seconds to several minutes; I have not yet been able
to see a pattern). A change in the mixer configuration, for example
switching the samplerate from 48 to 44.1 kHz and back again, so that the
audio backend of the Linux system is updated/reconfigured, and a
subsequent restart of JACK in most cases cause the noise to disappear
temporarily.

Hm. Would I ask you to use the other sound services like PulseAudio (or PipeWire)
as comparison experiments? You can check current clock of sampling frequency
by output of /proc/asound/cardX/firewire/clock (X is numeric ID for your
device in Linux sound subsystem).

However in case, it is better to store data of ROM for your device. You can pick it up via sysfs node,
typically:
$ cat /sys/bus/firewire/devices/fw1/config_rom > behringer-x-uf.img

Here is the file: behringer-x-uf.tar.gz

Great. I pushed it at a commit c83dbf04db00.

• takaswie/am-config-roms@c83dbf0

[dstra2]

Hi,

Hm. Would I ask you to use the other sound services like PulseAudio (or PipeWire)
as comparison experiments?

Tests under PulseAudio have led to the following results (playback of an audio file using Audacity, kernel 5.13.1-051301-lowlatency, drivers from this repository):

Mixer configuration	Audio file	Result
16 I/O channels, 44.1 kHz	44.1 kHz	O.k. (no noise)
16 I/O channels, 44.1 kHz	48 kHz	Playback not possible (Audacity error message due to sample rate mismatch)
16 I/O channels, 48 kHz	44.1 kHz	noise appears after a few seconds
16 I/O channels, 48 kHz	48 kHz	noise appears after about 1 minute
32 I/O channels, 44.1 kHz	44.1 kHz	O.k. (no noise)
32 I/O channels, 44.1 kHz	48 kHz	Playback not possible (Audacity error message due to sample rate mismatch)
32 I/O channels, 48 kHz	44.1 kHz	noise from the beginning
32 I/O channels, 48 kHz	48 kHz	noise continually comes and goes

Changing the mixer configuration, so that the audio backend of the Linux system is updated/reconfigured, causes the noise to disappear temporarily (as under JACK).

Kind regards

[takaswie]

Hi @dstra2,

Thanks for the feedback. It's possible that the device has any quirk between packet processing function and audio signal processing function since it generates noise even if packet streaming is successful without any XRUNs.

I'm preparing some tools to diagnose internal state of the device. I'd like you to wait a bit.

Thanks

[takaswie]

Hi @dstra2,

I'm preparing some tools to diagnose internal state of the device. I'd like you to wait a bit.

I pushed the tools into hinawa-utils repository:

• https://github.com/takaswie/hinawa-utils

As a prerequisite, libhinawa 2.0 or later should be installed:

• https://github.com/alsa-project/libhinawa

In Ubuntu 21.04 or later, deb pfackages (libhinawa2, gir1.2-hinawa-3.0) are available from official repository:

• https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=libhinawa

Python 3 and PyGObject (python3-gi) should be required as well.

When checkout the master branch hinawa-utils repository, below scripts are available:

$ ./hinawa-bebob-plug-parser /dev/fw1 2
$ ./hinawa-bebob-connection-cli /dev/fw1 dump-connections

I'd like you to retrieve output from the above utilities, then paste them here.

Thanks

[takaswie]

$ ./hinawa-bebob-plug-parser /dev/fw1 2

Incidentally, the above script takes longer to finish, several seconds.

[dstra2]

Hi @takaswie,

Thanks for your assistance.

When checkout the master branch hinawa-utils repository, below scripts are available:

$ ./hinawa-bebob-plug-parser /dev/fw1 2
$ ./hinawa-bebob-connection-cli /dev/fw1 dump-connections

I'd like you to retrieve output from the above utilities, then paste them here.

Here is the output of the two scripts:

• output_hinawa-bebob-plug-parser.tar.gz
• output_hinawa-bebob-connection-cli.tar.gz

Kind regards