Open mazunki opened 2 years ago
Can you provide a full trace log? The output of ALSOFT_LOGLEVEL=3 ALSOFT_DRIVERS=pipewire openal-info
.
Also, try latest master. Audio/Duplex
devices are now handled.
I was looking at it some more afterwards, and found the loglevel variable after digging through the source code. Would be nice if alsoft-info --help
had that info too.
Anyway, I saw the "Got default %s device"
appeared correctly, followed by detection of some other devices, similar to below, yet after displaying the new devices it displayed the wrong "Default %s device"
, but otherwise everything else seemed okay.
After updating to new version,
$ ALSOFT_DRIVERS=pipewire ALSOFT_LOGLEVEL=3 telegram-desktop
...
[ALSOFT] (II) Got duplex device "both-me-and-others"
[ALSOFT] (II) "Sharing is caring" = ID 30
[ALSOFT] (II) Device ID 30 sample rate: 44100 (range: 1 -> 2147483647)
[ALSOFT] (II) Device ID 30 got 2 positions for Stereo
[ALSOFT] (II) Got duplex device "others"
[ALSOFT] (II) "The outside world" = ID 31
[ALSOFT] (II) Device ID 31 sample rate: 44100 (range: 1 -> 2147483647)
[ALSOFT] (II) Device ID 31 got 2 positions for Stereo
[ALSOFT] (II) Got duplex device "only-me"
[ALSOFT] (II) "Voices in my head" = ID 32
[ALSOFT] (II) Device ID 32 sample rate: 44100 (range: 1 -> 2147483647)
[ALSOFT] (II) Device ID 32 got 2 positions for Stereo
[ALSOFT] (II) Got default playback device "only-me"
[ALSOFT] (II) Got default capture device "others"
[ALSOFT] (II) Got source device "alsa_input.usb-0c76_USB_PnP_Audio_Device-00.capture.0.0"
[ALSOFT] (II) "USB PnP Audio Device" = ID 75
[ALSOFT] (II) Device ID 75 sample rate: 48000
[ALSOFT] (II) Got sink device "alsa_output.pci-0000_0e_00.4.playback.0.0"
[ALSOFT] (II) "Starship/Matisse HD Audio Controller" = ID 109
[ALSOFT] (II) Device ID 109 sample rate: 48000 (range: 44100 -> 192000)
[ALSOFT] (II) Got source device "alsa_input.pci-0000_0e_00.4.capture.0.0"
[ALSOFT] (II) "Starship/Matisse HD Audio Controller" = ID 73
[ALSOFT] (II) Device ID 73 sample rate: 48000 (range: 44100 -> 192000)
[ALSOFT] (II) Got sink device "alsa_output.pci-0000_0e_00.4.playback.1.0"
[ALSOFT] (II) "Starship/Matisse HD Audio Controller (ALC1220 Digital)" = ID 90
[ALSOFT] (II) Device ID 90 sample rate: 48000 (range: 32000 -> 192000)
[ALSOFT] (II) Got source device "alsa_input.pci-0000_0e_00.4.capture.2.0"
[ALSOFT] (II) "Starship/Matisse HD Audio Controller (ALC1220 Alt Analog)" = ID 135
[ALSOFT] (II) Device ID 135 sample rate: 48000 (range: 44100 -> 192000)
Voices in my head
Sharing is caring
The outside world
Starship/Matisse HD Audio Controller (ALC1220 Digital)
Starship/Matisse HD Audio Controller
Available capture devices:
The outside world
Sharing is caring
Voices in my head
Starship/Matisse HD Audio Controller
USB PnP Audio Device
Starship/Matisse HD Audio Controller (ALC1220 Alt Analog)
Monitor of Starship/Matisse HD Audio Controller (ALC1220 Digital)
Monitor of Starship/Matisse HD Audio Controller
Default playback device: Voices in my head
Default capture device: The outside world
...
This looks promising. From openal-info
everything seems to be in order... but.
When I try to use it in Telegram Desktop it now displays the duplex nodes, with the proper description label, yay! Regardless, setting the input/output to "Default device" still uses the wrong devices. I'm not entirely sure how to debug whether or not this is a bug in Telegram or here. I could test some other apps, if you know about some.
I can confirm ALSOFT_DRIVERS=pipewire mpv .
uses the default device correctly, when built with USE='openal -alsa'
.
Thanks for the help, I will report to Telegram.
Perhaps I was too quick on my toes. The output device had been working already, the problem was with input. Got to keep testing the source device.
The current problem of openal pipewire backend is that it sets target.object
to the object.serial
of default.audio.sink
, which is a number. I can't match object.serial
of a node in pipewire stream.rules
because it changes over time.
default.audio.sink
on my system is null-sink
which is useless.
In pipewire stream.rules, I have a rule for assigning default-sink
to target.object
if target.object
is missing for a new stream.
If openal pipewire backend just doesn't set target.object
when it wants the default, target.object
will be chosen by pipewire stream.rules
.
Just don't set target.object
if openal wants the default.
Because of the current openal behavior, I had to configure openal to use pulseaudio backend which works correctly.
I am running the current upstream version of OpenAL, which has (some) support for Pipewire, on Gentoo.
I have a set of duplex devices which act as my default nodes, which I then link up to my physical I/O devices.
When using
ALSOFT_DRIVERS=pipewire openal-info
it does not seem to care about mydefault.configured.audio.source
. It works fine if I useALSOFT_DRIVERS=pulse
, and in that case even displays my customnode.description
labels.I am guessing this is simply not implemented yet, and thus will fall back to PulseAudio as my driver until it is implemented.
Following are some relevant infodumps:
pipewire.conf
Pipewire output
ALSA output
Pulse output: