So the wheel continues to turn
So the wheel continues to turn
Posted Sep 19, 2017 15:32 UTC (Tue) by tau (subscriber, #79651)In reply to: So the wheel continues to turn by pwithnall
Parent article: Schaller: Launching Pipewire
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]
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
