[LAU] Daemons, daemons...kill those daemons.

Now that I've gotten a pretty clear picture of the concensus about
PulseAudio, I wondered about some of the other (new and old) sound
facilities in Linux, and specifically wondered if being on a system like
Gentoo where one can turn off build-time support for these things is a
good idea. So...
PortAudio:
From what I can see, this doesn't do much. It seems to provide an API
of sorts that unifies Linux sound with sound on other operating systems.
(For example, FreeBSD supports PortAudio, even though its an OSS-based
system.) Then again, I thought Alsa's OSS emulation provided a
'/dev/dsp' that did that already. Anyway...
Is this bad? Has anyone had nearly the nightmares with
PortAudio presence in a DAW system that's described from users of newer
systems with PulseAudio? I don't want to incriminate it just because
its name is similar. (Though I do find myself calling PortAudio
"PulseAudio" by accident a lot. They really could have found a better
name for that...)
Gentoo has a USE flag to disable PortAudio, but I hesitate to do
so if most of the apps these days are taking its presence as a given. I
don't want to diverge from what's perceived as "normal" upstream more
than necessary to achieve good results.
Esound ("esd"):
This is truly 90's technology that won't die, and we all know that.
The question is, how much of an assumption is it in the apps (and in the
Gnome desktop) to the extent that if it weren't there, there would be
problems? Is it safe on a Gentoo system to globally ban build support
for ESD? Sure, Alsa has its own mixer, but will the apps just
transparently use it if ESD isn't around? This is really the gist of
all my questions here: We know there are daemons we don't like. But
which ones are safe to actually kill, and which ones do we still sadly
depend on for something or other?
Arts ("artsd"):
I already have some doubts about eliminating this one, at least in any
system that hopes to have a KDE desktop available. Even if we don't
need it per se, KDE seems (at least to a naive user like me) to be
deeply wedded to it. There are even direct mentions of artsd setup in
some of the audio setup panels of the KDE Control Panel. Does banning
Artsd support equal losing all desktop audio support in KDE? It looks
like it might...experiences?
I guess what I'm thinking is that it'd be nice to do a build in which
everything but Alsa and Jack is banished to hell, but I'm wondering if
that will leave some programs at a loss to find a mixer at all, and thus
without sound. Ideally, all sound apps, regardless of what target
they're expecting, ought to be able to transparently find the Alsa
mixer, and multiplex with other apps to share access with it
simultaneously, also without special setup.
Does that work?
(I'd even put up with artsd if I had to, since KDE seems to assume it,
and since it doesn't seem to cause major problems...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Brent Busby wrote:
>
> PortAudio:
Isn't PortAudio an API... not a sound server?
> Arts ("artsd"):
>
> I already have some doubts about eliminating this one, at least in any
> system that hopes to have a KDE desktop available. Even if we don't
> need it per se, KDE seems (at least to a naive user like me) to be
> deeply wedded to it. There are even direct mentions of artsd setup in
FWIW.... aRts is needed for KDE 3, but has been removed for KDE 4. It is
replaced by Phonon. From what I gather, Phonon is more of an API (like
PortAudio) than a sound server (like aRts). However, it is able to be
configured with different backends (libxine, gstreamer, NMM, and Helix are listed).
For more info:
http://multimedia.kde.org/arts-faq.php
http://phonon.kde.org/
HTH,
Gabriel
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, 14 Jun 2009, Gabriel M. Beddingfield wrote:
> Brent Busby wrote:
>>
>> PortAudio:
>
> Isn't PortAudio an API... not a sound server?
Could be. I'm still on Debian etch, so I don't have it yet whatever it
is. Question is though, is it really necessary? Or is it benign enough
that it can be safely allowed regardless?
>> Arts ("artsd"):
>>
>> I already have some doubts about eliminating this one, at least in any
>> system that hopes to have a KDE desktop available. Even if we don't need
>> it per se, KDE seems (at least to a naive user like me) to be deeply wedded
>> to it. There are even direct mentions of artsd setup in
>
> FWIW.... aRts is needed for KDE 3, but has been removed for KDE 4. It is
> replaced by Phonon. From what I gather, Phonon is more of an API (like
> PortAudio) than a sound server (like aRts). However, it is able to be
> configured with different backends (libxine, gstreamer, NMM, and Helix are
> listed).
Okay, thanks for the info. By the way, is KDE 4 still a mess (as I keep
hearing), or should all the fear and loathing subside now?
(Still wondering about possible effects of global banning of esd...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sunday 14 June 2009 18.10.51 Brent Busby wrote:
> Okay, thanks for the info. By the way, is KDE 4 still a mess (as I keep
> hearing), or should all the fear and loathing subside now?
If someone says that now: don't listen to them, it's probably the old Desktop
War ghost running in someone's mind.
Many people (including me) are using KDE4 and it's very clean and user centric
(and thank God, it's still hacker friendly, users are still not protected
against them self as in some other environments/OSs) ;-) . However, I did not
go from KDE3 before 4.1 was out.
Look at this:
http://www.josander.net/images/kde4.png
If you look at the right side, I have my Desktop Icons in groups (DAW, System,
Guitar, Synths/Sampler etc) and the Desktop folder in a plasma widget (avoidin
loads of icons here and there. I do also normally hide my panel but shows it
now for the screenshot. Also, I use GTK, KDE, QT and Gnome apps when needed,
no problem. Why do some people still have problem using an app just because
it's a QT or KDE app? I don't get that.
Messy? No way!
Jostein
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Hiho,
On Sunday 14 June 2009 13:50:26 Jostein Chr. Andersen wrote:
> On Sunday 14 June 2009 18.10.51 Brent Busby wrote:
> > Okay, thanks for the info. By the way, is KDE 4 still a mess (as I keep
> > hearing), or should all the fear and loathing subside now?
>
> If someone says that now: don't listen to them, it's probably the old
> Desktop War ghost running in someone's mind.
>
> Many people (including me) are using KDE4 and it's very clean and user
> centric (and thank God, it's still hacker friendly, users are still not
> protected against them self as in some other environments/OSs) ;-) .
> However, I did not go from KDE3 before 4.1 was out.
>
> Look at this:
>
> http://www.josander.net/images/kde4.png
>
> If you look at the right side, I have my Desktop Icons in groups (DAW,
> System, Guitar, Synths/Sampler etc) and the Desktop folder in a plasma
> widget (avoidin loads of icons here and there. I do also normally hide my
> panel but shows it now for the screenshot. Also, I use GTK, KDE, QT and
> Gnome apps when needed, no problem. Why do some people still have problem
> using an app just because it's a QT or KDE app? I don't get that.
>
> Messy? No way!
What are you using for these groups?
I upgraded a while ago, but am not completely happy yet... I miss the single
command line widget to just launch programs from (the one that someone made is
still rather buggy, and doesn't work well in the panel). And I'm getting weird
interferences with OpenGL apps; I suspect there is some weird interaction
going on there between KDE4 using OpenGL and the app using it.
sincerely,
Marije
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, Jun 14, 2009 at 11:15 AM, Brent Busby wrote:
> Now that I've gotten a pretty clear picture of the concensus about
> PulseAudio, I wondered about some of the other (new and old) sound
> facilities in Linux, and specifically wondered if being on a system like
> Gentoo where one can turn off build-time support for these things is a
> good idea. =A0So...
>
>
> PortAudio:
PortAudio is just a portable API. there is no server, no backend
anything. It doesn't provide shared hardware access. It is unrelated
to everything else in your list.
> =A0Ideally, all sound apps, regardless of what target
> they're expecting, ought to be able to transparently find the Alsa
> mixer, and multiplex with other apps to share access with it
> simultaneously, also without special setup.
There is no "ALSA mixer" for multiplexing apps unless you mean dmix
and or a "share" plugin. Both of these "work" for some definition of
the term, but both have also been tested and found wanting as a
general solution to the problem of shared h/w access.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis wrote:
> There is no "ALSA mixer" for multiplexing apps unless you mean dmix
> and or a "share" plugin. Both of these "work" for some definition of
> the term, but both have also been tested and found wanting as a
> general solution to the problem of shared h/w access.
'For some value of the term' is quite correct, and one may wonder
why that is the case.
AFAICS, Alsa has shot itself in the foot by trying to provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra =
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
If such a library had been created by the ALSA devs instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
Just my 2 eurocents, of course.
Ciao,
-- =
FA
Io lo dico sempre: l'Italia =E8 troppo stretta e lunga.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, June 14, 2009 11:10 am, Brent Busby wrote:
> Okay, thanks for the info. By the way, is KDE 4 still a mess (as I keep
> hearing), or should all the fear and loathing subside now?
No, it is not a mess. My well meaning brother installed a laptop with
Kubuntu and KDE4 for my dear old mom to use. (argh....) Still, it's
worked out OK. The only trouble I've had is configuring the wireless
applet to work with WPA.
KDE 4 is definately worth a look. However, I'm not switching my family's
desktops yet. ("Daddy!! Why did you have to go and change
everything?!?!")
> (Still wondering about possible effects of global banning of esd...)
:-)
--
G a b r i e l M B e d d i n g f i e l d
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

--001e680f18bc7ef10a046c59afbf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Phonon is to KDE what PulseAudio is to GNOME. What's more, Phonon beats the
crap outta PulseAudio for being simplistic.
I have been a KDE and pro-audio user for about 4 years, and KDE 4 is truly a
blessing. Phonon with the Xine backend has proved to be the ultimate
environment. I start JACK and two instances of TiMidity++ (one ALSA out, one
JACK out) on bootup (as user in realtime with proper privilleges), which is
very simply taken care of by Phonon (System Settings > Multimedia > Select
JACK as first device for all). It is intelligent to fall to the next device
in case of a failure, and then return once again if JACK is running anew.
I have no other server interfering with the flow/chain, and with the ALSA
JACK plug-in I can even play games like Urban Terror. However, this is only
an abuse test - don't use JACK as a generic sound server! (definitely never
meant to be one, though it appears to be able to handle whatever you throw
at it)
--001e680f18bc7ef10a046c59afbf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Phonon is to KDE what PulseAudio is to GNOME. What's more, Phonon =
beats the crap outta PulseAudio for being simplistic.I have =
been a KDE and pro-audio user for about 4 years, and KDE 4 is truly a bless=
ing. Phonon with the Xine backend has proved to be the ultimate environment=
. I start JACK and two instances of TiMidity++ (one ALSA out, one JACK out)=
on bootup (as user in realtime with proper privilleges), which is very sim=
ply taken care of by Phonon (System Settings > Multimedia > Select JA=
CK as first device for all). It is intelligent to fall to the next device i=
n case of a failure, and then return once again if JACK is running anew.
I have no other server interfering with the flow/chain, and =
with the ALSA JACK plug-in I can even play games like Urban Terror. However=
, this is only an abuse test - don't use JACK as a generic sound server=
! (definitely never meant to be one, though it appears to be able to handle=
whatever you throw at it)
--001e680f18bc7ef10a046c59afbf--

On Sun, Jun 14, 2009 at 3:51 PM, Fons Adriaensen wrot=
e:
> AFAICS, Alsa has shot itself in the foot by trying to provide
> too much. Generally the 'driver' part works well, but all the
> user space things stacked on it have a tendency to fail to
> meet expectations, and IMHO should be replaced by some other
> solution.
>
> There should be *one* and only *one* entity setting the HW
> parameters - period, sample rate, format, etc. =A0*One* way to
> wait for and access sample data which provides no extra
> buffering, no conversions of any sort, and which requires
> the client to be real-time. Basically the way Jack uses Alsa.
> Providing software mixing on top of that would be relatively
> simple - Jack does it all the time. And there Alsa should
> end.
>
> All the rest - format and sample rate conversion, extra
> buffering allowing a client to be lazy and non-RT, other
> ways to access samples - should be provided by a library
> that apps link with, instead of trying to create 'devices'
> that try to provide the zillions of possible combinations
> and generally fail to do that.
lets be fair to ALSA. this design is a result of pressure from actual
app developers. i think you sometimes forget that the world of audio
programming extends way, way outside people who want the kinds of
things that we tend to want. take a look at phonon (from KDE) - this
is a living, breathing definition of the kind of thing that
non-pro-audio, non-music-creation, non-sound-installation audio app
developers imagine they want. but ALSA tries to give this same general
idea to them in a rather interesting way: your code doesn't vary when
you use a device that can support your data streams natively (in
hardware) versus when you use one that requires some extra conversion.
open "hw:0" and then do FOO. alternatively, open "plughw:0" and then
do FOO, regardless of the capabilities of the underlying hardware. FOO
remains constant. No "if (hw->can_support (sample_rate)) { ... }"
conditionals etc etc.
this was no small accomplishment, even if for the subset of the audio
programming world that we tend to inhabit, its largely irrelevant. the
idea that you can write a single chunk of audio io code, and
regardless of the capabilities of the underlying hardware, it will
just work - this was really quite a large goal for ALSA. maybe it
would have been preferable to have started with something more like
gstreamer - this behaves in a way similar to the broad goals that you
are describing, even if its API has some baroque complications. but i
think the vision/gaze/focus was just on a different model - open the
real hw, use it as-is, or open up a virtual device and have things
"just work".
where things maybe went wrong was the idea of defining a lot of
different *kinds* of virtual devices via a config file, including ones
that did multi-app multiplexing, device sharing, even i/o to
non-hardware devices like the ALSA JACK plugin.
now compare the situation with CoreAudio (i know, i know: i sound like
a broken record). there is only 1 sample format when interacting with
an audio interface. but there are lots of appallingly designed APIs
for stream conversion before you hit the "hardware". moreover the
device you open will do multiplexing to the real hardware *AND* sample
rate conversion automagically. yet - this whole system can be
reasonably easily made to reroute any applications audio via a
user-space system like JACK without the app even knowing anything
about it. there is also an "aggregate device" system similar to ALSA's
"multi" plugin, and which works even worse (or at least, in a way that
puts some absurd requirements on an app developer - oops, all playback
channels from your device just vanished). the similarities and
differences with ALSA are remarkable.
> If such a library had been created by the ALSA devs instead
> of all the 'plugins' we would not have needed any of the
> large collection of desktop servers we have now.
i don't think this is accurate. esd and artsd predated ALSA. when we
started work on JACK, nobody really knew how it should work (in terms
of implementation or API or general design). what does seem sad in
retrospect was that when we started JACK we did so in a context that
was deliberately "non ALSA". this had had costs - JACK lives outside
ALSA - but also benefits - JACK runs on all 3 major contemporary
operating systems. the goals for JACK at that time seemed like
something that was outside the scope of what ALSA was attempting to
accomplish, but in hindsight, it all seems very much part of the same
goal(s).
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

> Many people (including me) are using KDE4 and it's very clean and user centric
i found it overtly hostile to basic tasks, like finding a web browser in an app menu
plus it caused the boot-to-GUI proces to take 3 minutes
> no problem. Why do some people still have problem using an app just because
> it's a QT or KDE app? I don't get that.
because, at least on Gentoo, it requires compiling all of KDE and QT, which can be a multi-day affair (compare w/ 5 seconds for dwm, 10 mins for xorg, and 15 for webkit, a 'WebOS' system in a half hour)
then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver, dcop, etcetc, sucking 200 MB of ram
>
> Messy? No way!
the hodgepodge of panels and default icons was certainly messy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, 14 Jun 2009, carmen wrote:
>> Many people (including me) are using KDE4 and it's very clean and user centric
>
> i found it overtly hostile to basic tasks, like finding a web browser in an app menu
>
> plus it caused the boot-to-GUI proces to take 3 minutes
>
>> no problem. Why do some people still have problem using an app just because
>> it's a QT or KDE app? I don't get that.
>
> because, at least on Gentoo, it requires compiling all of KDE and QT, which can be a multi-day affair (compare w/ 5 seconds for dwm, 10 mins for xorg, and 15 for webkit, a 'WebOS' system in a half hour)
>
> then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver, dcop, etcetc, sucking 200 MB of ram
>
>>
>> Messy? No way!
>
> the hodgepodge of panels and default icons was certainly messy
All this KDE versus non-KDE is interesting, but I already know the
downsides of KDE itself. I don't run it all the time, but like having
it on my system as an available choice.
I was just wondering though whether v4 was quite ready, or whether I
should stick to KDE 3. I suppose there are a lot of opinions on that
though, since there's a lot of discussion on that already on the
Internet right now.
For me, it comes down to:
Do you think I should allow 'qt4' in $USE at this point, or should I
stick to 'qt3' only for now? Loaded question, I know...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, 2009-06-14 at 22:27 -0400, Paul Davis wrote:
> On Sun, Jun 14, 2009 at 3:51 PM, Fons Adriaensen wrote:
> > AFAICS, Alsa has shot itself in the foot by trying to provide
> > too much. Generally the 'driver' part works well, but all the
> > user space things stacked on it have a tendency to fail to
> > meet expectations, and IMHO should be replaced by some other
> > solution.
> >
> > There should be *one* and only *one* entity setting the HW
> > parameters - period, sample rate, format, etc. *One* way to
> > wait for and access sample data which provides no extra
> > buffering, no conversions of any sort, and which requires
> > the client to be real-time. Basically the way Jack uses Alsa.
> > Providing software mixing on top of that would be relatively
> > simple - Jack does it all the time. And there Alsa should
> > end.
> >
> > All the rest - format and sample rate conversion, extra
> > buffering allowing a client to be lazy and non-RT, other
> > ways to access samples - should be provided by a library
> > that apps link with, instead of trying to create 'devices'
> > that try to provide the zillions of possible combinations
> > and generally fail to do that.
>
> lets be fair to ALSA. this design is a result of pressure from actual
> app developers. i think you sometimes forget that the world of audio
> programming extends way, way outside people who want the kinds of
> things that we tend to want. take a look at phonon (from KDE) - this
> is a living, breathing definition of the kind of thing that
> non-pro-audio, non-music-creation, non-sound-installation audio app
> developers imagine they want. but ALSA tries to give this same general
> idea to them in a rather interesting way: your code doesn't vary when
> you use a device that can support your data streams natively (in
> hardware) versus when you use one that requires some extra conversion.
> open "hw:0" and then do FOO. alternatively, open "plughw:0" and then
> do FOO, regardless of the capabilities of the underlying hardware. FOO
> remains constant. No "if (hw->can_support (sample_rate)) { ... }"
> conditionals etc etc.
I understand that it was a huge leap at the time but......
I don't know nothing, and most probably things have changed a LOT since
then, but when I actually tried to write an alsa backend for snd a long
long time ago I failed[*]. You could either use the hw interface,
connect to the sound card directly and then deal with _everything_ in
your program, or you could use the plug interface and get the advantage
of automatic conversions, etc, etc, but then you would be _completely_
isolated from the hardware, you could _not_, for example, find out how
many _real_ channels the hardware behind the plug interface had (to
actually record from them!). It was impossible, you could not even find
which "hw" was behind "plughw" (everything could be potentially
reconfigured though confi files so your guess could be wrong, or at
least I convinced myself of that at the time). If you used plughw, ALSA
would happily tell you that it could record from something like 4
billion channels (or some other equally ridiculous number). This was not
"logically" wrong (and I remember arguing about this), but it was worse
than useless.
For me there was a disconnect between the needs of a programmer writing
a real app and what ALSA provided.
[*] to to take advantage of what alsalib supposedly could do :-)
> this was no small accomplishment, even if for the subset of the audio
> programming world that we tend to inhabit, its largely irrelevant. the
> idea that you can write a single chunk of audio io code, and
> regardless of the capabilities of the underlying hardware, it will
> just work - this was really quite a large goal for ALSA. maybe it
> would have been preferable to have started with something more like
> gstreamer - this behaves in a way similar to the broad goals that you
> are describing, even if its API has some baroque complications. but i
> think the vision/gaze/focus was just on a different model - open the
> real hw, use it as-is, or open up a virtual device and have things
> "just work".
In a real program that could record that was, I believe, impossible. Now
if you are talking about a simple program that would, say, play a
soundfile, then yes, of course it worked.
> where things maybe went wrong was the idea of defining a lot of
> different *kinds* of virtual devices via a config file, including ones
> that did multi-app multiplexing, device sharing, even i/o to
> non-hardware devices like the ALSA JACK plugin.
Oh yeah. I never could really find out or understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
-- Fernando
> now compare the situation with CoreAudio (i know, i know: i sound like
> a broken record). there is only 1 sample format when interacting with
> an audio interface. but there are lots of appallingly designed APIs
> for stream conversion before you hit the "hardware". moreover the
> device you open will do multiplexing to the real hardware *AND* sample
> rate conversion automagically. yet - this whole system can be
> reasonably easily made to reroute any applications audio via a
> user-space system like JACK without the app even knowing anything
> about it. there is also an "aggregate device" system similar to ALSA's
> "multi" plugin, and which works even worse (or at least, in a way that
> puts some absurd requirements on an app developer - oops, all playback
> channels from your device just vanished). the similarities and
> differences with ALSA are remarkable.
>
> > If such a library had been created by the ALSA devs instead
> > of all the 'plugins' we would not have needed any of the
> > large collection of desktop servers we have now.
>
> i don't think this is accurate. esd and artsd predated ALSA. when we
> started work on JACK, nobody really knew how it should work (in terms
> of implementation or API or general design). what does seem sad in
> retrospect was that when we started JACK we did so in a context that
> was deliberately "non ALSA". this had had costs - JACK lives outside
> ALSA - but also benefits - JACK runs on all 3 major contemporary
> operating systems. the goals for JACK at that time seemed like
> something that was outside the scope of what ALSA was attempting to
> accomplish, but in hindsight, it all seems very much part of the same
> goal(s).
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Monday 15 June 2009 05.52.23 carmen wrote:
> > Many people (including me) are using KDE4 and it's very clean and user
> > centric
>
> i found it overtly hostile to basic tasks, like finding a web browser in an
> app menu
>
> plus it caused the boot-to-GUI proces to take 3 minutes
20 seconds here! :-)
> > no problem. Why do some people still have problem using an app just
> > because it's a QT or KDE app? I don't get that.
>
> because, at least on Gentoo, it requires compiling all of KDE and QT,
> which can be a multi-day affair (compare w/ 5 seconds for dwm, 10 mins for
> xorg, and 15 for webkit, a 'WebOS' system in a half hour)
This is not a problem on *Ubuntus, Fedoras and other mainstream distros, it's
already compiled. I used LFS (manuell compilationa as oposite to Gentoo)
several years, and when I compiled apps like QT, I just did something else in
the meantime, like working, sleeping or whatever.
>
> then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver,
> dcop, etcetc, sucking 200 MB of ram
>
> > Messy? No way!
>
> the hodgepodge of panels and default icons was certainly messy
Perhaps you misunderstood me? I wrote apps (".. a QT or KDE app"), not
environment. :-) Gnome is neat and slick, I like it and many other people like
it, I just like KDE better.
Well, I can understand that people don't use a program because they don't like
it, or are using something that they think is better, but choose away an app
because of the tookit?. I don't like GTK and wxWidgets, but it's no way that I
stop using two of my favorite apps because their toolkits: Ardour (GTK)and
Audacity(wx). I even use wx on an Opensource project (SocratiMA) I'm working
on that will be finished by end of this year.
Jostein

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Sun, Jun 14, 2009 at 11:51 PM, Fons Adriaensen wro=
te:
> On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis wrote:
>
>> There is no "ALSA mixer" for multiplexing apps unless you mean dmix
>> and or a "share" plugin. Both of these "work" for some definition of
>> the term, but both have also been tested and found wanting as a
>> general solution to the problem of shared h/w access.
>
> 'For some value of the term' is quite correct, and one may wonder
> why that is the case.
>
> AFAICS, Alsa has shot itself in the foot by trying to provide
> too much. Generally the 'driver' part works well, but all the
> user space things stacked on it have a tendency to fail to
> meet expectations, and IMHO should be replaced by some other
> solution.
>
> There should be *one* and only *one* entity setting the HW
> parameters - period, sample rate, format, etc. =A0*One* way to
> wait for and access sample data which provides no extra
> buffering, no conversions of any sort, and which requires
> the client to be real-time. Basically the way Jack uses Alsa.
> Providing software mixing on top of that would be relatively
> simple - Jack does it all the time. And there Alsa should
> end.
>
> All the rest - format and sample rate conversion, extra
> buffering allowing a client to be lazy and non-RT, other
> ways to access samples - should be provided by a library
> that apps link with, instead of trying to create 'devices'
> that try to provide the zillions of possible combinations
> and generally fail to do that.
>
> If such a library had been created by the ALSA devs instead
> of all the 'plugins' we would not have needed any of the
> large collection of desktop servers we have now.
>
>
> Just my 2 eurocents, of course.
>
> Ciao,
>
>
> --
> FA
>
> Io lo dico sempre: l'Italia =E8 troppo stretta e lunga.
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
From just one "power" user's perspective, having alsa only do its bit
in the kernel, and jack do the rest sounds appealing. I think the alsa
team continue to do a great job, but maybe their workload could be
even easier to manage if they just did H/W devices/modules, and let
Jack "manage" as it seems to be specifically designed to do.
I use a lot of midi (big orchestral templates), and have had quite a
few adventures with timing, ports, etc..using alsa. I respectfully
suggest that in this area too, alsa only occupies itself in the
kernel, and jackmidi assumes the sample accurate responsibility for
any midi requirements.
Ergo, i respectfully ask devs for the few programmes that still use
alsa midi, to consider a push towards replacing it with, or adding
jackmidi, and then we'll all be singing from the same orchestral
score, to sample accurate level.
Then alsa can do what it does best, at kernel/hw device level, and
jack can take the blame/credit for the rest....
Alex.
-- =
www.openoctave.org
midi-subscribe@openoctave.org
development-subscribe@openoctave.org,
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Mon, 15 Jun 2009 01:52:23 pm carmen wrote:
> > Many people (including me) are using KDE4 and it's very clean and user
> > centric
>
> i found it overtly hostile to basic tasks, like finding a web browser in an
> app menu
Interesting
K->Applications->Internet->Web Browser (Firefox) does it here for me and seems
a pretty obvious location to me.... Also try K menu then type in "web" or
"fire" or "ope" on the keyboard... You can do this without the mouse by using
"Alt + F2".
There is a web browser by default in the favourites menu... (the first thing
you see when you click on the K) if your favourite browser is not the default
you can right click on it's menu entry and select add to favourites. You can
also remove items you don't use from the favourites menu by right clicking on
them.
Should you prefer a KDE3 style menu you can get that too by right clicking on
the K and selecting - Switch to classic style.
What would be a less "hostile" approach?
--
Your wise men don't know how it feels
To be thick as a brick.
-- Jethro Tull, "Thick As A Brick"
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Mon, Jun 15, 2009 at 1:14 AM, Fernando
Lopez-Lezcano wrote:
>
> Oh yeah. I never could really find out or understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
*NOTHING* could ever be that bad!
even the syntax of asoundrc is a stunning example of everything one
could ever wish for in a configuration system when compared to
sendmail rewriting rules. i guess the difference was that back in the
day, it seemed normal to have to learn stuff like that, whereas now
... kids these days!
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

