PipeWire audio that just works and with pipewire-pulse an easy switch.
I expect it to be more tricky than replacing pulse on a desktop pc with all the stuff a mobile has to do. It seems to be the future though. But i also donāt expect it in SFOS anytime soon.
Legacy is always a heavy weight and the notion that something has to be break before it warrants a change. Fedora on a PinePhone can make calls with audio routed through PipeWire.
Does it use pipewire directly or its through pipewire-pulse?
I will have to look into it more. If my memory is correct then it was pipewire-pulse but then something was needed modifying to send signals back for ending calls etc.
I route pipewire (and pulse) through jack. depends on the os.
but then, I also do this:
echo "g(i,x,t,o){return((3&x&(i*((3&i>>16?\"BY}6YB6%\":\"Qj}6jQ6%\")[t%8]+51)>>o))<<4);};main(i,n,s){for(i=0;;i++)putchar(g(i,1,n=i>>14,12)+g(i,s=i>>17,n^i>>13,10)+g(i,s/3,n+((i>>11)%3),10)+g(i,s/5,8+n-((i>>10)%3),9));}"|gcc -xc -&&./a.out|aplay
And flatpak is a pipedream. I like it, but itās a pipedream. And yes, apples app bundles are old (I mean 1980s old) resource fork hacks. Remember those?
As far as Iām aware, SailfishOS relies heavily on some PulseAudio modules for the separate ringtone and media volume and high volume warnings. These would need to be ported to work with PipeWire, since as far as Iām aware, PipeWire is not directly compatible with PulseAudio modules, but feel free to correct me if Iām wrong.
I was just being cheeky Iāve been using jack with alsa since before the enlightened sound daemon. So I have to ask, why do we need pipewire?
The claim on the website is:
Seamless support for PulseAudio, JACK, ALSA and GStreamer applications.
If jack audio routing (or apple core audio like routing) works better ā¢ than pulseās routing (which took years to catch up to jack) then it might be interesting to me.
UPDATE: after reading https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3
Iād say weāre talking about years before prime time.
According to the pipewire āmarketingā it is supposed to cover both areas of Jack and Pulse (and AFAIK it had input on the design by the Ardour dev who also wrote jack i think).
Also it does redirection for video, handles Wayland screen capture stuff (which we need), also works with flatpack and i read it uses less cpu cycles. Thats all i know and sounds good.
It reaching prime time and being usable in SFOS is a different topic. Obviously if someone feels adventurous and knows the ins and outs of SFOS he can test stuff and see what works and what not.
What I gather reading Limitations page is that they have already dealt with most of them.
Nope. there is no way for me to run my jack based routing with what they currently have on offer without, basically, rewriting everything I have running?
The āreplacement daemonā for pulse solution begs the question, why replace it? This is all hot air until some distro gets behind it. I hated/hate pulse to this day (well, on machines that make music, it is ABSENT), so I expect someone to step on my toes so or so. Donāt care that much. Iām still using jack with supercollider on dedicated machines that have ZERO pulse stuff.
Oh. Fedora. Them.
GNOME 40! Yeah! ( Flatpaks with JACK will not work and need to be converted to use the replacement libjack.so
.) Yipee! All hail RED HAT! Oh wait, what will flatpacks do? Ah, welcome to cupertino!
You do realize that weāre dong QT here?
Ok, Iām working on a synth for SFOS ā¦ it is NOT going to support pipewire (obviously, Iām not going to support anything in that sense:). Itās going to be based on: https://github.com/poetaster/synth
Qt, Qt, I know. And flatpakās do Sailfish OS somewhat already.
@jwnz, I do not know you, but pls have understanding that there are people like me that want their device just working and we do not care if it is pulse or something else. BTW pulse with version > 12 is working pretty well and I do not see why you open this topic here.
You could try replacing pulse on your device (implies fixing all dependencies) then you have to convince Jolla and users like me to accept those changes.
If you are not able to do it yourself, please write a letter to Santa Claus
Here is some extra credit reading material on the subject.
One reason to switch to pipewire is better support for bluetooth codecs and support for switching profiles for answering calls.
Upcoming pulseaudio 15.0 does have bt codecs switching aswell. itās already merged, but release isnāt out yet. Also pa 15.0 will have support for higher quality backchannel/microphone via mSBC/WBS (Wide Band Speech).
There is a platform target release for aarch64 but none of the tooling yet, so at least today I can not build pipewire for Xperia 10 II outside of the phone. If I had 2 phones I could consider just building it in the other one. If pipewire were to be added IMO it should be on aarch64 only, so your device would go on working.
No need to convince anyone, I use it everyday so I am convinced and that is enough for me.
Opening this thread in Platform Development section of Sailfish OS seems quite appropriate. You are allowed to experience things your way. Lastly the only thing worth bothering Sinterklaas with is world peace.
What do you mean? You need tooling matching your host (x86) and target matching the device (aarch64) to build packages for the device.