Watch
1
0
Fork
You've already forked SouveraineOS
0

task-39: profile selection is state-machine work, not a pactl poke

The card was stuck in the modem call profile, so audio came out of the earpiece
and read as a weak speaker. Restoring HiFi is manual; classifying when each
profile is wanted is the actual task. Also notes that the device runs pipewire
while pipewire-abi-provider claims PulseAudio owns the stack.
This commit is contained in:
Fimeg 2026-08-02 08:12:44 -04:00
commit 5f53bf7396

View file

@ -114,3 +114,24 @@ should come out of the role model, not go into it.
`AUDIO-PRIVACY.md` (the lock-tier half), `SETTINGS-AUTHORITY.md`,
TASK-08 (device state manager — and the question of whether audio belongs in
it at all), TASK-19 (settings/control centre — where roles would surface).
## Profile selection belongs in the state machine (raised 2026-08-01, Casey)
The card sat in **`Voice Call (Earpiece, Mic)`** instead of `HiFi`, so every
sound came out of the earpiece rather than the `Both CS35L36 amps, speakerphone`
port, and it read as "the speaker got weaker". A `pactl set-card-profile ... HiFi`
restores it and wireplumber persists the choice — but that is a manual poke, and
the profile got there because a wireplumber restart re-ran selection with no
notion of what the device was *for* at that moment.
Casey's framing: the device has to know **when** a profile is needed and carry a
proper classification for them, the way Android and iOS do — in-call vs media vs
speakerphone vs headset, with the routing following the classification rather
than whatever priority number happened to win. That is state-machine work and
belongs with audio-as-state, not a udev rule or a login hook.
Worth knowing before designing it: `pkgs/pipewire-abi-provider/PKGBUILD` asserts
that **native PulseAudio owns the phone audio stack** and `conflicts`/`replaces`
pipewire, pipewire-audio and wireplumber — while the device is in fact running
pipewire, pipewire-pulse and wireplumber. Reconcile which is true before
building policy on either.