--00151750de10b5828a046c625a5f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
GNOME has never managed to impress me one bit. It looks and acts like a 90's
environment. To me, the only reason for its mass adoption was Qt's licensing
(and history would agree). I see no technical or aesthetical benefit. It
took me only a couple of hours to create a small in-house cross-platform
accounting utility with Qt and Python - with the help of designer & py2exe.
It looks and works great on Linux _and_ Windows.
On the other hand, Enlightenment is a fine piece of art. Couple it with KDE,
disable composite extensions, and you have the perfect blend of beauty and
usability. With KDE, you get what you expect, you get what you want, and you
get what you see, unlike GNOME.
For audio though, one should look at Juce instead.
--00151750de10b5828a046c625a5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
GNOME has never managed to impress me one bit. It looks and acts like =
a 90's environment. To me, the only reason for its mass adoption was Qt=
's licensing (and history would agree). I see no technical or aesthetic=
al benefit. It took me only a couple of hours to create a small in-house cr=
oss-platform accounting utility with Qt and Python - with the help of desig=
ner & py2exe. It looks and works great on Linux _and_ Windows.
On the other hand, Enlightenment is a fine piece of art. Couple it=
with KDE, disable composite extensions, and you have the perfect blend of =
beauty and usability. With KDE, you get what you expect, you get what you w=
ant, and you get what you see, unlike GNOME.
For audio though, one should look at Juce instead.
--00151750de10b5828a046c625a5f--

