https://bugs.kde.org/show_bug.cgi?id=494120

Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |89q1r1...@relay.firefox.com

--- Comment #7 from Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> ---
First of all, I'm not trying to downplay the actual UX issue here or claim it's
all good or all bad, I'll only be explaining some of the story behind this
known mess.

[Backstory]
The profiles themselves are a PulseAudio idea in the form of the original ACP
profiles. That idea then got expanded upon by userspace ALSA project into UCM
profiles and then PipeWire also added its own Pro Audio and Off profiles, which
means that the concept of audio profiles itself is unique to Linux and the
meaning of some of these profiles (most notably Pro Audio) is non-obvious even
to audio engineers, unless they have read or otherwise learned about them.

[Where we at]
That being said, no one has come up with a better idea is some 20 years other
than maybe set devices to Pro Audio, forget about ACP/UCM and just have a
capable GUI (e.g. qpwgraph) and a daemon (e.g. WirePlumber) with custom rules
to route things as the user sees fit (another option is to use custom virtual
devices which is essentially a PW-JSON way to write profile without using ACP
or UCM syntax). I was running such a setup for a few months myself.

However this just replaces all the profile tentacles and underwater hazards
with directly exposing the potentially messy I/O of the actual hardware (some
of which may be badly labeled or even just floating pins that are not connected
to any physical port). Hardly an improvement to the average person but it might
be just what an audio producer would want (hence Pro Audio name).

[Where to]
Well, there is an alternative path in the sense we could have a KCM that sets
each device to either Pro Audio or Off profile and then allows users to
customize via GUI where each client gets routed or what virtual devices,
filters, etc are set up and can be used in the audio graph, which to me sounds
cool and unique but, again, the only way this would not be more of a UX
nightmare would be if that KCM was essentially reading the relevant UCM or ACP
profiles and re-creating them as the default config that users can then edit.
It should be doable and would be really cool but does that actually solve the
UX issues at hand?

Other ideas welcome.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to