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 <ralf.mardorf(a)alice-dsl.net> wrote:
  From: Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>
 Subject: Re: [LAD] palm pre [was Re: [ANNOUNCE] Safe real-time on thedesktop by default;
Desktop/audio RT developers, read this!]
 To: "james morris" <james(a)jwm-art.net>
 Cc: linux-audio-dev(a)lists.linuxaudio.org
 Date: Wednesday, June 24, 2009, 6:45 AM
 james morris wrote:
  On 24/6/2009, "Patrick Shirkey"
<pshirkey(a)boosthardware.com>
        
 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
 Linux-audio-dev(a)lists.linuxaudio.org
 
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
      
 _______________________________________________
 Linux-audio-dev mailing list
 Linux-audio-dev(a)lists.linuxaudio.org