On Mon, 15 Jun 2009 05:14:46 +0000
Fernando Lopez-Lezcano wrote:
> Oh yeah. I never could really find out or understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
*whimpering and resisting the urge to hide under the bed*
I remember having to modify a rule in sendmail.cf back in the days before
the web, before m4 macros, when 10Base5 was how we were wiring boxes together.
Do you have any idea how long it took me to figure out that tabs != spaces?
It took a sick, sick mind to come up with the obfuscated hell that is
sendmail.cf. I thought I'd gotten over the trauma, but the shakes have
returned, so perhaps I'm not really past it.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh@brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Fernando Lopez-Lezcano wrote:
>> Oh yeah. I never could really find out or understand how to deal with
>> that. Maybe I did not try hard enough. Right now thinking about it I am
>> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
>> was not that bad :-)
>>
Is there any such thing as a fond memory of sendmail.cf ?
Best,
dp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Ray Rashif wrote:
> GNOME has never managed to impress me one bit. It looks and acts like a
> 90's environment.
I'm not sure what a 90's environment looks and and acts like, could you
elaborate a bit?
Funny thing is, this must mean I just stepped down to an 80's
environment (openbox under arch), although I did this very deliberately
and it feels like a step *up* :-)
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Mon, Jun 15, 2009 at 6:58 PM, Atte Andre Jensen w=
rote:
> Ray Rashif wrote:
>> GNOME has never managed to impress me one bit. It looks and acts like a
>> 90's environment.
>
> I'm not sure what a 90's environment looks and and acts like, could you
> elaborate a bit?
>
> Funny thing is, this must mean I just stepped down to an 80's
> environment (openbox under arch), although I did this very deliberately
> and it feels like a step *up* :-)
>
> --
> Atte
>
> http://atte.dk =A0 http://modlys.dk =A0 http://virb.com/atte
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
Fluxbox and Gentoo here.
And i remember Cream's "White Room" from the FIRST time it came out.......
Dark side of the Moon anyone?
Alex.
-- =
www.openoctave.org
midi-subscribe@openoctave.org
development-subscribe@openoctave.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

