LinuxMusicians

I'm sure PipeWire is working on real modern computer life problems (sandboxing, security), that world is in constant development of course, but it's approach is not particular KISS is seems. Like systemd is addressing real issues, but also it's approach is debatable (I leave that judgement to others). These kind of things are also dropped early, to make Linux users do the testing (with the suffering it comes with it).

Pipewire might be useful if you want to record Desktop stuff in your 'proaudio' session, but when does that happen? It might be useful to be able to use some cheap bluetooth devices in mobile setups and to fiddle around. Not all people who are making music with computers needs extreme low latency anyway.

Pipewire might make life easier when it just works, but when not, I'm afraid the complexity of it's design will hit you.

Anyway, the times that I jumped on this new developments early are gone. I solved these issues by buying a JBL Flip bluetooth device, selected via pulseaudio for listening to youtube videos when running jackd. A second soundcard will help as well.

grammo wrote: ↑Mon Mar 27, 2023 2:00 pm

I'm sure PipeWire is working on real modern computer life problems (sandboxing, security), that world is in constant development of course, but it's approach is not particular KISS is seems. Like systemd is addressing real issues, but also it's approach is debatable (I leave that judgement to others). These kind of things are also dropped early, to make Linux users do the testing (with the suffering it comes with it).

Pipewire might be useful if you want to record Desktop stuff in your 'proaudio' session, but when does that happen? It might be useful to be able to use some cheap bluetooth devices in mobile setups and to fiddle around. Not all people who are making music with computers needs extreme low latency anyway.

Pipewire might make life easier when it just works, but when not, I'm afraid the complexity of it's design will hit you.

Anyway, the times that I jumped on this new developments early are gone. I solved these issues by buying a JBL Flip bluetooth device, selected via pulseaudio for listening to youtube videos when running jackd. A second soundcard will help as well.

What do you think is complex about it, and what about its approach is debatable for you?

sysrqer wrote: ↑Mon Mar 27, 2023 2:30 pm

Pipewire might make life easier when it just works, but when not, I'm afraid the complexity of it's design will hit you.
What do you think is complex about it, and what about its approach is debatable for you?

I read it as saying that solving problems with pipewire is not necessarily easier than solving problems with pulseaudio or jack.

grammo wrote: ↑Mon Mar 27, 2023 2:00 pm

Pipewire might be useful if you want to record Desktop stuff in your 'proaudio' session, but when does that happen?

Well, I just posted a short guide to drive Rebirth RB338 (a windows standalone softsynth, running in Wine, necessitating the use of Pulseaudio afaik) with MusE (which needs Jack afaik). So there you have it!

Not saying that Pipewire would be more suited in this case than Jack+Pulseaudio by the way. I wouldn't know.

Run PipeWire on top of native JACK

PipeWire can also run as a JACK client on top of the native JACK daemon if desired.

See JACK and PipeWire for more information.

Haven't tied this, but they state it's possible...
So this would fix a lot of scenarios/fears debated in this thread...

Also, Pipewire is still SO young, we are still at Version 0.3.x , far away from 1.0....

https://gitlab.freedesktop.org/pipewire ... ses/0.3.68

The ALSA plugin has experimental support for IRQ based scheduling. This
should decrease latency for some (mostly USB) drivers. This should bring
latency within JACK latency. More work on this will be done before the
1.0 release later this year

They are working hard on it, give them some more time. Pulseaudio also had not the best reputation because of "too-early-release-desaster", alas that's how you are gonna find those nasty bugs in such a complex application without having a billion dollar company behind your back (as coreaudio had with Apple). And opposed to Pulseaudio it also does MIDI (and also Video)...

