From: Martin Steigerwald <Martin@lichtvoll.de>
To: ck@vds.kolivas.org, whansard@sbcglobal.net
Cc: linux-kernel@vger.kernel.org,
"Carlo Florendo" <subscribermail@gmail.com>,
"Lenar Lõhmus" <lenar@city.ee>,
"Klaus Schulz" <Klaus.Schulz@web.de>
Subject: Re: [ck] Re: ck vs. cfs : realtime audio performance
Date: Thu, 2 Aug 2007 18:47:44 +0200 [thread overview]
Message-ID: <200708021847.49271.Martin@lichtvoll.de> (raw)
In-Reply-To: <20070802115952.6cd4b217.whansard@sbcglobal.net>
[-- Attachment #1: Type: text/plain, Size: 5868 bytes --]
Stripped CC list restored.
Am Donnerstag 02 August 2007 schrieb Will:
> > > -----Ursprüngliche Nachricht-----
> > > Von: Carlo Florendo <subscribermail@gmail.com>
> > > Gesendet: 02.08.07 08:27:01
> > > An: Lenar Lõhmus <lenar@city.ee>
> > > CC: Klaus Schulz <Klaus.Schulz@web.de>, ck@vds.kolivas.org,
> > > linux-kernel@vger.kernel.org, mingo@elte.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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-08-02 16:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 7:57 ck vs. cfs : realtime audio performance Klaus Schulz
2007-08-02 9:06 ` Carlo Florendo
[not found] ` <20070802115952.6cd4b217.whansard@sbcglobal.net>
2007-08-02 16:47 ` Martin Steigerwald [this message]
2007-08-02 16:59 ` [ck] " Martin Steigerwald
2007-08-03 0:14 ` Carlo Florendo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708021847.49271.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=Klaus.Schulz@web.de \
--cc=ck@vds.kolivas.org \
--cc=lenar@city.ee \
--cc=linux-kernel@vger.kernel.org \
--cc=subscribermail@gmail.com \
--cc=whansard@sbcglobal.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox