Originally posted by dee.
View Post
Announcement
Collapse
No announcement yet.
X.Org Server Systemd Integration Proposed
Collapse
X
-
-
Originally posted by caligula View PostWhile this sounds reasonable, PA will get better. It has zero copy API so the latency will not grow significantly on localhost. You should definitely use RT kernel and JACK as a backend, but PA can be used as a frontend with low latency overhead. It's just about passing pointers.
PA can definitely be used as a frontend and backend for casual desktop use, like video/music playback, desktop sounds or such. But it will never be useful as a frontend for actual, serious audio applications. Because the needs are just too different.
In fact, the Jack webpage explains this difference quite well:
PulseAudio is focused on desktop and mobile audio needs. It doesn't try to address low latency usage, but does provide seamless device switching, network routing, global per-application volume control and lots more great stuff.
JACK is focused on the needs of pro-audio and music creation users. It offers the lowest possible latency, complete routing flexibility between applications and audio hardware, and all audio is always sample synchronized - apps don't run ahead or behind of others. It doesn't provide the smooth desktop experience that PulseAudio is aiming at.
Comment
-
In any case, caligula, I think you are missing dee.'s point. The point was not about PA and Jack, but on something more general: there isn't always a solution that fixes everything, sometimes you need specific solutions for specific problems, so forcing one specific solution for all the problems becomes short sighted.
Comment
-
Originally posted by mrugiero View PostBut again, if systemd is an optional dependency only, I think there is nothing to complain about here, and I seriously doubt the X guys are that moronic to make it a hard one, I hardly believe they are morons at all.
Comment
-
Originally posted by caligula View PostWhile this sounds reasonable, PA will get better. It has zero copy API so the latency will not grow significantly on localhost. You should definitely use RT kernel and JACK as a backend, but PA can be used as a frontend with low latency overhead. It's just about passing pointers.
in fact it's mostly no better then a regular copy
PA uses alsa in the end
so if you have like 2 sounds playing with different sampling rate there needs to be mixing
and still last time i checked it it used way too much cpu
in fact it used twice as much cpu then the music player, music player that decodes stuff
after... 2 years you'd think it gets better
Comment
-
Originally posted by dee. View PostWell that sounds nice and all but in practice it's just not happening.
PA can definitely be used as a frontend and backend for casual desktop use, like video/music playback, desktop sounds or such. But it will never be useful as a frontend for actual, serious audio applications. Because the needs are just too different.
In fact, the Jack webpage explains this difference quite well:
I think PA makes sense as the default, and if you have niche needs, there are better alternatives.
So I think the situation is pretty good all in all.
Comment
-
Originally posted by Vim_User View PostThis! They didn't make a hard dependency for systemd in Wayland, so why should they do that in Xorg?
Comment
-
Originally posted by Daktyl198 View PostWould it even be an optional "dependency"? From what I can tell, it only provides integration if you use systemd, it doesn't try to force it on you or allude that X works better with systemd.
Comment
-
Originally posted by jrch2k8 View Posti think the problem radicate in the fact most people don't have the background needed to understand why systemd do what it does, so they tend to whine about thing they probably won't ever touch in their life for whatever reason they read for any random troll here and there which 99% of the time are totally wrong.
so in the end they blame systemd for the lazyness of other init systems devs.
facts:
1.) CGroups was declares a security bug by kernel devs: only systemd devs responded to the call to find a proper and secure solution (PID1 in 205+)
2.) consolekit is dead for more than a year!!! blame systemd because they are the only ones around proposing an far superior solution that even canonical has to accept for thecnical reasons
3.) network init at early boot stages is a bloddy hell of a mess/bonding is like calling satan to your home!!! blame systemd ofc for fixing it and then lay control to networkmanager later in the boot process, blame you lennart you so evil
4.) journal is binary OMFG, lennart is the devils spawn!!! ohh wait syslog still works perfectly fine(give lots less info than journalctl) and it never started that early in the boot process or stay alive during shutdown process or have a nice dbus API or give easy search functions(without 2 pHD in grep/sed engineering) and never played well with other log Systems like rsyslog and never was standard among distros(rsyslog/syslog/syslog-ng/etc)
5.) Dbus in kernel OMG the heaven will fall!!! ohh, wait basically every linux app on existance uses dbus and the kernel didn't like the idea because lennart poisoned their corn flakes but because kernel IPC is quite obsolete and slow and porting dbus to a lower layer will allow for way more performance and security plus regular apps won't even notice and kernel deis can take that train and improve a lot of subsystem suffering from IPC performance issues, well WTH lets blame lennart either way
6.) etc,etc,etc,etc blah blah blah lets go political besucase i can't understand any of the above, just to not look stupid
Edit: I didn't see the post of GreatEmerald.
Comment
-
Originally posted by GreatEmerald View PostWell, X does work better with systemd, by virtue of being able to operate without root privileges.
it only requires KMS to be used, that binary drivers don't support
edit: more about it
Last edited by gens; 29 January 2014, 08:08 AM.
Comment
Comment