Ed Greshko writes:
On 17/11/2021 19:58, Sam Varshavchik wrote:
> Ed Greshko writes:
>
>> On 17/11/2021 07:27, Sam Varshavchik wrote:
>>> One of my servers was rebooted two times, so far, since the update to F35.
>>>
>>> There's no audio after each reboot. First time: after some scrambling
>>> around, I found that I simply have to switch to "Built-In Analog
Stereo" in
>>> XFCE's (my desktop) audio mixer. Fine, so I wrote it off as a result of a
>>> one-time update to Pipewire.
>>>
>>> But this happened again, after the 2nd reboot.
>>>
>>> I saw nothing in audio mixer which lets me permanently set my default audio
>>> out.
>>>
>>> I searched for "pipewire default audio device" and "pipewire
save default
>>> audio device" but didn't find anything useful. After browsing some
random
>>> links I found mentions of a "pactl" command, so after reading its
man page:
>>>
>>> $ pactl list short sinks
>>> 41 alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
>>> PipeWire s16le 2ch 48000Hz SUSPENDED
>>> 42 alsa_output.pci-0000_00_1b.0.analog-stereo PipeWire s32le 2ch
>>> 48000Hz SUSPENDED
>>>
>>> After a reboot:
>>>
>>> $ pactl get-default-sink
>>> alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
>>>
>>> Fail.
>>>
>>> $ pactl set-default-sink alsa_output.pci-0000_00_1b.0.analog-stereo
>>>
>>> Now I have audio again.
>>>
>>> After logging out and back in, the default audio is unchanged. But it gets
>>> reset after every reboot. After scratching my head, I looked deeper and
>>> discovered that pactl is pulseaudio, but my understanding is that F35
>>> switched to something called "pipewire".
>>>
>>> More digging uncovered the existence of pw-cli. However its man page is
>>> sparse, and after starting it the "dump" and "list
objects" command produced
>>> a ton of incomprehensible output. "help" didn't seem to have
much help to
>>> say in terms of selecting and saving, permanently, the default output
>>> device. Wouldn't you think that this should be pretty basic, elementary
>>> stuff that any audio framework should put in front of the user, in a very
>>> visible way? But I guess not.
>>>
>>> So, anyone knows how to set the permanent default output device?
>>
>> No. But I do have a question.
>>
>> If you boot the system with the USB device disconnected, and then login, I
>> assume sound works with the pci
>> device.
>>
>> Then, if you plug in the USB device does it take over from the pci device?
>
> No, it does not.
>
> $ pactl list short sinks
> 40 alsa_output.pci-0000_00_1b.0.analog-stereo PipeWire s32le 2ch
> 48000Hz SUSPENDED
> 55 alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
> PipeWire s16le 2ch 48000Hz SUSPENDED
>
> Only the first entry, the built-in audio jack, came up after a reboot, and
> that's where the audio went by default. Plugging back the USB-Audio adapter
> did not change the default audio-out.
So, you get the audio where you want it if you boot with the device
disconnected.
Sure. There aren't any options in that case, only one audio device.
Have you checked the journal or dmesg to maybe see what is happening
when
the system is booted with the device connected?
I have about 1500 lines in dmesg after a reboot. Random greps were not very
useful, no hits on "alsa", or anything.
The USB device is announcing its presence very early on, a few seconds into
the boot.
[ 1.857177] usb 3-1: Product: USB Audio CODEC
[ 1.861220] input: Burr-Brown from TI USB Audio CODEC as
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.3/0003:08BB:
2902.0002/input/input3
[ 1.912906] hid-generic 0003:08BB:2902.0002: input,hidraw1: USB HID v1.00
Device [Burr-Brown from TI USB Audio CODEC ] on usb-0000:00:1a.
0-1/input3
The first mention that I can find, of the built-in audio out, is 27 seconds
after boot.
[ 27.999140] input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1b.
0/sound/card0/input6
[ 27.999791] input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:1b.
0/sound/card0/input7
[ 28.000355] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.
0/sound/card0/input8
[ 28.001048] input: HDA Intel Line Out Front as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[ 28.001991] input: HDA Intel Line Out Surround as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[ 28.002675] input: HDA Intel Line Out CLFE as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[ 28.003455] input: HDA Intel Line Out Side as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input12
[ 28.004254] input: HDA Intel Front Headphone as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input13
[ 28.005076] input: HDA Intel SPDIF as /devices/pci0000:00/0000:00:1b.
0/sound/card0/input14
And that's the only mention of it.
I don't really see anything here referencing anything in userspace, like
alsa or pipewire. The last grep that I could find returned one more line, 30
seconds after boot:
[ 30.289470] usbcore: registered new interface driver snd-usb-audio
But I do have some fingers to point at userspace, rather than anything at
the kernel level. I still had the last F34 kernel installed
(5.14.15-200.fc34.x86_64), booted that, and still got the wrong audio by
default. Unless I suffered in stroke this worked in F34. The first time I
was aware of this problem is the first boot after the update to F35.
Anyway, the server auto-logins to my desktop, but I was booting it, and
attempting to ssh into it. As soon as it started replying to pings I started
trying to ssh in, and as soon as I got in:
$ pactl get-default-sink
@DEFAULT_SINK@
A little bit later, after everything came up:
$ pactl get-default-sink
alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo
So, it looks to me like userspace is getting it wrong.
I have a very, very dim recollection that after I updated to F34, which I
believe was the first release that switched to pipewire, I had the wrong
audio defaulted, but after I fixed it in audio mixer, it stuck from that
point on. So, either:
1) It used to be that alsa or pipewire remembers your default audio out and
tries to preserve this, but this doesn't work any more, or
2) Nothing is actually memorizing/saving the default audio out to
preserve it, but the heuristics that set the initial default audio out after
boot are now getting it wrong.
I do see an available pipewire update now, maybe I'll try it over the
weekend…