Oh wow yes I just updated and it works again. Seems like I updated at the worst possible time... as always... sigh Anyways I think we should have the calling and sms logic NOT fail when sound is failing, and have a tiny backup plan, cause I wasn't able to receive calls nor SMS messages because of that error. Thanks for your time investigating this!

Just as an FYI, running pinephone on pmos edge and I do not experience this. That said, I didn't go through the normal ugrade process so maybe a package is missing. Will dig a little deeper.

On Sat, May 20, 2023 at 12:47:43PM +0000, ~euhmeuh wrote:

Oopsie, forgot to mention that's the pinephone on postmarketos edge.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-238924

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Oopsie, forgot to mention that's the pinephone on postmarketos edge.

What device is this?

On Fri, May 19, 2023 at 04:12:19PM +0000, ~euhmeuh wrote:

Hello ! I waited quite some time before updating to 1.13 because I know for sure I get issues when updating too soon... Alas, I still got screwed up by the update T_T

sxmo is unable to switch to callaudiod, which makes calls impossible, and I can't even hang up the call because the audio crash makes the hang up script fail too.

I investigated a little and found that the call to :

dbus-send --session --print-reply --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.freedesktop.DBus.Properties.Get string:org.mobian_project.CallAudio string:"AudioMode"

returns correctly uint32 0 (which means Normal mode)

but calling :

dbus-send --session --print-reply --type=method_call --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.mobian_project.CallAudio.SelectMode uint32:1

returns org.freedesktop.Dbus.Error.Failed: Operation failed

without further explanation...

I tried starting callaudiod myself with debug enabled like so : killall callaudiod && G_MESSAGES_DEBUG=all callaudiod

but it keeps spamming the logs with callaudiod-pulse-CRITICAL: No suitable card found, retrying in 3s...

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

The sound cards are correctly shown by alsa. I also did the pactl unload-module module-suspend-on-idle trick.

Also, I uninstalled sxmo-common-bluetooth, sxmo-common-audio-pipewire and installed sxmo-common-audio-pulse.

I also checked that pipewire was not running.

Any ideas ? That's kinda important for me to find a solution because I can't have phone calls at all right now :/

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Hello ! I waited quite some time before updating to 1.13 because I know for sure I get issues when updating too soon... Alas, I still got screwed up by the update T_T

sxmo is unable to switch to callaudiod, which makes calls impossible, and I can't even hang up the call because the audio crash makes the hang up script fail too.

I investigated a little and found that the call to :

dbus-send --session --print-reply --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.freedesktop.DBus.Properties.Get string:org.mobian_project.CallAudio string:"AudioMode"

returns correctly uint32 0 (which means Normal mode)

but calling :

dbus-send --session --print-reply --type=method_call --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.mobian_project.CallAudio.SelectMode uint32:1

returns org.freedesktop.Dbus.Error.Failed: Operation failed

without further explanation...

I tried starting callaudiod myself with debug enabled like so : killall callaudiod && G_MESSAGES_DEBUG=all callaudiod

but it keeps spamming the logs with callaudiod-pulse-CRITICAL: No suitable card found, retrying in 3s...

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

The sound cards are correctly shown by alsa. I also did the pactl unload-module module-suspend-on-idle trick.

Also, I uninstalled sxmo-common-bluetooth, sxmo-common-audio-pipewire and installed sxmo-common-audio-pulse.

I also checked that pipewire was not running.

Any ideas ? That's kinda important for me to find a solution because I can't have phone calls at all right now :/

I have the same issue. Every audio output option toggled during call are ignored, and audio still gets routed to earpiece.

Seems fixed in 1.8.2! Thanks!

Getting somewhere: It happens when the vis window is not in the first position in the workspace. Moving the "reply" window to another workspace makes the bug disappear.

Okay, I got more info : It actually happens when ANY window is already open in the current workspace. Which means even the workaround I was talking about previously can fail if there's a terminal window open. Which means it might not be a vis issue but maybe related to sway?

The only workaround I found for now is to make a detour through : Main menu > Text > Send text > Select the contact > Vis opens and works correctly. It only seems to happen with "Reply" and "Conversation" options.

By the way, I'm up to date with SWMO version 1.8.0