alex stone wrote:
>
> Fluxbox and Gentoo here.
>
> And i remember Cream's "White Room" from the FIRST time it came out.......
>
> Dark side of the Moon anyone?
second generation listener, but sure :)
us, and them,
and after all we're only ordinary men
how did waters know about the gnome/kde quarrel in 73? ;)
reminds me of that great cartoon i saw years ago: a man and a boy hide
behind a trashcan in some huge metropolis, boy says, "why do we have to
hide from the police, daddy?", father responds, "because they use vi,
son. we use emacs."
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

Dave Phillips wrote:
> Fernando Lopez-Lezcano wrote:
>>> Oh yeah. I never could really find out or understand how to deal with
>>> that. Maybe I did not try hard enough. Right now thinking about it I am
>>> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
>>> was not that bad :-)
>>>
>
> Is there any such thing as a fond memory of sendmail.cf ?
oh yes, i have a recollection about it that borders on the erotic.
it happened on the day when i switched to postfix and went
$~> rm sendmail.cf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

--nextPart1321452.7Aguz9ndUh
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Monday 15 June 2009 16:01:44 Dave Phillips wrote:
> Fernando Lopez-Lezcano wrote:
> >> Oh yeah. I never could really find out or understand how to deal with
> >> that. Maybe I did not try hard enough. Right now thinking about it I am
> >> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> >> was not that bad :-)
> Is there any such thing as a fond memory of sendmail.cf ?
Maybe the day you deleted it because it was obsoleted?
Arnold, using KDE4 and liking it:P
--nextPart1321452.7Aguz9ndUh
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAko2g40ACgkQuYLL1cDjHx2+4QCbBNv0vZAhHSxu3tHRhR7Av9XT
iU0An0TB15JIFwjGGdzYo3A/7RmzUfNx
=F2hm
-----END PGP SIGNATURE-----
--nextPart1321452.7Aguz9ndUh--

