Date:	Thu, 2 Aug 2007 18:47:44 +0200
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	ck@....kolivas.org, whansard@...global.net
Cc:	linux-kernel@...r.kernel.org,
	Carlo Florendo <subscribermail@...il.com>,
	Lenar Lõhmus <lenar@...y.ee>,
	Klaus Schulz <Klaus.Schulz@....de>
Subject: Re: [ck] Re: ck vs. cfs : realtime audio performance


Stripped CC list restored.

Am Donnerstag 02 August 2007 schrieb Will:
> > > -----Ursprüngliche Nachricht-----
> > > Von: Carlo Florendo <subscribermail@...il.com>
> > > Gesendet: 02.08.07 08:27:01
> > > An: Lenar Lõhmus <lenar@...y.ee>
> > > CC: Klaus Schulz <Klaus.Schulz@....de>, ck@....kolivas.org,
> > > linux-kernel@...r.kernel.org, mingo@...e.hu Betreff: Re: ck vs. cfs
> > > : realtime audio performance
> > >
> > > Lenar Lõhmus wrote:
> > > > Klaus Schulz wrote:
> > > >>> I am currently testing the 2.6.22.1 cfs-rt9 vs. ck1 on my
> > > >>> rather pure realtime high-end-audio setup. (NO X, just a
> > > >>> terminal, streaming .wav. I am using my own written player and
> > > >>> brutefir as the audio engine.)
> > > >>> Comment: This is not a standard (amarok or xmms setup), all
> > > >>> buffers in the chain are very small. Any problem will
> > > >>> immidetialy end up in xruns. The sounddriver, HW (pci-bus etc.)
> > > >>> are tweaked accordingly Until now ck1 on 2.6.22 is giving me
> > > >>> better results (less audible distortions) and runs extremely
> > > >>> stable compared to cfs. Under ck I ran my player with schedtool
> > > >>> -R -p 98, which was better than running it e.g. with nice -20
> > > >>> Both setups under cfs were giving me worse results than ck.
> > > >>> With CFS I also experienced XRUNS from time to time, what never
> > > >>> happened with ck.
> > >
> > > See, this is exactly the problem of the SD ranters.  A ranter posts
> > > a problem, doesn't give reproducability hints, and neither provides
> > > technical detail, not even the slightest relevant stats.  And the
> > > most irritating part is that the code that the OP wrote (or at
> > > least its relevant parts) is not even available for download.
> > >
> > > I was wondering why the OP need timers for audio playback.  What
> > > type of audio?  PCM, MIDI?  Once does not need timers for PCM
> > > playback but for MIDI.
> > >
> > > SD ranters. Pure rants.
> > >
> > > Thank you very much.
> > >
> > > Best Regards,
> > >
> > > Carlo
>
> I just think it's funny that there's a group of "SD Ranters", and that
> they have a problem, or cause a problem, or both.  And someone
> has been sitting around trying to figure just what the problem is
> with these "SD Ranters".

And I just think this is getting more and more ridiculous.

If Klaus writes he has given Ingo all debug information Ingo requested, I 
have no reason to believe otherwise until Ingo says he did not receive 
the information. And before it is clear that this information has not 
been given, I would not assume this. And if its not in the public post by 
no way this means they have not been given to the person(s) in charge to 
fix that potential problem.

I am really upset, cause its actually quite some of those "SD ranters" 
that actually helped Ingo to get CFS to match the experience that SD gave 
to them. And it didn't match it initially. (It now seems to do here and 
thats fine of course.)

Well I think I will just continue to send Ingo pointers to things that 
look like regression reports *privately*. Cause that avoids the "rants 
against anyone who looks remotely like someone who likes SD" quite 
effectively.

The tone I see on responses to posts that are CCed to LKML in my 
perception often is just completely and utterly awfully unfriendly. And 
often those responses actual include factual inaccuracies and preliminary 
assumptions as well. Is that how Linux Kernel Management Style is 
supposed to work? I hope not. Once in a while IMHO it makes a lot of 
sense to learn at least some of the basics about how communication works! 
Cause otherwise you get what happens here.

I do not know how Klaus feels now, but I wouldn't be surprised when he was 
fed up by getting this back when actually he tries to help debugging a 
potential problem - likely in this free and unpaid time. What would have 
been if Klaus did not write that he used SD? I think he would have been 
treated quite differently then.

So now to me it seems LKML people begin to scare away people who actually 
help debugging CFS just cause they like SD as well - as if scaring away 
Con was not enough. When I see this I more and more understand Con's 
decision to stay away from anything that even remotely has something to 
do with Linux Kernel development.

If people just started to say they are angry, cause ... instead of 
accusing one another that would be a good start. What Carlo has said 
could have been said as well like this:

"Hi Klaus!

I did not found any information on how to reproduce the problem in your 
post. I am quite upset about this, cause I think people who like SD often 
do not provide good informations on how to reproduce a problem with SD.

Could you please provide these informations?

What audio settings do you use? ...

Thanks.

Regards,
Carlos"

That in my perception would transport exactly the same facts, but it would 
have a completely different impact on the people involved. It would 
encourage involvement instead of scaring it away. It even would not be 
longer than the original post by Carlo.

Tthats in no way meant against you, Carlo, everyone - including myself - 
can learn to communicate in that way. I try to do it, but with differing 
success. Its not easy to stay with myself when I am upset, cause then I 
have to feel my emotions in me instead of venting them off at the cost of 
other people.

(Actually I want to stay away from this discussion at the moment, but I am 
really upset when I see such kind of communication in threads where 
people are working on *solving* potential problems.)

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists