Hi,
bjc <[email protected]> writes:
[...]
>> Yeah, it'd be nice to have some fields to add drop-in configs for
>> pipewire and wireplumber to extend it more easily, and maybe rename that
>> extra-content field to something more descriptive (asoundrc?).
>
> since i wrote it, i'll say that i probably made a mistake calling that
> field ‘extra-content’, instead of ‘extra-asoundrc-content’. i think it
> probably makes sense to create a field for pipewire and wireplumber
> config extras.
>
> maybe deprecate ‘extra-content’ to replace with ‘extra-asoundrc-content’
> and add new fields for ‘extra-{pipewire,wireplumber}-content’?
>
> wdyt?
That would be a good start!
>> So my solution now looks like this:
>>
>> # file: ~/.config/pipewire/pipewire.conf.d/10-sample-rates.conf
>
> should we have a mechanism in home-pipewire-config for this kind of
> rc.d/udev configuration file types? my knee-jerk reaction would be that
> it's not worth it, and we should be using
> home-xdg-configuration-files-service-type.
I'd see two benefits for drop-ins support: the main pipewire.conf could
stay in the store instead of being copied/appended with an
extra-pipewire-content (like asoundrc is), which is a bit
simpler/cleaner, and having the fields documented on
home-pipewire-configuration along some examples would help discovery for
users trying to figure out the best way to extend their pipewire
config. We have such an example in the pulseaudio-configuration record
(called extra-script-files, see (info "(guix) Sound Services")).
That said, an example showing how to do the same via
home-xdg-configuration-files-service-type (which I hadn't seen/used yet)
could be fine as well, I think (especially given that pipewire has a
system/global counterpart config under /etc/pipewire which would need to
be managed with something like etc-service-type).
>> And then 'herd restart pipewire' (and sometimes I have to follow with
>> 'herd restart wireplumber', as there seems to be a race) gives me a rate
>> that goes to 192 kHz when using the analog output of the ALC4080 when
>> playing hi-res FLAC or 96 kHz if using its SPDIF output instead.
>
> there shouldn't be a race here, as wireplumber depends on pipewire,
> shouldn't restarting pipewire auto-restart wireplumber? that's how it's
> working for me.
It depends on it yes, but there's nothing in our service that ensures
pipewire has successfully initialized before wireplumber starts, which I
think is why sometimes it doesn't pick up any real sink (outputs) and
shows a single null/void sink instead. You can try repeatedly 'herd
restart pipewire' and if you're lucky you'll see the problem (it's not
deterministic). On systemd systems perhaps that's handled via notifyd
or socket activation, if we aren't using this already in
home-pipewire-service.
> i'll note that i have to restart wireplumber sessions after it restarts
> for things like firefox which don't retry automatically.
The issue was lower level, as even something like 'wpctl list' wouldn't
show the actual (hardware) sinks when triggering the issue. But I can't
seem to reproduce it now.
--
Thanks,
Maxim
