SoylentNews is people
SoylentNews
The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
(Score: 5, Interesting) by linuxrocks123 on Monday May 30 2016, @10:29AM
"WHY!": Because BlueZ doesn't support ALSA for Bluetooth audio anymore.
"NO!": I wrote the "Removing PulseAudio Completely" section of this wiki page which details how to remove it without getting dynamic loader errors when running anything that uses audio: http://docs.slackware.com/howtos:multimedia:pulseaudio_non-default [slackware.com]
You're welcome :)
The software is "apulse", which I didn't write, and the nice thing about the approach I document there is that, in theory, you should still be able to use software that requires PulseAudio, maybe even including BlueZ, but apulse was written just to make Skype work and so any other PulseAudio software might or might not actually work with apulse. The concept is really nice, though: apulse provides a fake "libpulse.so" that exactly mimics the PulseAudio API but just translates the API calls to ALSA instead of spawning a daemon and throwing shit everywhere like the real PulseAudio library does.
(Score: 2) by bitstream on Monday May 30 2016, @12:57PM
In what way does PulseAudio throw shit everywhere?
Btw, How does one arrange sound device over IP without PulseAudio?
(Score: 1, Interesting) by Anonymous Coward on Monday May 30 2016, @01:26PM
I don't think I've had the need outside of audio streaming like shoutcast. I suppose it'd be possible to write network-capable sinks and hook them into asound.conf. Then again, I'm also looking forward to Wayland (without systemd) because I have no need to display GUI programs remotely. ssh works fine for doing admin stuff on my servers.
I don't know what GP meant by throwing shit everywhere. The one time I used PulseAudio in the bad old days before ALSA's dmix made things just work I absolutely could not eliminate a 1 second delay from even local audio. Somebody, either here or on the old site, explained the potential problem to me recently, but I never looked into it. I just switched back to ESD, noted that network transparency for audio was a neat trick, and went on with life.
I believe JACK will do network transparency as well. JACK is good enough and low-latency enough to turn my desktop into an effects box for my guitar, but I never played around with its networking support.
Now, if I had infinite free time, I probably could write you a network transparency sink for ALSA. The other one I've been wanting to write is a sink that allows dynamically switching its audio sink on the fly so I can switch between headphones and speakers without pausing whatever's playing whatever and switching each application over to a different sink. I'm guessing neither of those exist because there's simply not a big need for either.
(Score: 2) by bitstream on Monday May 30 2016, @01:42PM
I suspect the inherent problem is that of packetization and thus as a consequence latency. Interprocess communication is affected by scheduler and so on. An open file handle can usually handle byte-by-byte usage but a network connection would likely become a mess in such scenario. Perhaps if the (network) connection where handled by the kernel and the pathway consist of circuit connections like in ATM, perhaps then it could work without serious issues.
I simple suspect anyone trying network audio, even internally within a computer will be fighting the basic architecture and thus all approaches will be tainted in some way.
(Score: 2) by Scruffy Beard 2 on Monday May 30 2016, @04:21PM
I believe that JACK does network audio first, then if you want to hear the output, you remix it for your soundcard's clock.
The packetization would have a mostly predictable latency because the bandwidth used it predictable. As for scheduling latency, JACK wants to run with the "Real-time" process priority. The Debain configuration script warns that can cause crashes if you are low on memory (I left that disabled).
I never did get it to work across the network: multicast failed for some reason I never had the time to trouble-shoot.
(Score: 2) by sjames on Monday May 30 2016, @09:07PM
Some professional audio distribution systems use raw ethernet packets in order to reduce overhead and latency. They also use real time scheduling.
If the network audio has a long duration, you also run in to problems with sample clock disagreement. You have to have at least a small buffer so you can drop or duplicate samples to sweep that under the rug without it being human audible or risking under/overflow..
(Score: 2) by Marand on Monday May 30 2016, @08:57PM
I believe JACK will do network transparency as well. JACK is good enough and low-latency enough to turn my desktop into an effects box for my guitar, but I never played around with its networking support.
It will, and it works great, but at the requirement of more configuration and manual effort. Biggest problem is lack of JACK-aware programs, so you have to route ALSA through JACK and then back through ALSA via configuration wizardry to transport general system audio. Once it's working, you link the audio to network output on one system and link network input to speaker output on other and it's done. The linking can be automated once you get it sorted out, of course, like any other patchbay setup.
Bandwidth use seemed higher than pulse, though, it still generally works fine, even over wifi. Only exception was this one old router that crashed and rebooted any time I tried, but that was a router problem; it would overheat because it was shit.
JACK gives more control and better latency/quality, but Pulseaudio wins at making the process more idiotproof, assuming PA works at all for you. (It tends to have issues on my system for some reason. Fine on laptop though.)
(Score: 2) by sjames on Monday May 30 2016, @09:10PM
I killed pulseaudio for a variety of reasons. Often it just didn't work, but even when it did work, it was too jittery to keep it synced with video well enough for even casual viewing.
(Score: 2) by Marand on Monday May 30 2016, @11:45PM
My problem is excessive cpu use and unnecessarily high audio latency (local audio, not network). The latter will never improve because it's just not a goal with pulse; they've said before to not use it if latency is a concern. So I tend to not use it on systems where it matters, though the laptop gets a pass because I don't care there as long as the cpu issue doesn't crop up.
(Score: 2) by VLM on Tuesday May 31 2016, @12:15PM
because I have no need to display GUI programs remotely. ssh works fine for doing admin stuff on my servers.
The only exception I'm unfortunately personally aware of is mythtv-backends can only be configured via a slow painful agonizing GUI. My backend is headless and physically far away from my frontends, which sounds pretty funny out of context. Anyway life is pretty easy when you can configure the backend by networked X while standing in front of a frontend.
I've used RDP at work and to a lesser extent, at home, for headless systems that need a GUI. Pretty cool to have the same dev environment on an ipad or an android tablet or my phone or any other computer. I'll probably rig something up on the mythtv-backend so it thinks its using X locally but I'm actually talking to it over the network. In the end that would be nicer as I could mess with the backend config using one of the kids ipads while testing on the frontend.
Something I kind of like is a tricked out emacs with all the addons connected to via whatever RDP screen is nearby. Its a nice flexible development environment. It means I'm developing on a giant machine of essentially infinite resources with all the speed you'd expect yet my laptop doesn't get warm and the battery lasts quite awhile because all its really doing is shoveling from network to screen.
(Score: 0) by Anonymous Coward on Monday May 30 2016, @07:33PM
Well, this might be good, thanks for the response.
Still, as someone who never uses bluetooth (and is always sadly disappointed when we try for whatever reason), it strikes me as odd that we'd crack open the gates just to let some additional systemd-influenced sound bullshit behind the walls.
Especially for an OS that has done so well in the past at avoiding all this weird freedesktop/gnome b.s.