Sampling issue with JACK (Pipewire) and RME Fireface 800

[Kir]

Hello there,

I'm just digging into Linux audio : after installing yesterday a FireWire PCIe card (with Texas Instrument chipset), I'm trying to bring my old RME Fireface 800 back to life.

My distribution is Fedora 37 (workstation), so it comes with Pipewire. I installed qpwgraph (flatpak) to have a patching GUI, and then Audacity+Zrythm+Ardour in order to test my interface on several DAW's (the ultimate purpose is to go with Bitwig, but I'd like to make sure my hardware works first).

When I'm recording a track from the Fireface, the waveform is hashed. It looks like there's a clock sync issue ? The Fireface physical panel shows the "Host" LED on. See below how the waveform appears in Ardour (same happens with Audacity and Zrythm) :

Capture d’écran du 2023-04-15 10-51-25.png (6.86 KiB) Viewed 2362 times

I managed to get a normal waveform in Ardour when recording audio, by selecting "ALSA" as audio system rather than JACK.

Do you have similar experience ? (I suppose it is not much related to FireWire or Fireface, but rather to using several sound cards at once... ?)
What set up would you recommend ? (not going with Pulseaudio, if possible :/ )

Thank you !

[asbak]

How many sound servers are already running on your system when you try to record?

inxi -Aa

Is pulseaudio disabled from starting?
Are you trying to use native jack or pipewire jack?

[sysrqer]

What settings are you using in pipewire's jack config?

[Kir]

Thank you for your answers !

For info, the input and output devices that I can select when using ALSA audio system in Ardour are :

• Fireface 800
• My webcam
• HDA Intel PCH
• HDA Intel PCH (2)
• and as ouputs only : several lines starting with "HDA NVIDIA"

How many sound servers are already running on your system when you try to record?
inxi -Aa

Code: Select all

$ inxi -Aa
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Micro-Star MSI
    driver: snd_hda_intel bus-ID: 1-2:2 v: kernel chip-ID: 046d:****
    alternate: snd_soc_skl,snd_sof_pci_intel_cnl bus-ID: 00:****
    class-ID: 0102 chip-ID: 8086:a348 class-ID: 0403
  Device-2: NVIDIA TU116 High Definition Audio vendor: eVga.com.
    driver: snd_hda_intel v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 16
    link-max: gen: 3 speed: 8 GT/s bus-ID: 01:**** chip-ID: 10de:****
    class-ID: 0403
  Device-3: Logitech **** *** ** Webcam type: USB
    driver: snd-usb-audio,uvcvideo
  API: ALSA v: k6.2.9-200.fc37.x86_64 status: kernel-api
    tools: alsamixer,amixer
  Server-1: PipeWire v: 0.3.68 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl

Is pulseaudio disabled from starting?

I thought that Pulseaudio was not delivered with Fedora 37 (which I installed from scratch). But I see that there's a "Pulseaudio" line that I can select as audio system in Ardour's and Zrythm's settings... On the other hand, when I type "pulseaudio" in a terminal, it returns that it's an unknown command and suggests me to install the "Pulseaudio" package... So I'm not sure about anything.
(I've been on Linux for some months only... so I'm not a veteran yet...)

Are you trying to use native jack or pipewire jack?

DAWs just mention "JACK", and qpwgraph gives no info about this. But I suppose it's Pipewire JACK, as :

• pw-jack command works
• jackd and jack_control commands are unknown
• The qpwgraph app is undertitled "A Pipewire Graph Qt GUI Interface"

What settings are you using in pipewire's jack config?

I didn't touch anything, and I'm not sure what settings we are talking about. In Ardour's Audio/MIDI settings, I can only choose the sample buffer (which is on 1024, as default). It also shows a red message saying that JACK is already running, and that Ardour is going to connect to it using the existing settings.

I search on the internet but couldn't find further ways to investigate on Pipewire JACK's settings.

Thank you for your help. Please forgive my newbiness.

[sysrqer]

Yes, if you are using pipewire then you won't have pulseaudio (or jack) installed and the outputs to it that you see are just masks which go to pipewire.

In terms of the config, you might need to tweak something or at least make sure the defaults match what you are trying to do. I would guess that there is some conversion going on like wrong sample/bit rate it could be a clock issue like you mentioned. I'm not familiar with fedora at all but the default configs should be on your system somewhere so you can copy them into ~/,config/pipewire. On arch they are located in /usr/share/pipewire.

Maybe look at the jack.conf and uncomment the sample rates to what you need, and make sure that the following is set and not commented (no # in front of it):

Code: Select all

node.lock-quantum  = true

The arch wiki has some hand info about it all: https://wiki.archlinux.org/title/PipeWire

robert-vdh has some good config starters in his github - https://github.com/robbert-vdh/dotfiles, you could have a look at the pipewire and wireplumber ones to see if there is anything of interest.

[Kir]

Hello !

Thank you for your answer.

Maybe look at the jack.conf and uncomment the sample rates to what you need, and make sure that the following is set and not commented (no # in front of it):

Code: Select all

node.lock-quantum = true

I applied that. The locations you indicated are the same as on Fedora 37, so I could follow your advice. It successfully changed and locked the soundcard sample rate, but the problem remains.

As I'm facing a new huge amount of work, I won't have time to dig further (robbert-vdh/dotfiles) until the winter... and I think I will start audio on Linux using ALSA sound system (without JACK). It looks like working perfectly: I'll just have to avoid using different sources at the same time, which... is the way I used to work 18 years ago

Thank you for your help, I'm glad to join this warmhearted community!

[Impostor]

Now this thread is a good example of how Pipewire makes Linux audio more difficult (read: confusing) for end-users. The OP doesn't have Jack installed, and has a problem with Pipewire. But to him, it looks like a Jack problem, instead of a Pipewire one.
And because of that, OP concludes that he'd better not use Jack, while Jack could very well be part of the solution instead of the problem!

[Audiojunkie]

Now this thread is a good example of how Pipewire makes Linux audio more difficult (read: confusing) for end-users. The OP doesn't have Jack installed, and has a problem with Pipewire. But to him, it looks like a Jack problem, instead of a Pipewire one.
And because of that, OP concludes that he'd better not use Jack, while Jack could very well be part of the solution instead of the problem!

It makes sense, what you are saying here. It is important for new Pipewire users to learn and understand the paradigm of Pipewire to avoid this type of confusion. Although I’ve been an eager (and quite satisfied) early adopter, I myself don’t know or understand everything. I truly have “caught the vision” of what is trying to be done through the Pipewire project, and I truly believe Pipewire is going to make everything better. But I also recognize that some aren’t having as great of an experience as I am, and I understand that it will take time for all things to get worked out across all distros. I guess the best we can do is explain what we learn with each other and expect growing pains like this as the move to Pipewire becomes normalized. As time progresses and as the technology continues to mature, the general population will start to learn and understand the paradigm changes between Pipewire and the former PulseAudio/JACK. In the meantime, developers are starting to create GUI-based configuration tools for Pipewire, and some distro teams are considering making preempt=full the running generic kernel default. Each step that gets automated or allows for simplified controls brings Linux one step closer to my dream of low latency working directly out of the box.