Pipewire for sure needs to mature a lot, it's in it's childhood.. But I am quite optimistic that it will be successful, it even seems we could have a 1.0 release that year I really like the comment where it was called an equivalent of coreaudio userspace part - if it can surpass that one on feature- and performance-level (and that's the goal), it could make a lot of people happy, if not, you apparently can still plug it into JACK

more fresh food on the topic: https://discourse.ardour.org/t/why-not- ... /108377/12

robin garaeus of ardour fame is currently less optimistic:

The actual problem that pipewire will fix is:

• to easily aggregate multiple soundcards
• provide seamless support when hotplugging devices
• have persistent names for sound-devices and ports (no more random order when using multiple audio or MIDI devices)
• support multiple buffer queues with different quality of service (allow to run low-latency Ardour and a high-latency Desktop sound app simultaneously)

That being said, I’m currently no longer convinced that the pipewire ecosystem will be the future. It became too complex, and ambitious with conflicting goals and repeated the mistakes pulseaudio made. It currently also does not scale as well as JACK, and as opposed to JACK also enforces policy.

revoxs wrote:

Pipewire does MIDI

And I see absolutely no reason why it should. MIDI (without a General MIDI engine) is strictly a music composer's tool. Pipewire is obviously geared for generic audio/video apps, plus has no plan to implement a built-in GM engine. Therefore, its current design of assuming responsibility for access to all MIDI devices is nothing more than disaster for all legitimate midi applications.

Bad design.

PipeWire can also run as a JACK client on top of the native JACK daemon if desired.

https://gitlab.freedesktop.org/pipewire ... ssues/2860
https://gitlab.freedesktop.org/pipewire ... ack-bridge
https://docs.pipewire.org/page_spa.html
https://gitlab.freedesktop.org/pipewire ... ugins/jack

SPA = Simple Plugin API. PipeWire uses SPA to implement the low-level multimedia processing plugins, device detection, mainloops, CPU detection, logging, among other things.
As I understood it, they have made a JACK SPA plugin, and when that is installed, it should just work.
But the developer answering to the issue says its not recommended because nobody touched the code for 2 years, "SPA JACK2 plugin should probably be considered untested at this point"; And that's also why this plugin does not get included by distributions, thus one has to compile it, and put in the spa_plugindir to work. Will try that..

What a shame, its there yet to no avail for the average musician. Maybe if enough People would push on that Issue, they will re-consider - looks like a community effort from this Forum would be wise - maybe start a petition?

I asked the pipewire-debian ppa maintainer to include it for us for testing purposes..

j_e_f_f_g wrote: ↑Fri Apr 07, 2023 5:26 am

revoxs wrote:

Pipewire does MIDI

And I see absolutely no reason why it should.

If pw is to replace jack, then it should at least offer a "jack transport" equivalent? Or isn't that a midi protocol? For midi connections I prefer to just use alsa midi instead of jack connections.

revoxs wrote: ↑Fri Apr 07, 2023 12:33 pm

PipeWire can also run as a JACK client on top of the native JACK daemon if desired.

And I thought that Pipewire was to make audio on Linux simpler, not more complex. Instead of Pulse and Jack running in parallel on top of Alsa, we get Pipewire replacing Pulse AND running on top of Jack on top of Alsa?

Impostor wrote:

"jack transport" isn't that a midi protocol?

No, Jack Transport is not anything to do with MIDI. MIDI has its own two sync protocols. One protocol is called "MIDI Clock", which is an exclusive MIDI technology. The other protocol is called MIDI Time Code (abbrev to MTC, which is basically SMPTE sync adapted for transfer over a MIDI cable). Neither is based on Jack Transport, which is a third way of doing some of the things done by the 2 MIDI protocols (although Jack Transport also does things not covered by the MIDI protocols).

j_e_f_f_g wrote: ↑Fri Apr 07, 2023 5:26 am

MIDI (without a General MIDI engine) is strictly a music composer's tool.

Really? I use it when playing for my own entertainment though I don't compose at all.

Kirtai wrote:

I use MIDI though I don't compose at all.

You're definitely an exception to the rule. What software are you using to play MIDI? (Obviously, you don't record midi since you don't create music).

j_e_f_f_g wrote: ↑Fri Apr 07, 2023 8:50 pm

You're definitely an exception to the rule. What software are you using to play MIDI? (Obviously, you don't record midi since you don't create music).

I use my digital piano and external synths and I do record in order to see where I need to improve.

Kirtai wrote:

I use my digital piano and external synths

Well then you can't use your own example as a counterpoint to my argument. (ie, An audio API for generic apps aimed at typical endusers has no use for MIDI, and should not be allocating MIDI resources). After all, how many PC owners (who aren't musicians who make music) even have external MIDI synths? Hardly any.

Impostor wrote: ↑Fri Apr 07, 2023 5:12 pm

revoxs wrote: ↑Fri Apr 07, 2023 12:33 pm

PipeWire can also run as a JACK client on top of the native JACK daemon if desired.

And I thought that Pipewire was to make audio on Linux simpler, not more complex. Instead of Pulse and Jack running in parallel on top of Alsa, we get Pipewire replacing Pulse AND running on top of Jack on top of Alsa?

I think the important part of the original message was 'can'. I can't imagine the majority of people would use in this way but it's an option.