Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 7, 2020 15:53 UTC (Sat) by kleptog (subscriber, #1183)
In reply to: Bouzas: PipeWire, the media service transforming the Linux multimedia landscape by ocrete
Parent article: Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

So Pulse did one thing right, they defined an API that was sensible enough that the implementation could be swapped out and replaced with a better one.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 8, 2020 22:33 UTC (Sun) by Wol (subscriber, #4433) [Link] (4 responses)

Not really. As far as I can make out, part of PulseAudio was was a soundcard emulation you could stick aRts on top, so several applications could be fooled that they had sole control of the sound card.

So now you have an interface where you fool PulseAudio into thinking it has control of the soundcard ...

This is the way computing *should* advance - the new layer fools the old layer into thinking nothing's changed ... I always think of IBM mainframes, where an IBM 360 program runs on a virtual 360, which used to run on a 370 and now runs on a virtual 370 which runs on ... well I don't know the progression of mainframes, but old 360 applications sit on top of three or four emulators to run on the latest hardware.

Cheers,
Wol

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 17, 2020 21:49 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

That's almost entirely wrong. One thing PA did right -- and PipeWire is following suit -- was to mimic the userspace APIs of almost all previously-existing sound server systems, so it could support almost all existing userspace programs. This was very difficult for OSS and ALSA -- it had to use an LD_PRELOAD wrapper you had to turn on explicitly for programs that needed it -- but for everything else it was more or less trivial. At no point in this does PA do anything one could reasonably describe as "soundcard emulation". Equally, PipeWire's PA emulation does not work by kicking up a copy of PulseAudio and giving it a virtual sound card: it merely provides a shared library that makes PipeWire appear to be PulseAudio to PA consumers using that shared library (basically all of them). The thing on the other end of the shared library is PipeWire, not PA-talking-to-an-emulated-sound-card.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 18, 2020 11:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

Well, it didn't emulate the soundcard hardware, that's the kernel's domain in any case, but it did (and still does, in case anybody needs it, which is rather unlikely these days) emulate the OSS driver.

ALSA is/was way easier, pulseaudio hooks itself into it reasonably seamlessly, though the extra layer is painfully visible at times.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 19, 2020 22:00 UTC (Thu) by nix (subscriber, #2304) [Link]

Yeah, it had to emulate whatever API was available, and for OSS that meant it had to intercept mmap and stuff like that. It's still not actually emulating a *sound card* though.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 18, 2020 14:55 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> At no point in this does PA do anything one could reasonably describe as "soundcard emulation".

For ALSA, PulseAudio provides an ALSA plugin which connects to PA. That is essentially PA emulating a sound card, if one considers other ALSA plugins like dmix or plughw which appear the same as sound cards to applications to be "soundcard emulation". Only OSS required the LD_PRELOAD, since OSS applications accessed the device nodes directly. With CUSE and osspd to provide literal "soundcard emulation" for OSS apps one doesn't even need that.