I think that was true in the “early” days of PA. Not sure there have been issues for several years now.
Pipewire can already provide an ALSA device that can can use. Pulse still cannot.
I use Skype and Firefox via Pulse all the time. But that maybe because of a native-pulse-module for both applications, which would leave me unaware of the problems with direct ALSA support.
It’s because of those apps (and gnome) needing pulseaudio, PA became widespread.
If pulse’s ALSA emulation would have worked, PA would still be mostly optional.
Anyway my point was that ideally Ardour will not have nor need a Pipewire backend.
And if Ardour could implement only the option to choose Pipewire ALSA? Like this:
So we could choose between ALSA (Ardour exclusive hardware), JACK, Pulse and PipeWire Sound Server (this way we can use MIDI, listen to a song or something else while record/playback or just use a plugin at the same time.
I can use JACK Audio Connection Kit instead if I want by removing the pipewire libraries for jack. So it would make sense to have this option to choose Pipewire ALSA, wouldn’t it?
That’s just ALSA.
Ardour won’t know the difference if it is a physical device, or pipewire virtual one.
Nothing new is needed.
That’s my point. Pipewire server won’t “catch” Ardour if you choose ALSA because Ardour connects directly to physical device and that is the option “directly to output without any conversion” on Pianoteq. You can’t see Ardour on pw-top except if you choose JACK or PulseAudio in Audio/MIDI Settings. If I choose Pulse there is no midi support, of course. So, using the Pipewire server (pipewire-pulse, isn’t?) there is a midi-bridge making it possible.
Likely because Ardour/ALSA currently only lists hw: devices by default.
You can pick any interface by setting the ARDOUR_ALSA_DEVICE env variable. That can also work with aplug and similar interfaces.
Eventually we can relax the device list, likely also for MIDI devices (which are hotpluggable).
Nice, Robin. I didn’t know before but I’m glad to know now.
I’ll give a try.
It would be amazing… Especially for less experienced users coming from other Daws.
1 Like
When else do you expect it to release the device?
1 Like
When I don’t want a recording mix session 100% focused (where I’d use Alsa) but intent to do multitasking.
Robin summed it up perfectly.
But I need more than playback only and that without relying on jack for everything. Then I could stop using jack or having jack installed. Everything would be up to ALSA (exclusive access for heavy tasks and virtual/pseudo device for multitasking)
That’s a “when” and a common scenario.
Sometimes I want to check an audio file while I’m mixing or recording a demo without stop the audio engine to do this ordinary task.
1 Like
You could use Ardour’s audition feature from the import dialog for that (or import a reference to it).
If you want to share your audio interface between applications then you need some system capable of doing that. JACK is the main example of such a system. Pipewire can be considered an alternative implementation of JACK for this purpose. PulseAudio cannot be considered equivalent, because it is not designed with pro-audio/music creation workflow and applications in mind.
So, if you really need to do this, keep using JACK (or Pipewire-as-JACK).
If you other reasons for preferring to use Ardour’s ALSA backend, then you need to accept that this implies exclusive use of the device.
Also, sndfile-jackplay, clementine, vlc and a myriad of other ways to “just play an audio file via JACK”.
but I am not using JACK 
you’re also not that guy
For sure, I forgot about this feature. That is why now I think that “audio file” was a bad example. Let’s say… a whatsapp web, telegram or skype audio as an example. The whatsapp is a real situation for me because my clients usually just drag and drop everything they want to show me.
I see… For real, ALSA backend works wonderfully and I’m just bringing this up for debate because 1) I don’t understand very much what is Pipewire ALSA (is it an emulation?) 2) Why couldn’t pipewire make this scenario any less inflexible like it is with Mac’s CoreAudio? (I don’t know how CoreAudio is designed to naturally do that) 3) I hope Pipewire can make things more pragmatic and intuitive in the future, so I’m not blaming Ardour, even because Bitwig works exactly like Ardour so far, that is, any difference in this scenario would be a pioneering spirit from Ardour.
Yes, when pipewire-as-jack be able to perform like Ardour’s ALSA backend. We don’t have freewheling implemented yet, we can’t change buffersize without a command line, there are mysterious glitches happening even with rtkit properly set and working. So… Almost there but not yet.
CoreAudio imposes a single API on all applications using it (at least, using it directly). This API is semantically similar to JACK. CoreAudio does not permit/provide the sort of APIs used by many ALSA/OSS/PulseAudio applications.
So … PipeWire’s situation is more complex right out of the gate.
But, if Pipewire works out (and it seems likely that it will), you won’t see most of that complexity. Apps that use the ALSA API will just continue to do so, and apps that use JACK will just continue to do so, and they will all be able to share whatever device(s) Pipewire is interacting with.
2 Likes
I imagine it is Apple’s choice based on closed/exclusive hardware and proprietary software (MacOS and etc). It’s easy on the apple side because things are more restricted and imposed. So… Yes, I’m wrong. In fact, CoreAudio is more inflexible than FOSS, right? There are more options, libraries, architectures to support in the penguin universe and Pipewire tries to make a sort of alchemy of the best in freedom and plurality without coming from scratch.
Yay! 
I don’t see myself going to Windows or Mac OS as long as Linux (and Wine) exists.