I think I'm going to go with KDE 4, just because it's the future, like
it or not. Short of setting up a standalone machine that never gets
updated, no one can stay on KDE 3 forever, so I'm plunging forward.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

--00151757081e28e661046c67c9af
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Atte Andre Jensen
>
> I'm not sure what a 90's environment looks and and acts like, could you
> elaborate a bit?
>
> Funny thing is, this must mean I just stepped down to an 80's
> environment (openbox under arch), although I did this very deliberately
> and it feels like a step *up* :-)
That should've been obvious from the statement itself. Since GNOME looks and
acts like a 90's environment, a 90's environment looks and acts like GNOME.
OK, no more suspense. Basically, OS 9.
WMs like Awesome, Xmonad, *box are not in the equation. In fact, they _are_
a step up because they serve their purpose of being (lightweight or not)
window managers. I'm an Xmonad user as well.
--00151757081e28e661046c67c9af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Atte Andre Jensen <atte.jensen@gmail.com>

I'm not sure what a 90's environment looks and and acts like,=
could you
elaborate a bit?

Funny thing is, this must mean I just stepped down to an 80's
environment (openbox under arch), although I did this very deliberately
and it feels like a step *up* :-)That should'=
ve been obvious from the statement itself. Since GNOME looks and acts like =
a 90's environment, a 90's environment looks and acts like GNOME.
OK, no more suspense. Basically, OS 9.WMs like Awes=
ome, Xmonad, *box are not in the equation. In fact, they _are_ a step up be=
cause they serve their purpose of being (lightweight or not) window manager=
s. I'm an Xmonad user as well.
--00151757081e28e661046c67c9af--

