Re: ck vs. cfs : realtime audio performance

Re: ck vs. cfs : realtime audio performance

[Lenar Lõhmus]

Cc'd to LKML & Ingo.

L.

Klaus Schulz wrote:
> Hi there.
>
>
>
>
> Am Dienstag, den 31.07.2007, 10:26 +0200 schrieb Klaus Schulz:
>   
>> Hi folks.
>>
>> 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.
>>
>> However:
>>
>> When looking at the latest performance statistics cfs vs. ck which are
>> spread around here, I am wondering, what might cause the differences.
>>
>> With ck I tweaked the rr_interval to 6 and was running at 10000Hz,
>> which caused obvious improvements.
>>
>> These options I do not have with CFS.
>>
>> I am wondering if sched_granularity_ns should be touched when using cfs.
>> I googled somewhere that bringing it down to e.g. 250000 instead of
>> 4000000 would smoothen the audio playback. I havn't tried it yet. I am
>> wondering if this tweak is still applicable.
>>     
>
>
>
> I did test now decreasing the sched_granularity_ns to 250000.
> There is still a clearly audible difference comparing ck and cfs. 
> ck Ídelivers cristal clear sound. With cfs I still get quite some
> distortions. 
>
> Any hints how to improve the situtation are welcome. 
>
>
>
>   
>> I'd be happy to get a hint on how to tweak the system parameters best to
>> give cfs a fair chance. I am also wondering how the timer freqency could
>> by increased under a cfs-patched kernel.
>>
>> Info: dynamic ticks and IRQ balancing are off for the time being.
>>      /proc/sys/dev/rtc is set to 4096 (gave me best results)
>>      ( I don't have a clue how all the (rtc)-timers in the OS interact,
>>        To me it is just a trial and error exercise to figure out which
>>        setup sounds best)
>>
>> THX for your advise. 
>>
>> Cheers
>> \Klaus
>>     
>
>
> Cheers
> \Klaus
>
>
> _______________________________________________
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: ck@vds.kolivas.org
> http://vds.kolivas.org/mailman/listinfo/ck
>   

Re: ck vs. cfs : realtime audio performance

[Ingo Molnar]

> >Am Dienstag, den 31.07.2007, 10:26 +0200 schrieb Klaus Schulz:

> >>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.
> >>
> >>However:
> >>
> >>When looking at the latest performance statistics cfs vs. ck which are
> >>spread around here, I am wondering, what might cause the differences.
> >>
> >>With ck I tweaked the rr_interval to 6 and was running at 10000Hz,
> >>which caused obvious improvements.
> >>
> >>These options I do not have with CFS.
> >>
> >>I am wondering if sched_granularity_ns should be touched when using cfs.
> >>I googled somewhere that bringing it down to e.g. 250000 instead of
> >>4000000 would smoothen the audio playback. I havn't tried it yet. I am
> >>wondering if this tweak is still applicable.

(re-sending my earlier reply to Klaus here on lkml too)

Klaus,

since you are using -rt, have you tried chrt-ing not only your audio
player but your audio IRQ as well? While playback is going on could you
create a system snapshot with the following tool:

  http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh

and send me the output file.

i'm also wondering why HZ=10000 makes a difference - audio interrupts
have no Linux-timer aspect normally (they are hardware timers in essence
themselves) - which portion of the workload is timing out so that HZ
shows up? Does the enabling of CONFIG_HIGH_RES_TIMERS help perhaps?

Also, do you have any advice for me how to reproduce your problem? I've
got a couple of PCs with various low-end/chipset-based audio hw, but the
buffers are generally large (around 500 msecs) so i rarely run into any
xrun problems. Is your player available for download so i could try it?

	Ingo

Re: ck vs. cfs : realtime audio performance

[Carlo Florendo]

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


-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp


-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: ck vs. cfs : realtime audio performance

[Klaus Schulz]

Hello Carlo.

The ranters! comment:

I can understand your way of looking at things.
But you'd better be a bit more careful with statements like these below, 
if you don't really know what's going on.

Just FYI: All possible traces - Ingo asked for - are on Ingos desk!

My intention is to support you folks as good as I can to get the issues solved.

