Just a small comment, and then I shut up: the great thing about linux is its flexibility. I have a few boxes at home doing different things: - a multimedia server based on mythtv, NFS and samba - a powerful DAW running an RT patched kernel - a couple of laptops for AOB (any other business)
For the AOB laptops, it was nice not to do anything once I installed the distro. Things worked OOB, and that was it. For the DAW or multimedia server, that was another story ... but simply because customized systems require, well, customization. The all-in-one distro is and I think will remain a utopia. This said, I recently upgraded my DAW to KDE 4.2 (was 3.5.9 before upgrade) and that automatically installed pulseaudio. I had already fiddled around with pulseaudio about a year ago due to my using VirtualBox (another story). I found pulse's features kinda cool and I quickly understood it was not meant as a replacement or alternative to Jack. As of today, my DAW has pulseaudio installed. But all I had to do was: - open the KDE system settings - disable ALL sound stuff I could find So basically, KDE offered me the possibility to not interact at all with the sound layer. It was obviously not a default setting but it was just a few clicks away. So let me be straight: it should remain like that. On average, a user installing e.g. KDE will expect desktop sounds to work (sound notifications, mp3 players, DVD playback, what-not). That's not what I want in my DAW at all but being myself an old linux "power user", I knew that it would do that (experience with artsd). I mean, how could the KDE installation possibly know that it was to be running on a DAW ?! :D I am glad the desktop config interface allowed me to configure it the way I wanted (no extra special services in the background, no sound system other than what I want for my DAW). Now, if things were to change (no longer the possibility to configure e.g. KDE the way I want), I would definitely feel pissed-off and complain on some mailing lists. But let's be also clear: pulseaudio is definitely NOT the worst things that could happen. It works fine on my laptops, I don't need to do anything about it and that's what it was intended for: a generic and multifeatured desktop sound system. But desktops are also used in other contexts (e.g. DAW) and it would really be wise to keep desktop components _optional_ (not only sound system but also visual effects, etc). That's just simple wisdom and i suggest we keep it that way. The same applies to jack. It is a highly specialized tool and should remain so. OK, time to disappear from this discussion. Cheers, J. --- On Wed, 6/24/09, Ralf Mardorf <[email protected]> wrote: > From: Ralf Mardorf <[email protected]> > Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop > by default; Desktop/audio RT developers, read this!] > To: "james morris" <[email protected]> > Cc: [email protected] > Date: Wednesday, June 24, 2009, 6:45 AM > james morris wrote: > > On 24/6/2009, "Patrick Shirkey" <[email protected]> > wrote: > > > > > >> It would be helpful if things that could make a > big impact will > >> continued to be discussed within the LAD > community. However this is a > >> difficult situation. No matter if the discussions > are starting prior to > >> implementation or post implementation the general > direction of the > >> arguments tend to be quite emotional. > >> > >> Is it just because audio guys have a bit more > artistic temperament than > >> most other developers? > >> > > > > I don't think this adds much to what has been stated > by Fons and others, > > but perhaps it explains a little? > > > > I'm not a hardcore audio developer like most of the > guys here, but I've > > been making audio/music/noise, and coding, since the > days of 486sx25s > > and windows 3.1. Back then, and for many years after, > it was a real > > concern to be able to disable as many irrelevant (to > audio) processes in > > the system as possible (as I'm sure you're aware). > > > > Now I have a pretty capable system, but when I want to > run RT audio apps > > I still want to disable as many irrelevant processes > on the system as I > > can. > > > > For this reason I really dislike the big monolithic > desktop environments. > > There are several applications tied into them (some > serious, plain > > useful, or just fun) which I'd love to have working > but which force me > > to install all sorts of software I really don't want > or need - along > > with all sorts of processes running in the > background. > > > > So it feels a bit freedom eroding. The choice seems to > be between a > > system which 'just works' but which wastes system > resources on things > > I don't want, or a system which I have to spend hours > setting up, > > constantly have to deal with the idiosyncrasies of, > but which is as fast > > and powerful as it could be. > > > > The notions of old, to raise the potential for system > resources to be > > only used for the job at hand (ie audio) are still > strongly rooted and > > people don't like it when they feel their freedom to > use systems in > > this way is threatened by forcing them to install > software and have > > running processes they don't want. > > > > James. > > I guess (if needed) separating rt and bread-and-butter > Linux by having a > dual-boot is an acceptable solution. A user with nearly no > knowledge > could install a comfortable distro for the everyday desktop > environment > and another for real-time usage. Even if somebody don't > have any trouble > with his Linux install, he might wish to have a safe Linux > for > productions and another Linux to have fun and fun sometimes > means to > risk things, you won't risk for a installation that needs > to be stable > all the time, that's why a dual-boot has also an advantage, > if there > will be a joint venture for distro/ desktop developers and > rt > hardliners. I have a bad mobo and for rt e.g. I need to set > irq priority > for especially the one port where the MIDI is connected to. > I don't > think things like that should be done by the desktop > environment. This > seems to be impossible. > _______________________________________________ > Linux-audio-dev mailing list > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