--0016e6dd9670203634046c68ae8c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/6/15 J=F6rn Nettingsmeier
> alex stone wrote:
> >
> > Fluxbox and Gentoo here.
> >
> > And i remember Cream's "White Room" from the FIRST time it came
> out.......
> >
> > Dark side of the Moon anyone?
>
>
> second generation listener, but sure :)
>
> us, and them,
> and after all we're only ordinary men
>
>
> how did waters know about the gnome/kde quarrel in 73? ;)
http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.og=
g
;-)
A quarrel I will never get tired of
> reminds me of that great cartoon i saw years ago: a man and a boy hide
> behind a trashcan in some huge metropolis, boy says, "why do we have to
> hide from the police, daddy?", father responds, "because they use vi,
> son. we use emacs."
Ahh, freedom
/Robert

>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
--0016e6dd9670203634046c68ae8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/6/15 J=F6rn Nettingsmeier <nettings@fo=
lkwang-hochschule.de>
alex stone wrote:
>
> Fluxbox and Gentoo here.
>
> And i remember Cream's "White Room" from the FIRST time =
it came out.......
>
> Dark side of the Moon anyone?


second generation listener, but sure :)

us, and them,
and after all we're only ordinary men


how did waters know about the gnome/kde quarrel in 73? ;)=
http://spamatica.se/music/spamatica/default/spamatica=
_-_kde_vs_gnome-1.8.ogg
;-) A quarrel I will never get tired of

