~mil/sxmo-devel

This thread contains a patchset. You're looking at the original emails, but you may wish to use the patch review UI. Review patch
10 6

[PATCH sxmo-utils] fix audio controls when using pipewire

Details
Message ID
<20211013014700.10018-1-anjan@momi.ca>
DKIM signature
pass
Download raw message
Patch: +17 -23
patch requires pipewire and pulseaudio-utils
---
 scripts/core/sxmo_audioout.sh | 20 +++++++++++---------
 scripts/core/sxmo_vol.sh      | 20 ++++++--------------
 2 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/scripts/core/sxmo_audioout.sh b/scripts/core/sxmo_audioout.sh
index a06e9b8..fb8e91a 100755
--- a/scripts/core/sxmo_audioout.sh
+++ b/scripts/core/sxmo_audioout.sh
@@ -5,20 +5,22 @@ ARG="$1"
# shellcheck source=scripts/core/sxmo_common.sh
. "$(dirname "$0")/sxmo_common.sh"

SPEAKER="${SPEAKER:-"Line Out"}"
HEADPHONE="${HEADPHONE:-"Headphone"}"
EARPIECE="${EARPIECE:-"Earpiece"}"
# need to apk add pulseaudio-utils

amixer set "$SPEAKER" mute
amixer set "$HEADPHONE" mute
amixer set "$EARPIECE" mute
# Phonesink name use `pactl list sinks`
PHONESINK="${PHONESINK:-"alsa_output.platform-sound.HiFi__hw_PinePhone_0__sink"}"

# can be found with `pactl list sinks | grep Out`
SPEAKER="${SPEAKER:-"[Out] Speaker"}"
HEADPHONE="${HEADPHONE:-"[Out] Headphones"}"
EARPIECE="${EARPIECE:-"[Out] Earpiece"}"

if [ "$ARG" = "Speaker" ]; then
	amixer set "$SPEAKER" unmute
	pactl set-sink-port "$PHONESINK" "$SPEAKER"
elif [ "$ARG" = "Headphones" ]; then
	amixer set "$HEADPHONE" unmute
	pactl set-sink-port "$PHONESINK" "$HEADPHONE"
elif [ "$ARG" = "Earpiece" ]; then
	amixer set "$EARPIECE" unmute
	pactl set-sink-port "$PHONESINK" "$EARPIECE"
fi

sxmo_statusbarupdate.sh
diff --git a/scripts/core/sxmo_vol.sh b/scripts/core/sxmo_vol.sh
index af32bde..35254d8 100755
--- a/scripts/core/sxmo_vol.sh
+++ b/scripts/core/sxmo_vol.sh
@@ -5,36 +5,28 @@
. "$(dirname "$0")/sxmo_common.sh"

notify() {
	VOL="$(
		amixer get "$(sxmo_audiocurrentdevice.sh)" |
		grep -oE '([0-9]+)%' |
		tr -d ' %' |
		awk '{ s += $1; c++ } END { print s/c }'  |
		xargs printf %.0f
	)"
	# TODO: fix notifications
	dunstify -i 0 -u normal -r 998 "♫ Volume" "$VOL"
	sxmo_statusbarupdate.sh
}

up() {
	amixer set "$(sxmo_audiocurrentdevice.sh)" 1%+
	pactl set-sink-volume @DEFAULT_SINK@ +1%
	notify
}
down() {
	amixer set "$(sxmo_audiocurrentdevice.sh)" 1%-
	pactl set-sink-volume @DEFAULT_SINK@ -1%
	notify
}
setvol() {
	amixer set "$(sxmo_audiocurrentdevice.sh)" "$1"%
	pactl set-sink-volume @DEFAULT_SINK@ "$1"%
	notify
}
mute() {
	sxmo_audiocurrentdevice.sh > /tmp/muted-audio.dev
	amixer set "$(cat /tmp/muted-audio.dev)" mute
	pactl set-sink-mute @DEFAULT_SINK@ 1
	notify
}
unmute() {
	amixer set "$(cat /tmp/muted-audio.dev)" unmute
	pactl set-sink-mute @DEFAULT_SINK@ 0
	notify
}

-- 
2.32.0

[sxmo-utils/patches/.build.yml] build failed

builds.sr.ht <builds@sr.ht>
Details
Message ID
<CEXWG6TXSR1D.1K43KPJMT0QM4@cirno2>
In-Reply-To
<20211013014700.10018-1-anjan@momi.ca> (view parent)
DKIM signature
missing
Download raw message
sxmo-utils/patches/.build.yml: FAILED in 17s

[fix audio controls when using pipewire][0] from [Anjandev Momi][1]

[0]: https://lists.sr.ht/~mil/sxmo-devel/patches/25669
[1]: anjan@momi.ca

✗ #606827 FAILED sxmo-utils/patches/.build.yml https://builds.sr.ht/~mil/job/606827
Details
Message ID
<3O36Y0AD4EM6X.3SO3RIF5DWNPP@stacyharper.net>
In-Reply-To
<20211013014700.10018-1-anjan@momi.ca> (view parent)
DKIM signature
pass
Download raw message
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 ?
Details
Message ID
<87k0iglnhv.fsf@navi>
In-Reply-To
<3O36Y0AD4EM6X.3SO3RIF5DWNPP@stacyharper.net> (view parent)
DKIM signature
pass
Download raw message
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
Details
Message ID
<9CB43F74-88B0-47CE-B002-67AC1BF2E69E@disroot.org>
In-Reply-To
<87k0iglnhv.fsf@navi> (view parent)
DKIM signature
pass
Download raw message
(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
Details
Message ID
<2T50MZRBHCPV4.2J77DFVY1O620@stacyharper.net>
In-Reply-To
<87k0iglnhv.fsf@navi> (view parent)
DKIM signature
pass
Download raw message
> 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.
Details
Message ID
<20211014191716.cedpdt7qqclnwegp@worker.anaproy.lxd>
In-Reply-To
<2T50MZRBHCPV4.2J77DFVY1O620@stacyharper.net> (view parent)
DKIM signature
missing
Download raw message
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
Details
Message ID
<CEZFUODB9W9A.1CWX6PPE2P8DY@t450>
In-Reply-To
<20211014191716.cedpdt7qqclnwegp@worker.anaproy.lxd> (view parent)
DKIM signature
pass
Download raw message
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.
Details
Message ID
<AB204324-499D-4B95-A525-44AC736CBD5D@disroot.org>
In-Reply-To
<CEZFUODB9W9A.1CWX6PPE2P8DY@t450> (view parent)
DKIM signature
pass
Download raw message
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.
>
Details
Message ID
<87bl3pl8e1.fsf@navi>
In-Reply-To
<AB204324-499D-4B95-A525-44AC736CBD5D@disroot.org> (view parent)
DKIM signature
pass
Download raw message
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
Details
Message ID
<2IJ2JF9EDR4MG.2SVSOWQ1OG82Q@stacyharper.net>
In-Reply-To
<87bl3pl8e1.fsf@navi> (view parent)
DKIM signature
pass
Download raw message
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).
Reply to thread Export thread (mbox)