Broken audio when using JACK via ALSA on Linux

[iamgreaser]

Following on from a few hours ago, and making sure it gets tracked here...

When attempting to use audio on my setup, if I'm attempting to set the input device or the output device to the default device, I get no audio.

The default device is a plug ALSA device connected to a jack ALSA device. Qt5Multimedia fails on a call to snd_pcm_hw_params_set_buffer_time_near() with a -22 error which is -EINVAL.

Most of my audio devices are correctly listed under Overte's audio settings.

If I write an LD_PRELOAD library to make this function always pretend that it succeeded, I do get a working audio output, but there's a lot of latency (we're talking possibly about a minute!) and any voices end up being incoherent. Plus the audio input still doesn't seem to work.

The current AppImage build is a non-option due to it lacking the jack plugin for ALSA.

I am aware that there are some issues with my audio setup at the moment and I will be looking into various options in order to make other things work consistently. For the record, SDL2's ALSA driver works fine (but doesn't do input, of course), NeosVR works fine using whatever Unity 2019.something does with ALSA, and PortAudio as used by Audacity mostly works fine except it occasionally drops audio input frames.

Outside of that, I am wondering how well things would work with using PortAudio instead of Qt5Multimedia for audio. (I'm toying with this idea on a local branch and the first thing I'm doing is decoupling things completely from QAudio, but it appears that what I've done so far has resulted in it no longer being able to list any of my audio devices... whoops!)

[daleglass]

We discussed this at the dev meeting.

So far this sounds too far removed from a standard Linux system, and there were concerns that PortAudio might not have enough functionality for most users.

Currently there seems to be very little interest overall in changing the underlying audio system.

Such an option would definitely need to make sure not to break any existing users on any of the supported platforms and be a compile-time option. And I can't guarantee we'd merge it.

[ksuprynowicz]

One thing that would be worth trying is updating to Qt6 once V8 branch is ready. Maybe it's a bug in Qt5Multimedia that got fixed in Qt6.

[ksuprynowicz]

If it turns out that it doesn't work on Qt6 either, then fixing it in QtMultimedia and sending patch upstream would be a good idea.

[Kreolis]

is #171 related?

[JulianGro]

No.

[iamgreaser]

OK, following up from this, my workaround is to do the audio via PulseAudio and force it to use the default ALSA device for sink and source. Here's my tweaks to /etc/pulse/default.pa (after removing the obligatory disparaging comments directed towards the original author of that steaming pile of software) - you should be able to locate what needs changing based on the comments:

Firstly, force static mapping:

### Load audio drivers statically
### (it's probably better to not load these drivers manually, but instead
### use module-udev-detect -- see below -- for doing this automatically)
load-module module-alsa-sink device=default
load-module module-alsa-source device=default
#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-null-sink
#load-module module-pipe-sink

Secondly, disable automatic mapping:

### Automatically load driver modules depending on the hardware available
#.ifexists module-udev-detect.so
#load-module module-udev-detect
#.else
### Use the static hardware detection module (for systems that lack udev support)
#load-module module-detect
#.endif

If you use PulseAudio's JACK plugin, it will add about a second of latency. Routing through ALSA's JACK plugin instead works perfectly. Actually, PulseAudio probably behaves best when it's not managing the hardware and instead going through something else.

I wouldn't consider this issue resolved as such, but at least there's a functional workaround.