Sound outputs missing after running Ardour

Installation & Configuration Linux
#1

Hi all,
I’ve searched high and low…

Time came to upgrade from debian 12 to 13 (Trixie / stable). After this my three sound outputs all worked:

  • optical out to hifi amp,
  • usb out to digital audio interface, and
  • hdmi/displayport out to display monitor’s speakers.

Then I installed Ardour
[Ardour 8.12.0~ds “Sonora Portraits” (rev 8.12.0~ds-1) Intel 64-bit]
…and opened a past project. I understand little of linux sound systems, but in the past I just used alsa settings without jack and it worked. This time I’ve read that Trixie defaults to using pipewire to connect everything up. On starting ardour I still chose the alsa options as I haven’t installed any jack stuff, and from what I can see there is no pipewire-jack or the like in my system. I mention that because jack/pipewire shows up in Ardour start options, even though it doesn’t work at all. So with alsa selected I was able to hear sound monitored externally on all of the three devices I have. All seemed well, but I noticed an odd thing early on…

Whenever I stopped and then started the Audio/Midi setup in Ardour to connect to a different output, the (non-Ardour) gnome sound settings GUI didn’t always display the matching output labels. Worse was to come…

When I closed Ardour altogether, my gnome sound settings got stuck on the USB audio interface, with no other output in sight. Reboots didn’t help, nor did restarting pipewire and wireplumber. I couldn’t use the other output devices any more. To be clear I’m not trying to use different outputs while using Ardour, I just want to be able to use different outputs once Ardour is closed.

I tried all sorts to no avail. Eventually I reinstalled the operating system, and sound worked as it should. I installed Ardour on top, ran it, and the same problem re-occurred. Only one sound output (usb) is now available after running Ardour. To be precise I can stick a 1/4 inch jack into the back of the computer and still get analogue sound out, but that’s not an output I wanted to use. Obviously reinstalling the OS after running Ardour each time isn’t practical.

Most search hits I found relate to pre-pipewire / pre-trixie setups so I’m not surprised they haven’t helped. There’s one item on this forum that talks of ‘killing’ Jack, which to my knowledge I don’'t have. Everything I’ve read about sound on trixie seems to imply it should just work without the extra effort that previous Debian versions needed. So not sure what more I can do.

Hoping this is a helpful clue, I get:

