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 …
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?
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.
Big problem is comparing the two Windows and Linux. Perhaps you upgrade too often. There is a rule: do not touch a running system
You might find these interesting… Sporth
and GitHub - thi-ng/synstack: Modular soft synth & Forth based VM for audio DSL experiments
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!
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
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.
why, is something not working that pipewire will do better while working as well the rest of the time?
Heh. Although I hate pulse, one of my jack + pulse setups has been solid for a number of years. That’s on a thinkpad with an 8 channel USB mixer. I have my own jack pre up and so scripts but I have seamless sound from desktop apps multi-channel audio apps. It took a long time to start feeling like apple core audio (which I also used for many years). but for the past 3-4 years it’s been just fine.
The biggest problem in that list seems this one:
Which can be seen also as a “feature” rather than a “bug”. I mean, imagine that a well-know distribution decides to move forward and adopt PipeWire. Are they going to complete this gap or are they going to fix the most important and/or used applications in order they do not abuse API?
The second one, will bring much more value for a lot of projects. Hence, it will attract much more people working on the goal. Which would not just adapt PipeWire to the status-quo but improve PipeWire to be the standard and the status-quo evolves to adapt to it.
This would be a HUGE improvement overall. Because, the day someone will decide to create a better replacement for PipeWire, s/he will not face this lack of API standardization usage. Which, after all, it is another form in which fragmentation presents itself or in others words the result of a kind of fragmentation.
Reducing fragmentation by standardization always brings value and usually it is a HUGE step forward in quality and quality assurance. Some markets, like automotive, definitely needs this.
Certainly true. The reason I’m still a bit uncertain about pipewire is that they ignore gstreamer completely when claiming to be the only game in town. Unifying Pulse and Jack is a welcome proposition (though, works for me after many years of just shutting off pulse). Replicating all the gstreamer (or libav) stuff were video is concerned? I’m sceptical.
It is always the same story. A project starts from scratch and no one has the gut to say: in some specific case / areas, our project should act like just a transparent proxy. At least, until it is reasonably working, set the option “proxing” on ON and redirect the API calls to the real libgstreamer or libav.
Now, tell me why? (your opinion or your guess, as well is fine for me)
Well, they imply they’re building from the ground up to allow using polkit to deal with ‘security’. And something about flatpak (yech). Not sure I buy it.