reminds me of that great cartoon i saw years ago: a man and a boy hide
behind a trashcan in some huge metropolis, boy says, "why do we have t=
o
hide from the police, daddy?", father responds, "because they use=
vi,
son. we use emacs."Ahh, freedom/Robert=A0


_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@l=
ists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-u=
ser

--0016e6dd9670203634046c68ae8c--

On Mon, Jun 15, 2009 at 05:14:46AM +0000, Fernando Lopez-Lezcano wrote:
> > where things maybe went wrong was the idea of defining a lot of
> > different *kinds* of virtual devices via a config file, including ones
> > that did multi-app multiplexing, device sharing, even i/o to
> > non-hardware devices like the ALSA JACK plugin.
> =
> Oh yeah. I never could really find out or understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
First thing I do when installig Fedora is remove sendmail
and install postfix - for the sole reason that I'm capable
of configuring postfix in less than 48 hours :-)
Seriously now, talking about ALSA let's just consider resampling.
Assume your hardware is running at 48 kHz and you want to use =
44.1 kHz.
Typical audio hardware will interrupt whenever it has N =
samples available for reading and writing, where in many
cases N will be a power of 2.
Now if you resample that you have basically two choices:
1. Keep the 'period time' generated by the HW, i.e. provide
an interface that will trigger its client at the same rate.
The consequence is that you don't have a fixed number of
samples (in this example, if the HW period is 1024, you
would have eiter 940 or 941 samples in a period). This =
would be unacceptable to some clients, e.g. Jack.
2. Try to create an interface that will offer a fixed 2^n =
period size. This requires extra buffering, in other words
increased latency. And the timing of such periods will be
irregular. In some cases a HW capture buffer will not be
sufficent to generate a resampled buffer, you have to wait
an extra period and you better have some samples buffered if
the client wants them. In a similar way, a single playback
buffer could complete two HW buffers, forcing you to store
one of them. If you want the period times to be more or less
regular, this again requires more latency. =
A client would quite legitimately expect the two resampled
streams (capture and playback) to have the same period timing,
as they would have for direct HW access. But in ALSA dmix and
share are independent plugins, so anything goes. And even if
they were coupled, synchronising the two streams could again
imply more latency (it's possible but not simple to avoid =
this).
The conclusion is that resampling at the sound card API, if
this is in any way 'period based' breaks things, at least in
the sense that it introduces more latency than the resampling
operation (which implies filtering and hence delay) does on its
own.
And there is no good reason for ever doing that. =
Applications like soft synths should be capable of generating
their output at the sample rate imposed by the hardware. The
*only* cases were resampling is really needed is when dealing
with *stored* data (either being read or written). But in that
caes there will be buffering between the storage and the RT
audio code, and *that* is the right place to apply resampling,
it costs nothing (in terms of timing) if done there.
Ciao,
-- =
FA
Io lo dico sempre: l'Italia =E8 troppo stretta e lunga.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Mon, Jun 15, 2009 at 5:40 PM, Fons Adriaensen wrote:
> Typical audio hardware will interrupt whenever it has N
> samples available for reading and writing, where in many
> cases N will be a power of 2.
neither USB nor firewire devices work this way, and are instead based
on clocks that are unrelated to audio sample rate. i believe that you
know this :)
> The conclusion is that resampling at the sound card API, if
> this is in any way 'period based' breaks things,
this is part (a big part) of the reason why CoreAudio's HAL API is not
based on hardware interrupts at all. it adds a small amount of latency
(and i continue to suspect that apple is playing conservative with
their "safety buffer"). the system is elegant (its basically a DLL
with a small offset built in), allows resampling and many other cool
things. PulseAudio is also using a similar model layered "above" ALSA.
> And there is no good reason for ever doing that.
> Applications like soft synths should be capable of generating
> their output at the sample rate imposed by the hardware. The
> *only* cases were resampling is really needed is when dealing
> with *stored* data (either being read or written). But in that
> caes there will be buffering between the storage and the RT
> audio code, and *that* is the right place to apply resampling,
> it costs nothing (in terms of timing) if done there.
infrastructure like gstreamer has done this for years. problem is (a)
the architecture is baroque (b) their resampler is poor quality and an
unbelievable CPU hog.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Monday 15 June 2009 22.12.40 Robert Jonsson wrote:
> http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.og
>g
>
> ;-)A quarrel I will never get tired of
Hey, this is really cool, haven't heard this before! :-)
J.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

