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.
[jwnz@ordinaattori ~]$ sdk-assistant create SailfishOS-latest-aarch64 http://releases.sailfishos.org/sdk/targets/Sailfish_OS-latest-Sailfish_SDK_Target-aarch64.tar.7z
Creating target [SailfishOS-latest-aarch64]
Using tarball [http://releases.sailfishos.org/sdk/targets/Sailfish_OS-latest-Sailfish_SDK_Target-aarch64.tar.7z]
Do you want to continue? (y/n) y
Downloading 'Sailfish_OS-latest-Sailfish_SDK_Target-aarch64.tar.7z'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 151M 100 151M 0 0 1982k 0 0:01:18 0:01:18 --:--:-- 1772k
INFO: md5sum matches - download ok
Unpacking target ...
No suitable tooling found for this target
Note that while SDK targets are target-cpu specific, SDK toolings are always i486 which is the only supported host platform.
I meant what I said.
Ah, yeah, that’s different I think. I think it’s usually caused by mismatch of version between tooling and the target you downloaded.
grep VERSION= /srv/mer/toolings/SailfishOS-latest/etc/os-release
VERSION="4.0.1.48 (Koli)"Oh, wow, there is a tooling folder but it is empty. 
So it literally was missing, just in a different way than I expected.
[mersdk@SailfishSDK SailfishOS-4.1.0.23EA-armv7hl]$ ls /srv/mer/toolings/SailfishOS-
SailfishOS-3.3.0.16/ SailfishOS-4.0.1.48/ SailfishOS-4.1.0.23EA/
[mersdk@SailfishSDK SailfishOS-4.1.0.23EA-armv7hl]$ ls /srv/mer/toolings/SailfishOS-4.1.0.23EA/etc/os-release
/srv/mer/toolings/SailfishOS-4.1.0.23EA/etc/os-release
[mersdk@SailfishSDK SailfishOS-4.1.0.23EA-armv7hl]$ grep VERSION= /srv/mer/toolings/SailfishOS-4.1.0.23EA/etc/os-release
VERSION="4.1.0.23 (Kvarken)"
I used the SDKMaintenance tool to install the targets - I managed it from 2nd try
Using SDKMaintenanceTool is fine, if one likes graphical tools, clicking with mouse etc.
If one does not want to move the hands from the keyboard, installing targets is also possible with sfdk. E.g.
sfdk tools install SailfishOS-4.1.0.23EA-aarch64
as discussed earlier PA 15.0 is progressing aswell, and 15.0-rc1 has been released now, including support for multiple bluetooth A2DP audio codecs, and also higher quality HFP mode using mSBC (Wide Band Speech / WBS) codec.
https://lists.freedesktop.org/archives/pulseaudio-discuss/2021-May/032082.html
Just read it. Thanks!
Summary, not up to par with Jack yet, but getting there. As a long time Jack (and core audio) programmer, I’m keen to see where this goes.
But I also have rock steady pulse / jack integration (mostly for dynamic audio installation stuff with super collider). Might be a thing, eh
Little bit off topic, but I had to respond to this…
I have a lot of linux software that doesn’t work anymore. Buy some software, and just 3 years later, it isn’t compatible anymore. Backwards compatibility is a bitch on linux. On windows, just by comparison, most XP software is still able to run on windows 10. Linux software must be actively maintained or you are screwed.
So yeah, without sarcasm: Yipee, flatpacks. Flatpacks solve this and many more problems. Ok, I could get older dependencies (if the repos are still online) and put them into a folder, set the variables and chroot into it, but flatpacks are a lot easier and nicer.
I see your name now and then on this forum and in the stores, and I got a lot of respect for your skills and contributions. But don’t let those blind you to other peoples problems. Flatpacks solve big problems.
Well, I know what you mean, in theory. And I have no credibility by virtue of being here.
But, big but, as a person who sunk a lot of money into apple software and went from 8080 to powerpc, bought the upgrades and finally gave up on ‘backward’ compatible (wasn’t, it was upgrade or die) I have to agree to disagree. Over the course of 30 years (first mac 1986, last mac 2007)… I put 10s of thousands into mac hardware and software. That I regret.
There are linux systems I built 10 years ago which i still use. They are kinda ‘air gapped’ media machines but they ‘just work’ ™. So I froze them in time in the awareness that ‘change is not always good’. I have a mulitrack recording system that still runs on linux. Although, to be honest, I switched to hardware for ‘all that’ (Tascam multi-track).
Flatpak is fine under two conditions.
I used to do Mac OSx development and have some experience with the ‘freedom’ of just packing all your dependancies in a directory … And sometimes there really is ‘no other way’. But it is just as much a burden. At the moment, for me that burden is knowing that I don’t have debian, ubuntu, arch or redhat security teams auditing what is happening with my crypto messengers.
So you tell me. Make it possible/easy to install mirage even on an older Ubuntu (say 18). Now, I communicate over channels where security is, well, paramount. With flatpak installs, I have extra responsibility to make sure I don’t compromise them. that’s ok for me, cause it’s my job anyway. But I’m not sure it’s such a good idea for people who ‘just want it to work’. I’m not saying that’s you, but I do know a lot of people even in Linux Land who are that way.
So, in summary, I’m not against flatpak, per se. I just find it dangerous. I’m willing to live with that. On the Sailfish front, I can’t imagine using it, because it would swamp my root partition in no time.
Update: so, I think that flatpak uses so much space because it doesn’t remove installed dependencies
correctly:
no way that the two apps in question require:
org.freedesktop.Platform.GL.default/x86_64/19.08 system,runtime
org.freedesktop.Platform.GL.default/x86_64/20.08 system,runtime
org.freedesktop.Platform.VAAPI.Intel/x86_64/18.08 system,runtime
org.freedesktop.Platform.VAAPI.Intel/x86_64/19.08 system,runtime
org.freedesktop.Platform.VAAPI.Intel/x86_64/20.08 system,runtime
org.freedesktop.Platform.html5-codecs/x86_64/18.08 system,runtime
org.freedesktop.Platform.openh264/x86_64/2.0 system,runtime
org.kde.KStyle.Adwaita/x86_64/5.12 system,runtime
org.kde.KStyle.Adwaita/x86_64/5.14 system,runtime
org.kde.KStyle.Adwaita/x86_64/5.15 system,runtime
org.kde.Platform/x86_64/5.12 system,runtime
org.kde.Platform/x86_64/5.14 system,runtime
org.kde.Platform/x86_64/5.15 system,runtime
Seems like at least one too many?
That’s a completely different sound than the message I quoted. Not that it matters, but I agree with most you said right now. I’ll keep it at that, to not sidetrack this topic any further.
To get on topic: When I first heard about pipewire I was thrilled. I really dislike pulseaudio, and jack is not supported by some apps I most use, so a better alternative is very welcome.
For SFOS I think it is not necessary. I never do much advanced audio configuration on my phone, and it is not what the device is meant for.
I hope in a few years pipewire will gradually replace pulseaudio everywhere, with applications dropping PA support. By that time, I hope sailfish will be ready to make the switch as well.
Yeah, I’m ‘all over the place’. I like to think it’s human, but sometimes I’m just tired. And I dislike redhat. And systemd, for that matter. But I’m just a kranky old guy. I flip between rabid revulsion and enlightened reflection. sorry.
I think I made it plain, above, that I’m also interested in the development of pipewire. But I’m a jack poweruser so I’m fine with alsa+jack. My next project for Sailfish is an SDL2 based softsynth. Sailfish needs a softsynth. and a proper rythm generation thing …