Anjan we cannot just replace all control with pipewire ones :D
The user should be able to run vanilla alsa and be able to manage audio
volumes etc.
What we should do is detect if pipewire is running, then use dedicated
methods to do what we need.
Here is a commit I got in my tree that I use from months and months
https://git.sr.ht/~stacyharper/sxmo-utils/commit/0cfc0a91
I can basically change volume and it should still be compatible with
plain alsa.
What do you think about this ?
Stacy Harper <contact@stacyharper.net> writes:
> Anjan we cannot just replace all control with pipewire ones :D> The user should be able to run vanilla alsa and be able to manage audio> volumes etc.>> What we should do is detect if pipewire is running, then use dedicated> methods to do what we need.
Sorry if Im misunderstanding but we would do this if we wanted to
support users that want to use pipewire and users that only want to use
alsa. I think it's fine if we drop alsa support and package sxmo to
require pipewire.
The only thing not working is calling not respecting pipewire's output.
We should look into how phosh does their audio routing and compare it to
our megi C program.
Sincerely,
Anjandev Momi
--
w:] www.momi.ca
pgp:] https://momi.ca/publickey.txt
(just random thoughts about the sound in Sxmo that I've accumulated over time)
I'm not sure if we should completely drop ALSA, but I think that requiring PulseAudio or PipeWire in postmarketos-ui-sxmo will generally be a good idea. I'm not a fan of PulseAudio or PipeWire. TBH, I hate them, and I'm used to use pure ALSA setup on all my x86 devices, but sadly ARM is not the case. Most ARM SoCs has terrible UCM setups that makes it literally impossible to configure sound using alsa-utils. Even if it can be achieved, it will be SoC-specific.
Tl;dr: sound control will work only on PinePhone until there is proper PulseAudio or PipeWire support. IMO, it should be either the only way of configuring sound, or the preferred one, meaning that it will replace current ALSA menu if PulseAudio/PipeWire is installed. There ofc should be output device selection as well. I think it's easier to implement universally (for all devices) on sound server level rather than at ALSA UCM one.
On October 13, 2021 10:43:08 PM GMT+03:00, Anjandev Momi <anjan@momi.ca> wrote:
>>Stacy Harper <contact@stacyharper.net> writes:>>> Anjan we cannot just replace all control with pipewire ones :D>> The user should be able to run vanilla alsa and be able to manage audio>> volumes etc.>>>> What we should do is detect if pipewire is running, then use dedicated>> methods to do what we need.>>Sorry if Im misunderstanding but we would do this if we wanted to>support users that want to use pipewire and users that only want to use>alsa. I think it's fine if we drop alsa support and package sxmo to>require pipewire.>>The only thing not working is calling not respecting pipewire's output.>We should look into how phosh does their audio routing and compare it to>our megi C program.>>Sincerely,>Anjandev Momi
> I think it's fine if we drop alsa support and package sxmo to> require pipewire.
I strongly disagree on this point. We made lot of works to support
multiple windows managers by example. I dont see why we should only
support pipewire o_O
Plus that pipewire got alsa compatible apis. I already sent a patch that
allow us to control alsa and pipewire volume in the same time. So this
definitely is not something costy.
On 21-10-14 09:38, Stacy Harper wrote:
> > I think it's fine if we drop alsa support and package sxmo to> > require pipewire.>> I strongly disagree on this point. We made lot of works to support> multiple windows managers by example. I dont see why we should only> support pipewire o_O>> Plus that pipewire got alsa compatible apis. I already sent a patch that> allow us to control alsa and pipewire volume in the same time. So this> definitely is not something costy.
I agree with Stacy here yes, pipewire is fine as an option to support but it
shouldn't be a forced solution.
--
Maarten van Gompel (proycon)
https://proycon.anaproy.nl
I have an idea. (Sorry I'm just a lowly user, I don't really contribute
much so take that how you will).
On my personal systems, I have a script called "audiocontrol". Perhaps
we can create an "sxmo_audiocontrol.sh" script that will abstract that
away, so that we can use it wherever we need to do any control over
audio volumes and devices, eg. switching devices over from speakers to
headpones, or changing the volumes. This way, slowly, we can just add
whatever sound server people are using, whether that be ALSA, PipeWire,
or PulseAudio, or even OSS if people ever want to use it on a BSD for
whatever contrived reason.
I like the idea, but IMO it should be done outside of Sxmo, like lisgd. And also it's pretty hard to implement, especially ALSA, as every device out there has unique controls.
On October 15, 2021 12:17:44 AM GMT+03:00, Nathaniel Barragan <nathanielbarragan@protonmail.com> wrote:
>I have an idea. (Sorry I'm just a lowly user, I don't really contribute>much so take that how you will).>>On my personal systems, I have a script called "audiocontrol". Perhaps>we can create an "sxmo_audiocontrol.sh" script that will abstract that>away, so that we can use it wherever we need to do any control over>audio volumes and devices, eg. switching devices over from speakers to>headpones, or changing the volumes. This way, slowly, we can just add>whatever sound server people are using, whether that be ALSA, PipeWire,>or PulseAudio, or even OSS if people ever want to use it on a BSD for>whatever contrived reason.>
Ok, it seems the consensus is to not drop alsa only support. I'm just
throwing ideas out there so no worries. Here is my rationale though:
As the number of things we support increases, the complexity of the code
and chances of bugs increases. Furthermore, alsa is not very suitable
for a phone because a phone's audio configuration is much more complex than
other devices. Ie. phones need bluetooth support, multiple sources,
audio codecs, etc. All of which alsa has a hard time with.
Regardless, if the consensus is to not drop alsa support, I think that's
fine. It's just going forward, if we find a lot of bugs with supporting
both and it's giving us a large maintainer burden, dropping alsa is an option.
This is similar to the philosophy I had with the phone number regex issue -
we have to keep in mind the cost of maintaining the code since
the maintainers' time is valuable and we don't wanna keep trying to solve
the same problems.
Lets try to fix audio routing with pulse according to how phosh fixed
it, maintain alsa support, and go from there.
Hope this clears it up =)
--
w:] www.momi.ca
pgp:] https://momi.ca/publickey.txt
Ya I completly agree with you. I'm also perfectly okay if we dont have
the same feature in both cases (alsa/pipewire). We could extends
features in the pipewire scope while still allowing simplest things
with alsa.
The thing is that maintaining alsa support doesnt cost that much at this
point. And as I run pipewire from monthes and monthes, nothing looks
broken or complex to handle.
But this will very probably change when we will dig again in the
ongoing call audio logic. If we plan to improve it (I already plan to),
then maybe dropping alsa would be necessary (or at least, preferable).