~$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: PCH [HDA Intel PCH], device 0: ALC897 Analog [ALC897 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: ALC897 Digital [ALC897 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [PL3493WQ]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: U192k [UMC204HD 192k], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

I presume the above devices should not all have the same card and subdevice number!

So I’m wondering, is there some simple command I can use to make gnome get a grip again on all the hardware outputs after running Ardour?

1 Like
#2

All the PCH devices are card 0, and have different device numbers.
The usb device is card 1, device 0.
Nothing looks unexpected there.

Check what pavucontrol shows the settings to be after Ardour stops.

#3

pavucontrol under the configuration tab offers:

  • the usb audio interface UMC204HD 192k, and
  • Built-in Audio “off” with drop down options
    • Stereo out + in (unplugged) unavailable
    • Stereo output (unplugged) unavailable
    • Stereo input (unplugged) unavailable
    • Pro Audio
    • off
      Pro audio is selectable but doesn’t seem to help connect to the outputs I want in any way

In case it helps: alsamixer shows Card and chip to be Pipewire. F6 “select sound card” offers:

  • default 0 HDA Intel PCH
  • default 1 UMC204HD 192k
    However attempting to select one of these exits with the comment “cannot load mixer controls: No such file or directory”
#4

What version of pipewire and wireplumber does Debian 13 provide? This seems like something wrong with the sound server configuration.
I don’t normally associate Debian stable with being super timely, but I saw somewhere that Trixie provides pipewire 1.4.9 now. Is that accurate? That is the latest tagged version of 1.4.x and is what Fedora currently provides, so should be both reasonably recent and stable.

#5

pipewire 1.4.2-1 (Debian -- Package Search Results -- pipewire)

On my debian/trixie system this I don’t have this issue though.

When I start Ardour/ALSA pipewire (using the onboard HDA Intel PCH), desktop sound stops, and when Ardour is closed, sound resumes…

I’m not using gnome (mate-desktop here), but I doubt that makes a difference.

That is pulseaudio. Likely the issue is at a lower level. Debian saves/restores hardware mixer levels (alsamixer) which may be muted.

Wow.

How can Ardour even use those soundcards in the first place :slight_smile:

Do you use Debian’s default kernel? Is there anything in dmesg?

#6

pipewire 1.4.2-1 amd64
wireplumber 0.5.8-2 amd64
ardour 1:8.12.0+ds-1 amd64

I don’t knowingly alter the kernel.

In summary here’s what I know I do:

  • install OS
  • apt-get update etc
  • alter /etc/crypttab and /etc/fstab
  • restore user’s files from backup into /home storage area with rsync opts -auv
  • alter umask for user to “UMask=0077”
  • chmod same restricted permissions throughout user’s /home storage area
  • install list of user-preferred applications from default repos
  • install proprietary google chrome using their repos - gets added to apt sources
  • restore printer settings in /etc/cups from backup
  • restore gnome user pref using dconf load from backup
  • apt sources: modernize, remove source code, target trixie, trixie-updates, trixie-security: all to min, non-free-firmware
  • The last of these brought in intel-microcode (3.20250812.1~deb13u1
  • Set nftables firewall
  • Set croncode schedules for updates and backups

I’m pretty clueless about dmesg, but had a go:

# dmesg | grep -i hda
[   71.339975] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[   71.340144] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   71.418557] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC897: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[   71.418563] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   71.418564] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[   71.418565] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[   71.418566] snd_hda_codec_realtek hdaudioC1D0:    dig-out=0x1e/0x0
[   71.418566] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[   71.418567] snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
[   71.418568] snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
[   71.463578] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card1/input13
[   71.463604] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card1/input14
[   71.463622] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card1/input15
[   71.463640] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card1/input16
[   71.463657] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card1/input17
[   71.463677] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card1/input18
[   71.463694] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card1/input19
[   71.463711] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card1/input20


# dmesg -l warn
[    0.078937]   #1  #3  #5  #7  #9 #11 #13 #15
[    0.245123] pnp 00:03: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
[    0.607599] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    0.886364] igc 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[    4.333499] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[   76.226712] nvme nvme0: using unchecked data buffer
[   98.382759] show_signal: 117 callbacks suppressed
[  104.407303] warning: `conky' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
[  164.131242] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131359] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131483] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131608] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131733] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131860] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.131981] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint
[  164.132109] xhci_hcd 0000:00:14.0: WARN: buffer overrun event for slot 2 ep 4 on endpoint

I tried Ardour on my machine using a live version of gnome trixie, it did hand back control to gnome, but of course I couldn’t update all the software first nor see if it still worked after a reboot. I noticed the problems on the installed version after a reboot following running ardour so can’t be sure when it locked out my access to the internal HDA / HDMI audio.

Just my impression, and again beyond my proper understanding, but it seems to me that Ardour somehow activates pipewire et al (leveraging alsa?) to list / locate outputs/sinks to make them available for the user to choose from. This is in the start button in the audio / midi settings window. And the stop button stops everything. Perhaps the stop is clearing some sinks from pipewire’s dynamically created sinks/nodes?

#7

I did a fair bit more reading about pipewire alsa and other systems, and am still no nearer identifying a clear error on my part, any precise cause or solution.

For the time being I reinstalled the whole system, and took a timeshift snapshot, then tried Ardour again. At first it worked then played up similar to before. I restored the system snapshot and it’s working for now. I’m hesitant to assume my Ardour / sound troubles are over or that I have a solid working foundation.

So I reflected that Robin said he uses ALSA pipewire with the onboard HDA Intel PCH. And Robin also commented or joked about “How can Ardour even use those soundcards”. I can’t interpret this in the context that Ardour clearly offers such soundcards (when things are working). Furthermore the ardour startup options provide an option for Alsa and a different option for Jack/Pipewire. Does the latter mean Jack with Pipewire, or either one of these alone. And is the spearate Alsa option in Ardour indicating a direct connection to Alsa or does it channel via pipewire without mention of the latter?

I mentioned already, all the online advice is mostly concerning earlier software versions (and the debian page on pipewire https://wiki.debian.org/PipeWire is written ambiguously about whether any manual setup is needed or not) so I’m not clear what to do to get sound out of Ardour’s Jack/Pipewire startup option to see how that goes. I read that pipweire has less latency than jack, so using it directly without jack could be a good idea?

More specifically I wonder whether Ardour is ready to work with pipewire without jack? If so which settings do this? Do I need to copy config files into some target as with the older Debian 12?

And to try Jack with Ardour on trixie, do I still need need to do something to activate it first (and which Jack programs does one need to install jackd / jack2 / pw-jack / other?). Sorry but the info in the manual is light-touch in this area.

As you can see I’m a bit lost with all my reading to know if I’m going forward or backwards. I’m starting wonder whether I should give up and migrate to a chromebook!

#8

Hi @beanhop, I have experience similar symptoms with an HDA Intel PCH chipset. I believe it is unrelated to ardour, pipewire, and alsa etc, rather that occasionally the device gets somehow “stuck” in a mis-configured firmware state. The fix for me was to disable UEFI/BIOS fastboot mode to force the chipset to fully initialize before booting the OS. Likely your full reinstall achieved the same result.

Note also that the snd-hda-intel kernel module has a number of options which can help with specific issues.

#9

The JACK/Pipewire backened used to be named JACK backend, but people who had pipewire-jack were confused about whether to use the JACK backend or not. The name change is just to hint that whether using jackd or pipewire-jack that is the backend to use.

Correct, when using the ALSA backend Ardour will request exclusive access to the sound hardware. There is a protocol for the request such that pipewire recognizes another application has requested exclusive use of the sound hardware and relinquishes use so that Ardour may use the device. After Ardour stops then pipewire should begin using the device again.

You have to install the pipewire-jack module to provide the JACK server API.

That was incorrect information.

No, pipewire is a sound server which provides multiple API variants for applications to use. Desktop applications almost universally use the Pulse API, provided by the pipewire-pulse module, or the ALSA library emulation, provided by the pipewire-alsa module. Neither of those is fully suitable for music production use case. The JACK API is intended for audio production, and the pipewire-jack module provides that API.
For cases where there is no need to route audio between different applications the best choice is to allow Ardour to access the ALSA hardware driver directly, which eliminates any sound server software layer between Ardour and the audio device.

I do not know about the trixie repository specifically, but in general you have the choice of either installing the pipewire-jack module to allow the pipewire server to also be the JACK server, or installing jackd (version 2 is really the only fully supported version now, which may be what you referred to as jack2). When using jackd the jackd server requests exclusive access to the audio hardware, and the pipewire server relinquishes control for the time that jackd is running, just as it does when Ardour requests exclusive access to the hardware.

You should not need pw-jack on a system which is setup properly, it was just for the case where you wanted to have original jackd and pipewire-jack installed simultaneously on the same system, and be able to use jackd by default, or start applications with pw-jack to force using the pipewire implementation of JACK. At this point you should just choose one or the other implementation and not have both installed.

So with that background, what should happen after Ardour (or any other application, such as jackd) relinquishes control of the audio hardware is that pipewire will again access the device, and should retrieve the set default configuration data to determine how to configure the device (sample rate, buffer size, default gain if that is adjustable, etc.).

I believe you indicated you are using gnome desktop environment, so perhaps gnome control center is the application which should set the default audio settings. Does that indicate that all devices are “on” and have a reasonable profile chosen?

2 Likes
#10

Thanks for your input Mark, I checked and Fast Boot was already off. There is an OC Tweak option under the CPU section to change the boot performance mode from the current ‘Turbo pref’, to ‘Max non Turbo pref’, but I’m not sure if that’s even active if fast boot is off. (never wanted to do any Over Clocking changes so hadn’t even looked in here before!)

My Realtek ALC897 wasn’t in your linked list but I think the mention in your first link of “enable the sound debug option, CONFIG_SND_DEBUG=y, no matter whether you are debugging or not.” might be something I could use in future, …if I figure out where and how to read the output :thinking:

#11

Chris,
Thank you so much for taking the pains to explain all this so clearly. I now know what I was misunderstanding about this much better, and feel much more comfortable continuing with the ALSA only option. Also thanks for recommending which way to go if I want to try JACK in future.

Yes, the gnome settings GUI does currently show all the sound outputs as I’d expect, but there’s no control of default, just that the current selection gets remembered until you change it manually. When some of the output options were not available was when things had gone wrong. Sometimes the only output was “Dummy”, and then I had no sound anywhere at all. Currently Dummy does not display in the settings GUI and all is well.

Unfortunately the Gnome settings GUI doesn’t provide any profile info like “sample rate, buffer size, default gain if that is adjustable, etc.”. I only have volume sliders, and a speaker test button.

#12

I haven’t read the whole thread but isn’t samplerate and buffer size parameters you can tune from Ardour’s audio setup after choosing the ALSA backend ?

#13

Desktop sound servers like Pulseaudio and pipewire-pulse don’t usually present that sort of configuration to end-users. Because, under normal circumstances, end-user probably don’t (or shouldn’t) care.

FWIW, I believe Pulseaudio defaults to 44.1kHz. I think Pipewire defaults to 48kHz. Both will do sample-rate conversion between streams and hard which use different rates and, for most desktop audio use (e.g. watching Youtube) this is fine and “just works”.

The difference with audio production work is you probably DO care, and this is where Pulseaudio (and, by association pipewire-pulse) aren’t really ideal. There are ways to configure this, but they aren’t exposed and aren’t enforced.

Historically, either direct-to-ALSA or Jack/Jack2 were what you needed as these, explicitly, allow you to specify sample rate and buffer size, and pretty much lock you to those.

Now we have Pipewire which does have the ability to configure these (or similar parameters) but (as I understand it) Pipewire is much more dynamic in its approach and will dynamically try to adjust the system. The upshot of this is that, wheras with Jack, everything was locked and limited to a specific sample rate, Pipewire-jack allows different applications to run at different rates and will resample.

Conventionally, in music production, this is not ideal as resampling breaks the “bit-perfectness” of audio streams and can, potentially, introduce distortions.

I believe the only way to ensure that your applications are all running at the same rate as the underlying Pipewire system is to use pw-top and manually check (look at the RATE column):

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME 
I   30      0      0   0.0us   0.0us  ???   ???     0                  Dummy-Driver
S   31      0      0    ---     ---   ---   ---     0                  Freewheel-Driver
R   72    512  48000  84.4us   0.4us  0.01  0.00   18   S24LE 18 48000 alsa_input.usb-BEHRINGER_XR18_4C5BB32DFB73_03-00.pro-input-0
S   41      0      0    ---     ---   ---   ---     0                   + capture.XR18_mic
I   42      0      0   9.4us   8.4us  0.00  0.00    0         F32P 1 0  + input.capture.XR18_mic
S   43      0      0    ---     ---   ---   ---     0                   + capture.XR18_stereo
I   44      0      0  75.6us   5.9us  0.01  0.00    0         F32P 2 0  + input.loopback-3094-13
R   45      0      0   0.8us   1.1us  0.00  0.00    0         F32P 2 0  + playback.XR18_stereo
R   46      0      0   3.3us   1.9us  0.00  0.00    4         F32P 2 0  + input.loopback-3094-14
R   59      0      0   2.6us   1.9us  0.00  0.00    0                   + Midi-Bridge
R   68      0      0   7.5us   1.6us  0.00  0.00    0                   + bluez_midi.server
R   71      0      0   3.1us  20.5us  0.00  0.00    0   S24LE 18 48000  + alsa_output.usb-BEHRINGER_XR18_4C5BB32DFB73_03-00.pro-output-0
S   63      0      0    ---     ---   ---   ---     0                   + v4l2_input.pci-0000_00_14.0-usb-0_8.1.2_1.0
R  208    512  48000   4.9us  39.1us  0.00  0.00    1                   + ardour

You can configure Pipewire to limit it’s sample rate to a given value and, then, typically most applications will then fall in line with this when launched.

Cheers,

Keith

#14

Going a little off the original Ardour topic: I never thought that pipewire would resample to a default! Just tried this playing a track in audacious outputting via pipewire:

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME 
R   71   1024  48000 195.0us  39.2us  0.01  0.00    0    S32LE 2 48000 alsa_output.pci-0000_00_1f.3.iec958-stereo
R  107      1     25  81.2us  38.5us  0.00  0.00    0       F32LE 1 25  + GNOME Settings
R  127   4096  96000  26.1us  81.3us  0.00  0.00    0    F32LE 2 96000  + audacious

Looks like 96 khz is being downsampled to 48 khz
Then i tried it direct to ALSA. I think the way to measure that is to look at the active soundcard in /proc/asound/… hw_params , and got this:

access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 6000
buffer_size: 24000

So it looks like ALSA direct sends whatever is playing, and Pipewire then resamples it to a default value. So Pipewire isn’t the simple do-it all feature I’d naively assumed. Thanks for the pointers Keith.

To bring this back to the original issue of disappearing outputs, I’m starting to think that where my system got gummed up, was when I assumed the gnome sound settings should follow whatever Ardour switched to. Now I see they are separate. Presumably when Ardour took over from say pipewire, and I set Ardour to output direct to Alsa, I shouldn’t have been trying to switch the gnome settings to the same output, and then quickly clicking others in frustration. Given when you stop / start your output settings in Ardour, it takes a short time for the changes to actually take effect, messing with the calls from gnome at the same time might have caused some system calls to get muddled. Leading perhaps to the system blacklisting a sound card / sink… which then left me unable to get certain outputs to work without a reinstall… maybe, maybe? Well that’s my guess at the mo: so I’m being patient about making direct connections, and first making sure nothing else is calling to another output at the same time. So far this approach is working.

1 Like