PipeWire replacing pulseaudio

Platform Development
#21 
[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.

#22

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)"
#23

Oh, wow, there is a tooling folder but it is empty. :smiley:
So it literally was missing, just in a different way than I expected.

#24 
[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

#25

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

2 Likes
#26

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

#27

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 :slight_smile:

2 Likes
#28

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.

2 Likes
#29

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.

  1. Desktop with lots of space (for 2 apps, I have 3.5G being used, that’s just for io.github.mirukana.mirage and io.github.NhekoReborn.Nheko).
  2. you have the time to spend doing security updates ‘outside’ the usual channels (apt update, etc).

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.

#30

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?

1 Like
#31

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.

#32

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 …

#33

Yeah, jack is great. I’ve yet to make ardour work with pipewire.
Why does SFOS need a softsynth? And is pipewire not a better jack alternative than PA?

#34

I often (well, before the pandemic home office) make music on my commute to the office. Usually i use one of my small synths or a pocket operator. But I’d like to also be able to do some sound design/synthesis on the way to work. I have a two hour daily commute, three times a week.

I do not know if pipewire is better than PA. PA has been suck but as pasik put it above, improvements keep being made. On the machine I’m typing with I have ardour running with jack and pulse streaming into jack from the webbrowser. Although I don’t do that very often. Jack syncs with pulse started working reliably about 3 or 4 years ago, but I admit it’s more a novelty thing.

As I mentioned, I have frozen in time machines for ‘real’ audio work and a dedicated multi-track tascam. I also use mostly home built hardware based on Axoloti, my own analog designs and the Mozzi lib running on arduino clones. Oh. And saxophones, drum kits (2), guitars, trombones, etc.

So, I don’t have an OS dependency for audio production anymore. I did 8 channels (with bob/firewire a presonos device) for about 3 years on linux but that was a period where I couldn’t focus on music enough anyway).

Now I’m derailing this thread. Sigh. Sorry.

#35

Big problem is comparing the two Windows and Linux. Perhaps you upgrade too often. There is a rule: do not touch a running system

1 Like
#36

You might find these interesting… Sporth
and GitHub - thi-ng/synstack: Modular soft synth & Forth based VM for audio DSL experiments

#37

Bloody weird. I’m just implementing a stack machine on Arduino. Started this morning. That’s weird timing. Thanks a bunch! I hadn’t seen this!

#38

now as pipewire has become quite mature and more distros have switched to it by default, it would be nice to see pipewire coming to SailfishOS

5 Likes
#39

The problems are still obviously the same, while there isn’t any advantage for SFOS. 99% of pipwire still works by imitating pulse, BT HQ codec support implementation in PA is imho better & there are no people that currently run Jack on SFOS and would profit from an easier way to do this.

3 Likes
#40

why, is something not working that pipewire will do better while working as well the rest of the time?