As a user, with a rather limited knowledge about ck or cfs, I am just able to 
judge on the results these patches are delivering. 
I'll go always for the one  - if I have a choice - matching my requirements! 

Since there is just one patch left in the near future, at least the way it looks to me today, 
I am trying of course to support Ingo the best I can to identify potential issues.

Constructive critism - always welcome! 

Best regards
\Klaus


> -----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
> 
> 
> -- 
> Carlo Florendo
> Softare Engineer/Network Co-Administrator
> Astra Philippines Inc.
> UP-Ayala Technopark, UP Campus Diliman
> 1101 Quezon City, Philippines
> http://www.astra.ph
> 
> --
> The Astra Group of Companies
> 5-3-11 Sekido, Tama City
> Tokyo 206-0011, Japan
> http://www.astra.co.jp
> 
> 
> -- 
> Carlo Florendo
> Softare Engineer/Network Co-Administrator
> Astra Philippines Inc.
> UP-Ayala Technopark, UP Campus Diliman
> 1101 Quezon City, Philippines
> http://www.astra.ph
> 
> --
> The Astra Group of Companies
> 5-3-11 Sekido, Tama City
> Tokyo 206-0011, Japan
> http://www.astra.co.jp
> 


_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

Re: ck vs. cfs : realtime audio performance

[Carlo Florendo]

Klaus Schulz wrote:
> Hello Carlo.
> 
> The ranters! comment:
> 
> I can understand your way of looking at things.
> But you'd better be a bit more careful with statements like these below, 
> if you don't really know what's going on.
> 
> Just FYI: All possible traces - Ingo asked for - are on Ingos desk!

Then that's very good :)  I was just wondering on what possibly happened to 
the problem since the person who forwarded your concern from the ck list to 
the lkml (I don't subscribe to the ck list) didn't have a follow-up after a 
few days.

And as far as the public list archives are concerned, there were no stats 
posted as Ingo had asked for.  It seems though that you had done privately, 
then that's very good.

Since your problem had already been posted online, I thought that any 
person who might've had a similar problem like yours would benefit from 
knowing what steps got undertaken to address the problem.  I particularly 
was interested in your problem since I myself do a lot of music in Linux. 
I'm very sure that if your problem got discussed on-line, many linux-user 
musicians/programmers would benefit from it, like myself.

Sorry if I have offended you and please accept my apologies.

Thank you very much.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

Re: [ck] Re: ck vs. cfs : realtime audio performance

[Martin Steigerwald]

[-- 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 --]

Re: [ck] Re: ck vs. cfs : realtime audio performance

[Martin Steigerwald]

Am Donnerstag 02 August 2007 schrieb Martin Steigerwald:

> 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. [...]

Well, if Carlo is not a Linux Kernel manager this comment of mine is 
inapprobiate. Sorry for that.

Actually when I remind myself of all the responses I got from Ingo I did 
not see anything like that what I have complained about here. I take that 
as something where I can learn something: Not nearly every Linux Kernel 
manager is a mean and unfriendly bastard who accuses everyone who wants 
something merged or has a problem report. ;) (At least Ingo did not 
accuse me for my problem reports. If I ever happen to dig that deeply 
into the kernel or its documentation that I have something to merge 
regarding the scheduler, I can try how he reacts to that...)

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

Re: ck vs. cfs : realtime audio performance

[Ingo Molnar]

* Carlo Florendo <subscribermail@gmail.com> wrote:

>>>> 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.

actually, there was no "SD ranting" going on at all. Klaus reported a 
problem, Martin forwarded it to me, i replied to it and Klaus gave me 
lots of debug info in a very professional way. So please calm down and 
lets get back to the tech topics, ok? (and i'd like to apologize here to 
Karl and Martin for the rough and unjust treatment they received on 
lkml.)

	Ingo

Re: [ck] Re: ck vs. cfs : realtime audio performance

[Carlo Florendo]

Martin Steigerwald wrote:
> Am Donnerstag 02 August 2007 schrieb Martin Steigerwald:
> 
>> 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. [...]
> 
> Well, if Carlo is not a Linux Kernel manager this comment of mine is 
> inapprobiate. Sorry for that.

I am not a kernel manager, just a simple Linux user.

I'm very very sorry if I have hurt anyone in this thread.

Thank you very much.

Best Regards.

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp