[gentoo-user] Re: Removing pulseaudio
On Fri, Apr 26, 2013 at 04:50:43PM +0800, Mark David Dumlao wrote: > On Fri, Apr 26, 2013 at 3:55 AM, Alan McKinnon > wrote: > > And you are vastly overstating the desirability of having pulseaudio > > enforced on users without very good cause > How much barefaced lying can you do in one sentence? > 1) it's not enforced _on you_. USE=-pulse Not enforced on Gentoo, no, which is why many of us use it. But we're discussing pulseaudio in the wider ecosystem (you certainly are) which does affect us too. > 2) bluetooth headset goes in, audio goes out is good cause. Yeah and if you need it all power to you: look you can install it real simply or it comes by default on some distros. What about the rest of us who either don't give a damn about audio beyond the speakers on our computer, with hifi TV et al separate, or are actually into quality audio, and use jack? See: you cannot predict the use-cases. By definition, you will not be present when the software is run by the end-user. So you have to learn humility, and let the user decide. Hence what was said before about software not imposing itself, especially when not in even use. One True Way inturgrated idiot-box crap doesn't allow that. It's the antithesis of Unix. And if you can't deal with the fact that Linux is a *nix, use something else instead of imposing layers of crap on the rest of us. Especially your dud spangly new ideas that are turds you want the rest of us to polish while you sell your "enterprise" distro based on everyone else's work. It's poisoning the software ecosystem. > > and seem to have > > underestimated how deep that rabbit hole goes. > No I haven't. I have no idea how deep the complexity of pulseaudio is > because I don't know how to use it. I don't know how to use it because > it just works. > But if I compare > how well I learned to use grub vs pulseaudio, two things that I use > everyday, it's clear that one of them was more successful in hiding > the complexity from me before I used it successfully. HINT: it wasn't > grub. Funny, I spent even less time learning to use the KDE artsd and it worked too. I never had any problems with it at all, yet I've heard of a lot of issues with pa, more worryingly to do with the mentality the "developer" imposes as a condition of working with him. I still got rid of it, and am much happier with my current, Lennartware-free, setup thanks. Must be something about "what programs actually do, rather than just" misleading analogies and invalid comparisons. > If you actually talk like it matters what the programs do, rather than > just making airy abstractions on what some ideal fetishized system > should be like, you'll understand things better. > > > "It does no harm and might be useful for some" is simply not a valid > > reason to enforce a package on all users, especially when said package > > is the latest johnny-come-lately from a wunderkind with a proven > > reputation for writing invasive code[1] > Oh dear. I should've realized what this was really about. There aren't > really any technical reasons behind this, are there? Just some good > old fashioned Lennart hate boners. > > I have a perfect halloween campfire story for this group. The one > where a malicious udev update gives a backdoor for He Who Must Not Be > Named to install his LennartWare onto yor systems... Newsflash: it's called "systemd" and you can't get udev without it. Nor can you build udev separately, you must install all the requirements and build the full systemd package: they deliberately broke that. Even though systemd has nothing to do with udev: it's a complete layering violation. They have nfc about what "not breaking userspace" means. They tried to push binary logfiles in the kernel; they broke module-loading and blamed it on everyone else; and they designed a system with a race builtin, despite claiming loud and wide that they are the "experts in the dynamic early userspace domain". Oh and let's not forget the wonderful decision to use XML in system space, plus the current nonsense about hw bus-ids being stable. But sure, these amateurs are just who we want writing system-critical code.. Smart businesses won't be so dumb. Nor will smart users. Good luck to the rest of you, you have my sympathy: I see your pain on IRC every day. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-user] Re: Removing pulseaudio
On Thu, Apr 25, 2013 at 09:31:43PM +0400, Yuri K. Shatroff wrote: > On 25.04.2013 19:48, Mark David Dumlao wrote: > > On Sat, Apr 20, 2013 at 5:34 PM, Walter Dnes > > wrote: > >> I think you've hit the nail on the head. Complex setups require > >> complex software... deal with it. An analogy is that an > >> 18-wheeler semi-tractor trailer with a 17-speed manual transmission > >> (plus air brakes that require months of training to manage/use) is > >> much more powerful than a Chevy Sonic hatchback when it comes to > >> hauling huge loads. But for someoneone who merely wants to zip out > >> to the supermarket and buy a week's groceries, the hatchback is > >> much more appropriate. > >> > >> Similarly, PulseAudio may be better at handling complex situations > >> like you describe. The yelling and screaming you're hearing are > >> from the 99% of people whose setups are not complex enough to > >> justify PulseAudio. Making 100% of setups more complex in order to > >> handle the 1% of edge cases is simply wrong. Exactly. If you think you have to make 100% of cases more complex just to handle an edge 1%, YDIW. No ifs nor buts about it. > > The "complexity" overhead of pulseaudio is vaaastly overstated here. > > > > Yes, as a general principle, adding unneeded complexity is bad. But > > that takes into account general ideas on the relative tradeoffs of > > having it there or not. But listen to the happy PA users here who > > don't feel any problem with their setup. The complexity doesn't bite > > them. > As for the complexity of PA, one must distinguish the PA architecture > complexity, its installation complexity and the complexity of managing > this stuff for the user (not mentioning usage complexity which is > probably negligible). > > I wouldn't care for the architecture complexity (although I assume it to > be too complex) but what I do care about is its bad manageability. > If it were to install just a package, or just remove one package, then > everyone would be satisfied, including those who need the functionality. > But apparently it isn't so; either all audio software is to use PA, or > none at all. > > > Analogy: 99% of people aren't going to need a11y. But the whole point > > of installing it by default on most desktop systems is that you can't > > predict who will need it, and _it does not harm_ (or very little > > harm) to the people who don't. > > > > So your tradeoffs are: A) no a11y unless elected by user: - for the > > 1%: a11y is a pain to install because the user might not even be able > > to see the screen (very big pain) - for the 99% use a few megabytes > > less on their disk. (very small gain) > > > > B) a11y for everyone unless elected removed: - for the 1%: they can > > use the system properly (no pain) - for the 99%: use a few megabytes > > more on their disk (very small pain) > > > Obviously (B) is a better default choice. Ditto pulseaudio. That's assuming it were simply a case of a few megabytes of disk space. But as pointed out, it's also a case of upstream wanting everyone to change the way they do things across the board, in the name of "convenience". It doesn't seem like these "convenience" layers really make anyone's life easier in the longer-term. Instead of working behind the scenes so that existing methods function more capably, everyone has to change their code to a new API, whose developers wouldn't know an ABI-promise if it smacked them on the head, and all users have to change their setups. Hardly making everyone's life easier, and "breaking userspace" as if it were lucrative. Further, they appear to have a tendency to break when you want to do something "unusual", or as most people think of it, use your machine as you see fit. That's a problem common to all idiot-box software, when they try to guess and don't listen. If I wanted that, I wouldn't have fled Windows development over a decade ago. > Well if PA is that great then why really not do like you suggest? > Probably, the problem is not "a few megabytes more on their disk" but > that PA is just not a good alternative? > > And eventually is there a real big unsolvable problem for one to > *install* PA when he needs? Does one really end up with "black screen" > or another kinda PITA without PA? If not, then it's not a good analogy? Precisely. > But as I feel it, the talk is about choice, not PA nor complexity. I > just *don't want* it. I probably don't see any harm with various > akonadis and nepomuks in KDE (actually, I did see much harm, but that's > another story) but I simply don't want'em. As a result (of all those > useless-for-me pieces of great code removed) I have Gentoo running KDE > times faster than e.g. OpenSUSE, but even without that, it's my choice > and if I don't perceive or measure these "times faster" I believe in > them. I'm with you there: after I removed semantic-craptop, my KDE came back to me :-) I went a bit further and removed the nubkit stuff, and things act
[gentoo-user] Re: Removing pulseaudio
On 04/21/2013 03:28 AM, Neil Bothwick wrote: > On Sat, 20 Apr 2013 20:15:49 -0500, Canek Peláez Valdés wrote: > >> So normal systems require PA. That *you* perhaps don't require PA is >> another thing altogether. > bike-shedding Been a long time since I've seen that used in a linux mailing list :)
Re: [gentoo-user] Re: Removing pulseaudio
> > I suggested he use Gentoo but I think he saw it as too much work. > > (comment for me?) > All I use is gentoo or embedded (state machines) on embeddded hardware. My > target is jack on embedded gentoo, but, I've run into resource limitations, > so I'm waiting on my new Arm15 dev board in May. > > > > Feel free to remove PA if you don't need it. I really don't see any > > > > scope for Lennart to make all of alsa redundant anytime soon (unlike > > > > udev...) >>> Of course from many threads from a pro audio user called Ralf, Gentoo >>> users and so a fraction of Linux users are the only ones lucky enough >>> to be able to do that *easily* whilst keeping packages they want, >>> especially Gnome ones! Ralf, Sorry. I should be more careful in what I write but I am in the middle of a few things. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
[gentoo-user] Re: Removing pulseaudio
Kevin Chadwick yahoo.co.uk> writes: > > > Another question. Can the installation of PulseAudio and Jack > > coexist? Doable or a constant nightmare? > > There seems to be a a package to allow pulse to utilise jack. However > if you are using jack for the high quality audio benefit then > apparently you have to kill pulseaudio even if it means making a dummy > package on binary distros to fool the system into thinking it is > installed and so not removing lots. What I suspected timing (latency) increases that from my experiments are sporadic and too unpredictable. jack alone works best. > I suggested he use Gentoo but I think he saw it as too much work. (comment for me?) All I use is gentoo or embedded (state machines) on embeddded hardware. My target is jack on embedded gentoo, but, I've run into resource limitations, so I'm waiting on my new Arm15 dev board in May. Thanks, James
Re: [gentoo-user] Re: Removing pulseaudio
> Another question. Can the installation of PulseAudio and Jack > coexist? Doable or a constant nightmare? There seems to be a a package to allow pulse to utilise jack. However if you are using jack for the high quality audio benefit then apparently you have to kill pulseaudio even if it means making a dummy package on binary distros to fool the system into thinking it is installed and so not removing lots. I suggested he use Gentoo but I think he saw it as too much work. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] Re: Removing pulseaudio
2013/4/19 James : > Canek Peláez Valdés gmail.com> writes: > > Another question. Can the installation of PulseAudio and Jack > coexist? Doable or a constant nightmare? > Yes, they sure can coexist. I haven't found it completely optimal always, but here is some info. I currently run both PA and JACK side by side, but on different sound cards. However, I can get PA to send audio into JACK and vice versa by manually starting JACK through QJackCtl; the PA plugin is not initialized otherwise. This works fine but it can be a little CPU hungry if I have many inputs/outputs. As I mentioned, PA is running "on top of" JACK. I do not know if the opposite is as easy (haven't yet tested), but I guess you could just start JACK with the "dummy" driver and let the PA plugin do the trick. Also, make sure PA does not take over the card you want to use with JACK. Otherwise JACK will complain. It can be disabled through pavucontrol. Kind regards, Karl
[gentoo-user] Re: Removing pulseaudio
Canek Peláez Valdés gmail.com> writes: > https://plus.google.com/photos/115256116066287398549/ albums/5778609034682831121/5778849461325756466 > > And I just don't care. PA just works, in all my machines and media > center. And it's all very nicely integrated with GNOME and it just > works with a couple clicks from my mouse (if at all). What about KDE? I do not see a gui interface for pulseaudio? I did find the files under /etc/pulse. A gui interface to pulseAudio for KDE? Another question. Can the installation of PulseAudio and Jack coexist? Doable or a constant nightmare? curiously, James
Re: [gentoo-user] Re: Removing pulseaudio
On 04/18/2013 05:26 PM, Hartmut Figge wrote: > Michael Mol: > >> My particular discovery was that if I launched WoW under WINE, and then >> launched a browser, audio in WoW worked fine. If I launched the browser >> first (which resulted in a flash applet being loaded in GMail for the >> purpose of audio notifications for google talk), Flash grabbed the ALSA >> device and no WINE application could get at it. Routing both through >> PulseAudio solved the problem. > > Mhm. I have now started my SM and loaded the flash > http://fun.from.hell.pl/2003-02-18/volare-karaoke.swf. Then i started > wine playing tcc1, a mod of Might & Magic 6. No problem with the sound. > > Shockwave Flash 11.2 r202 > wine-1.5.28 > > No pulseaudio. ;) Sounds like they got that problem fixed, then. That's good. signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Removing pulseaudio
Michael Mol: >My particular discovery was that if I launched WoW under WINE, and then >launched a browser, audio in WoW worked fine. If I launched the browser >first (which resulted in a flash applet being loaded in GMail for the >purpose of audio notifications for google talk), Flash grabbed the ALSA >device and no WINE application could get at it. Routing both through >PulseAudio solved the problem. Mhm. I have now started my SM and loaded the flash http://fun.from.hell.pl/2003-02-18/volare-karaoke.swf. Then i started wine playing tcc1, a mod of Might & Magic 6. No problem with the sound. Shockwave Flash 11.2 r202 wine-1.5.28 No pulseaudio. ;) Hartmut