--001636c5b7e46667c9046c76bb62
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
2009/6/16 Jostein Chr. Andersen
> On Monday 15 June 2009 22.12.40 Robert Jonsson wrote:
> >
> http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.og
> >g
> >
> > ;-)A quarrel I will never get tired of
>
> Hey, this is really cool, haven't heard this before! :-)
Thank you, it's an old tune that never seems to get too old... :)
Regards,
Robert
--001636c5b7e46667c9046c76bb62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/6/16 Jostein Chr. Andersen <jostein@vait.se>=

On Monday 15 June 2009 22.12.40 Robert Jonsson wrote:
> http://spamatica.se/music/spamatica/def=
ault/spamatica_-_kde_vs_gnome-1.8.og
>g
>
> ;-)A quarrel I will never get tired of

Hey, this is really cool, haven't heard this before! :-)Thank you, it's an old tune that never seems to get too old... :=
)Regards,Robert
--001636c5b7e46667c9046c76bb62--

On Mon, 2009-06-15 at 12:43 -0500, Brent Busby wrote:
> I think I'm going to go with KDE 4, just because it's the future, like
> it or not. Short of setting up a standalone machine that never gets
> updated, no one can stay on KDE 3 forever, so I'm plunging forward.
>
This is a rather blanket statement.. Linux is each to their own "freedom
of choice"... If someone gets the functionality they need from a wm and
it happens to be manually configured (like the old days)..
for those of us that have been using linux for "pro" audio purposes for
a while we have learnt that an non-obtrusive wm tends to allow for lower
latencies (less polling happening)...
but as I said each to their own..

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Monday 15 June 2009 13:16:20 J=F6rn Nettingsmeier wrote:
> Dave Phillips wrote:
> > Fernando Lopez-Lezcano wrote:
> >>> Oh yeah. I never could really find out or understand how to deal with
> >>> that. Maybe I did not try hard enough. Right now thinking about it I =
am
> >>> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> >>> was not that bad :-)
> >
> > Is there any such thing as a fond memory of sendmail.cf ?
>
> oh yes, i have a recollection about it that borders on the erotic.
> it happened on the day when i switched to postfix and went
> $~> rm sendmail.cf
It seems to me that to have braved sendmail and telling these anecdotes is =
very much like veteran war stories...
sincerely,
marije
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Thu, 18 Jun 2009, allan wrote:
> On Mon, 2009-06-15 at 12:43 -0500, Brent Busby wrote:
>> I think I'm going to go with KDE 4, just because it's the future, like
>> it or not. Short of setting up a standalone machine that never gets
>> updated, no one can stay on KDE 3 forever, so I'm plunging forward.
>
> This is a rather blanket statement.. Linux is each to their own "freedom
> of choice"... If someone gets the functionality they need from a wm and
> it happens to be manually configured (like the old days)..
>
> for those of us that have been using linux for "pro" audio purposes for
> a while we have learnt that an non-obtrusive wm tends to allow for lower
> latencies (less polling happening)...
>
> but as I said each to their own..
It's true, very true that in Linux, nobody's making your update your
software. But my studio machine is not so dedicated that it's not also
on the Internet. I like getting security updates...and eventually,
there comes a point where a KDE 3 desktop is just not patchable anymore.
Since I posted that, I decided to go with KDE 3 afterall, and did
install it, but I still know I can't stay forever...not if I want to
keep on getting security support.
On the bright side, it's not as obnoxious as some company changing their
file formats every release version just to keep you upgrading because
they arbitrarily want to keep taking your money.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user