Schaller: Launching Pipewire
Anyway as work progressed Wim decided to also take a look at Jack, as supporting the pro-audio usecase was an area PulseAudio had never tried to do, yet we felt that if we could ensure Pipewire supported the pro-audio usecase in addition to consumer level audio and video it would improve our multimedia infrastructure significantly and ensure pro-audio became a first class citizen on the Linux desktop." A video-only version will be shipping in Fedora 27.
Posted Sep 19, 2017 14:06 UTC (Tue)
by tau (subscriber, #79651)
[Link] (24 responses)
I'd ask why they felt the need to rewrite PulseAudio instead of evolving and extending it, but I already know the answer. Both the public one and the real one.
Posted Sep 19, 2017 14:26 UTC (Tue)
by pwithnall (guest, #97459)
[Link] (23 responses)
Posted Sep 19, 2017 14:59 UTC (Tue)
by SEJeff (guest, #51588)
[Link]
Posted Sep 19, 2017 15:32 UTC (Tue)
by tau (subscriber, #79651)
[Link] (21 responses)
We already have a working audio service in the form of PulseAudio, which also supports a variety of other features such as microphone beam forming, echo cancellation code imported from the WebRTC codebase, Bluetooth routing, and a fairly clever way of interacting with the DAC's output FIFO to minimize latency. There were some missteps by distribution packagers early in the project's life cycle, but we have a reliable and working service now.
So now we are going to throw all of that away instead of improving upon it. Now, to my second point, the usual public argument in favor of changes like this is that the development resources on the project are limited and it takes longer to do an incremental change than it takes to do a big-bang change. In fact this isn't really the case; it is indeed quicker to go from v1.0 to v0.8 than it is to go from v1.0 to v2.0. But the first 80% of the task is the easy part! those last few little details are where the actual difficulty lies! Not to mention, most people don't want to be the guinea pig for v0.8.
So how much testing has this new project undergone, beyond the developers running development builds on their work laptops? This software isn't being written using aerospace-grade validation methodologies, so "v0.8" is going to have bugs that won't manifest until it gets deployed on a wide range of devices. Desktops, laptops, on-board audio, USB audio, Bluetooth audio, analog output, SP/DIF output, HDMI output, codecs on Intel HD Audio buses, codecs on I2S, sandboxed, unsandboxed, and every possible combination of the above. Are you confident that the kernel and ALSA and BlueZ are going to shield you from every last quirk of every last combination of those platforms?
Is there a new sandbox-friendly IPC transport being developed here? Abstract it out, add a feature flag to PulseAudio. A new mixing system that works for both battery-efficient and low-latency use cases? Add a feature flag to select the experimental new core, but keep all the routing and noise-cancelling and beam-forming and IPC stuff in place. Adding video? I'm struggling to see why synchronizing it with audio requires every single line of code in the audio stack to be discarded. Do it this way and you don't end up seesawing between one set of bugs as version 1 stabilizes and then a different set of bugs as version 2 stabilizes. In fact, doing it this way is critical, because you and your platform preserve credibility, and trading off credibility versus perceived development speed is a terrible false economy: most people quickly lose interest in riding such a seesaw for more than a bounce or two.
Linux wasn't rewritten from scratch for v2.4 and then rewritten from scratch again for v2.6. GNOME rewrote its desktop shell from scratch, broke source and binary compatibility for Gtk, its equivalent of the system call interface, and then continued to break it for several years, constantly* before finally declaring it "stable", by which point their credibility was completely wiped out and most users or developers for this platform don't really trust any of their proclamations of stability any more. The consequence being that the vast majority of former GNOME users have defected to macOS, and we are all poorer for it. Credibility is a precious thing; once squandered, it is not quick to return.
* https://blogs.gnome.org/mortenw/2014/06/23/how-does-one-c...
Posted Sep 19, 2017 15:59 UTC (Tue)
by ledow (guest, #11753)
[Link] (16 responses)
The "Problems during adoption phase" part of the Wiki page pretty much says that it required all kinds of modifications and caused problems. https://en.wikipedia.org/wiki/PulseAudio
It also blames those problems on too-early adoption by distros, which would - if true - be the distro's fault, not the project (and I note that I agree with this, but also doubt it's ENTIRELY the fault of the distros here).
That PulseAudio is now reliable is also open to question, no software is ever finished and there are a range of people still having problems with it. A quick search and the big-distro's troubleshooting pages all appear to be quite extensive and require a lot of "If you have this problem, do this unguessable thing in your config file".
One of my favourites: "If PulseAudio uses the wrong microphone, and changing the Input Device with Pavucontrol did not help, take a look at alsamixer. It seems that Pavucontrol does not always set the input source correctly"
To be honest, just LOOKING at JACK/PulseAudio/etc. setups scares me, and I was used to loading soundfonts on boot, setting up MIDI, configuring ALSA / OSS / etc. for years.
If it results in an alternative, that's never a bad thing. If that alternative suddenly becomes your distro default without your say-so then you have a problem unless it's literally bug-free and "just works". But that's a criticism that PulseAudio should be very careful to level at others. Glass houses and all that.
Posted Sep 19, 2017 16:26 UTC (Tue)
by drag (guest, #31333)
[Link]
There wasn't really anything terribly functional that pulseaudio was replacing. Previous efforts was ESD (which never really worked) and Artsd, which was KDE-specific. It used Alsa and wasn't really replacing that. It also took advantage of alsa's plugin feature and implemented backwards compatibility layer.
-----
thank being said:
I don't think it's safe to say that it's better to extend pulseaudio then it is to create a new project or visa versa. It's difficult judgment call either way.
Remember the original plan was to create a 'Pulsevideo' that would work in parallel in pulseaudio, but they ran into issues with that approach. Certainly they must of considered extending Pulseaudio to add video. Also pulseaudio never addressing the needs for audio workstation is a problem and there may be a good reason in the code base why nobody has ever taken it in that direction.
I would think that the initial impression for any developer wanting to solve these problems would prefer to take a simple approach to extend pulseaudio. Hopefully the pulsewire developers can address this in a FAQ.
Posted Sep 20, 2017 12:04 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (14 responses)
Let's compare Linus and Lennart.
Linus, very reasonably, insists that "you don't break userspace. Not ever!". With the result that Linux carries quite a bit of cruft in order to keep that promise.
Lennart, on the other hand, also very reasonably insists that "stuff should do what it says on the tin". So when PulseAudio depends on a documented behaviour of some other component that is wrong, he screams loudly until it's fixed. In the meantime, PulseAudio crashes because this other component is broken. What's that saying about "progress depends on the unreasonable man"?
The result is Lennart's software is clean, easy to follow, and does exactly what it says. The downside is it often finds bugs in *other* software, and Lennart's insistence that the other component fix their problem, rather than PulseAudio or whatever work round it, means that Lennart is usually the one that cops the flack.
I don't like systemd - it's new and unfamiliar. But it certainly seems MUCH easier than SysVInit to understand. And systemd regularly hangs my laptop - but the bug seems pretty clearly to be a faulty interaction between KDE and Network Manager. That's exactly my point about Lennart expecting other software to do what it says on the tin, but he cops the flack for bugs in other peoples' software.
Cheers,
Posted Sep 20, 2017 14:11 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (7 responses)
This sounds like something I should be fixing. Do you have any details or a bug reference?
Thank you and sorry for getting slightly off-topic.
Posted Sep 21, 2017 17:20 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (6 responses)
I run openSUSE on a laptop, so I rely on wifi.
I have several network mounts specified in fstab - all using x-systemd-automount or whatever the option is.
So in KDE system settings, I've ticked the box to tell Network Manager to make the mounts available to all users. EXCEPT.
It seems that kwallet refuses to let Network Manager remember the password, telling it that kwallet will give it the password when it needs it. So the laptop boots, Network Manager asks for the password, and because I'm not logged in, Network Manager can't start the wifi and mount the filesystems. Very big bummer if ~ is an nfs mount!
It gets worse. When I shut down, because it's my password it seems that me logging out kills the wifi. So when Network Manager tries to unmount the filesystems, the unmount fails and hangs systemd.
This seems to be pretty common certainly on SuSE. The workaround is always to install some other DE, use that to configure Network Manager, and then go back to KDE.
I'm on the support list at opensuse@opensuse.org, and if you look there you should find some threads describing the problem. Probably ones I've started but I expect they'll be others too.
I'm pretty certain I haven't created a bug report because half the time the problem is hunting down the right place to report the bug! :-)
Cheers,
Posted Sep 23, 2017 11:36 UTC (Sat)
by tao (subscriber, #17563)
[Link] (5 responses)
Posted Sep 23, 2017 16:33 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
Kwallet should not be stealing the password! If the network is supposed to be available to all users, then the password should not be stored in a user's kwallet. And I think the applet or whatever that told network manager to bring the network up is a kde front end.
So the kde front end tells network manager to bring the network up *before* any users have logged in, then the kde password manager nicks the password so network manager can't do what it was told!
Which is why the workaround is to use a different DE that actually gives Network Manager the password it needs.
Cheers,
Posted Sep 23, 2017 17:24 UTC (Sat)
by sfeam (subscriber, #2841)
[Link] (1 responses)
Posted Sep 23, 2017 18:10 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
Nope. NetworkManager is just a daemon. It has multiple user interfaces including a cli, tui, GNOME and KDE frontends. KDE does typically use the NetworkManager daemon.
Posted Sep 24, 2017 9:44 UTC (Sun)
by lkundrak (subscriber, #43452)
[Link]
$ nmcli -f 802-11-wireless-security.psk-flags c show <your-connection>
This should print the currently set flag. If it's not set properly, just change the flag (you may need to re-set the secret):
$ nmcli c modify <your-connection> 802-11-wireless-security.psk-flags 0 802-11-wireless-security.psk <secret>
Posted Sep 29, 2017 14:34 UTC (Fri)
by StefanBr (guest, #110916)
[Link]
While this is a prerequisite to have it available at boot, it does not imply it. Think of e.g. a VPN connection - you provision it for all users of a company laptop (server address, authentication exchange mechanism, ...), while everyone uses his/her private set of credentials.
You can tell the KDE configuration dialog to save the credential either to the system settings or to kwallet, see here:
Posted Sep 20, 2017 15:33 UTC (Wed)
by ermo (subscriber, #86690)
[Link] (2 responses)
I don't think it is unreasonable in any way, shape or form to expect -- and indeed insist -- that a given piece of software does what it says on the tin.
And I don't quite understand all the hubbub about it, except that of course change is usually uncomfortable unless you yourself were the one who initiated it.
To get back to the topic, it seems to me that Fedora's focus on new concepts, models and technologies such as systemd, Flatpak, Wayland etc. are ultimately what is driving the development and growth of PipeWire.
To suggest that PulseAudio should be adapted to this new way of doing things before the new way has become the standard way is probably not the best idea; better to leave PulseAudio/JACK to service the needs of current users and systems and then evolve PipeWire in parallel to work well with the more segmented and sandboxed way of doing things that Fedora currently seems to be championing...
Posted Sep 20, 2017 15:56 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
The flip-side of Lennart's "meet your specification, or fix your specification" attitude is that it results in short-term pain - if everyone assumes that things are working fine, you're in a situation where it looks like Lennart's code is the problem; everyone else played with their API users until they worked to the implementation, Lennart is insisting that you fix your implementation or your specification.
In Lennart's case, this is reasonable behaviour - he not only insists that you meet your specification or fix it, he also provides good test cases to show where you're not meeting your spec, and is willing to roll up his sleeves and help you fix the problem. It does lead to an initially bad user experience, though, as something that apparently "works" (as in every other application using the API makes it work) doesn't work with Lennart's code, and it's not obvious to the end user that this is because Lennart is trying to fix the whole ecosystem, not just make his thing work.
Posted Sep 23, 2017 20:27 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
And Linux, unfortunately, seems to attract rather more than its fair share of folks who believe "my problem is your responsibility", even when you had nothing to do with it ...
Cheers,
Posted Sep 20, 2017 18:13 UTC (Wed)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Sep 20, 2017 21:45 UTC (Wed)
by glaubitz (subscriber, #96452)
[Link]
I'm very surprised to read this comment here because not many users are aware of that fact as they claim SysVInit to be the original Unix design which, as you correctly explained, it is not.
Everything below /etc/rc.*/ was actually purposed to be used for runlevel scripts, i.e. scripts that are run when changing runlevels. This mechanism was never designed to be used for starting services and the repurposing was a complete abomination which was full of hacks, in particular the double-forking which was necessary to keep the services running after they had been started by the runlevel scripts. This also meant that there was no reliable way of tracking services with PID files and some fragile bash scripts being the only solution for that. Init itself can only track services started through inittab.
On the other hand, inittab has no means of defining dependencies between services or the order in which they are started which is why runlevel scripts have been repurposed for that matter in the first place.
Posted Sep 20, 2017 23:47 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
The runlevel-directories-as-symlink-farms-to-init-shell-scripts approach was already present in 1980s-vintage Unix System V, long before Linux even existed (I used to own SVR3 manuals which explained it in excruciating detail). Linux just copied it from there – it seemed like a reasonable thing to do at the time –, and eventually some distributions tried to fix a few of its more egregious problems, like the complete lack of dependency management. The /etc/inittab part of System-V init is, indeed, reasonably simple but that's mostly because it doesn't do much at all (although even so it still has its weird aspects, like the line labels on the very left of each configuration line) .
System-V init has been around for more than 30 years now, and by now most Unixes have figured out that it is really no longer up to modern tastes and requirements. Linux is the last major Unix-like system to replace it with something more up-to-date – a move that was long overdue, but at least we get to learn from the experience of everybody else.
Posted Sep 19, 2017 16:44 UTC (Tue)
by Uraeus (guest, #33755)
[Link]
Posted Sep 19, 2017 18:59 UTC (Tue)
by mads (subscriber, #55377)
[Link]
Posted Sep 20, 2017 16:39 UTC (Wed)
by Sesse (subscriber, #53779)
[Link] (1 responses)
…which is, to put it mildly, not the highest quality A/V code I've seen. :-)
Posted Sep 21, 2017 20:06 UTC (Thu)
by tuna (guest, #44480)
[Link]
Posted Sep 19, 2017 15:42 UTC (Tue)
by drag (guest, #31333)
[Link]
It's a laudable goal, but it's going to be tough. Remote desktop plus generic multimedia streaming plus pulseudio plus jackd, etc. That's a beast. But if they can pull it off then it would put Linux on top of the desktop heap in terms of multimedia processing. Having to swap out sub systems to go from desktop audio to audio workstation has always been a big hurdle for people. Having generic remote desktop with things like SPICE support would be fantastic. Magical.
Hopefully they are able to leverage as much existing pulseaudio and jack code as much as possible. There are a lot of really obscure and difficult edge cases that pulseaudio has slowly learned to deal with over the years. It would suck to have to re-do all that work.
Of course if they can get really good documentation then that will help out acceptance incredibly. A less capable implementation you know how to use is always going to be superior to a more capable implementation that you can't figure out.
Incidentally here is a blog post covering a implementation for VNC for Gnome that uses pipewire and dbus:
https://www.ctrl.blog/entry/wayland-gnome-remote-desktop
Posted Sep 20, 2017 6:56 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
For video, everything is completely different. What is the new project going to do? Video is incredibly diverse - there are different ways to decode, process and display it. Not all of them compatible. There's also no pressing need to have a video arbitrator, unlike in the sound world.
Posted Sep 20, 2017 7:14 UTC (Wed)
by mads (subscriber, #55377)
[Link] (7 responses)
Posted Sep 21, 2017 6:22 UTC (Thu)
by gdt (subscriber, #6284)
[Link] (6 responses)
Part of the reason for the video+audio approach is the gstreamer authors' experience with synchronisation issues and saying "we've done that, and let's not hurt ourselves like that again".
Good to see that they're taking a slow approach to the deployment.
Posted Sep 21, 2017 7:06 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Keep in mind that PulseAudio is widely supported in other desktop environments and applications. Is the new server going to be just as widely supported?
Posted Sep 21, 2017 9:39 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (4 responses)
Audio is a 48-kHz stream of bytes, video a 25/30-Hz stream of multi-megabyte pictures with n>=0 audio or subtitle tracks alongside. Doing both in the same server doesn't make much sense IMHO; instead, the video streaming system's job is to package audio (from jack or pulse or …) and video and whatnot at the source (if it isn't already), distribute that, and do the reverse at the destination.
Posted Sep 21, 2017 20:03 UTC (Thu)
by tuna (guest, #44480)
[Link] (3 responses)
Posted Sep 21, 2017 21:47 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (2 responses)
My point is that a stream of n>=0 loosely synced(*) video, audio, and subtitle channels is conceptually a very different thing than a single tightly-synced multi-channel audio stream.
(*) audio vs. video frame rates differ by three orders of magnitude. Also, dropping a video frame may not even be noticeable at 50+fps, while dropping 20msec of audio certainly is.
From the blog entry:
>> designing Pipewire to just be able to do video would be a mistake as a major challenge he was familiar with working on GStreamer was how to ensure perfect audio and video syncronisation.
Yeah, but IMHO that's a result of sub-optimal design choices in GStreamer, which make compensating for divergent latency of audio vs. video playback particularly difficult.
I have no problem with Pipewire carrying audio as well as video, after all you can't get reliable sync if you have entirely unrelated subsystems for each. However, the goal should be to hook into the existing pulseaudio or jack infrastructure at the endpoints where audio is collected or played, instead of re-inventing the wheel yet again.
Posted Sep 22, 2017 10:36 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
PCM, DSD, and other uncompressed audio certainly has a much higher frame rate than video; once you get into passing on compressed audio streams (Dolby Digital/AC3, DTS), you can end up with audio frame rates on the order of 10 to 100 frames per second, much the same as video.
The key to perfect synchronization remains the same regardless of how you achieve it - some buffering, a common clock source for video and audio, and care taken to ensure that timestamps are met - whether that's handled by skewing audio clocks, resampling, doing frame rate conversion on video, or otherwise. Given a common clock, you can do this with PulseAudio's timing information and a separate video daemon handling video timing, or you can do it from within one process.
Posted Oct 7, 2017 18:46 UTC (Sat)
by tpm (subscriber, #56271)
[Link]
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
Wol
So the wheel continues to turn
So the wheel continues to turn
Wol
So the wheel continues to turn
So the wheel continues to turn
Wol
networkmanager is a gnome utility. KDE doesn't normally use or need it. Perhaps your problem is that you have told both the KDE "Network Center" and networkmanager to bring up the network. KDE gets there first, making the networkmanager settings irrelevant.
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
Wol
So the wheel continues to turn
Excuse my pedantry here (as I do when you talk about databases ;-), but you — and most everyone else — are blaming sysvinit for what's likely entirely the fault of your distro. The init system starts at /sbin/init and ends at /etc/inittab. And those two things actually work _pretty well_ when wielded as designed; sadly modern use is to treat them as a dumb stepping stone to a compost heap of ad-hoc, state-mishandling shell scripts...
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
So the wheel continues to turn
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
How so? There are multiple ways to solve this, like high-resolution timestamps on packets. There were experiments to add this to PulseAudio, no idea about their final state.
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
Schaller: Launching Pipewire
