Hello everybody:
After some exchange of posts in this thread:

http://puredata.hurleur.com/sujet-5578-old-toughbook-useful-live-events

I told @katjav and @PonZo that soon I was going to post a log of a Real-time Kernel compilation and installation for Debian based machines, so that Pd would run fast and smooth in any machine, even a small netbook. I only found the log of the compilation of a desktop machine, but the process is the same, adjusting the choices to the equipment features. I hope this encourages you to compile your own Real-time kernel.
You can download the pdf file from here:

http://dl.dropbox.com/u/6086343/HowToCompileARealTimeKernelForDebian.pdf

Extra data:
You can find out the chipset name of your audio card using this command:

# cat /proc/asound/cards

There are some extra tweaks needed to develop real-time performance:

Install jack with its graphic front end:

# aptitude install qjackctl

Once installed, it prompts us to configure automatically this file:
/etc/security/limits.d/audio.conf

We agree and then we tweak this other file opening it with any text editor (always in root mode).

# gedit /etc/security/limits.conf

Then we add these lines at the bottom of the limits.conf file to assign high and real-time priorities to the @audio group:

@audio - rtprio 99
@audio - memlock unlimited
@audio - nice -10

Don't forget to add your user to the @audio group:

# adduser <userName> audio

I hope it works for you too. Best regards to all of you.

Sumidero

Hi Sumidero,

Thanks for all the work. I understand you did the translation specially for us, the Pd forum. This will be very useful for many people who are now still in doubt whether to start such a complicated operation. Even though I don't understand all the details yet, it gives a good impression of the (amount and type of) work involved.

With eventual addition of other people's experiences, your detailed description could evolve into a tutorial/howto, which should be on a prominent location so everyone can find it, in the tutorial/howto's section of puredata.info for example.

Well I still have to find that target computer to install Linux on, so it may take a while before I will report experiences, comments or questions. For now, thanks, again.

Katja

Yea! I almost wish that you hadn't included the log - it is very intimidating but also indispensable for reminding noobs like me about permissions problems and demonstrating that errors can be overcome with persistence.

The Delta series cards work great. What do you know about setting the IRQ priorities? I know that I did this at one point but didn't script it because the PIDs change with each boot (there's a way to fix that). Is it necessary to change IRQ priorities in addition to the @audio rtprio set at 99?

I'm still concerned about the video card issues. Are we simply limited to NVidia or Radeon? And neither one likes the real-time kernel much.

I just do without 2D acceleration in my patches when I boot the real time kernel but it is so frustrating that I cannot use GEM.

https://help.ubuntu.com/community/RadeonDriver

I'll take these steps to switch to the open source driver and see if that works out with my current real-time kernel.

Thanks again.

J.P.

So switching to the open-source drivers supports 2d 3d acceleration on my Radeon, kernel 2.6.33-4 rt Ubuntu 64 10.04 and allows for use of Gem.

last edit: The howto at:
https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver#Problem:%20%20Need%20to%20fully%20remove%20-fglrx%20and%20reinstall%20-ati%20from%20scratch
worked like a charm but I did have to edit
/etc/X11/xorg.conf
Driver "fglrx"
needs to be
Driver "ati"

Don't read the rest of this post.

Okay, I managed to lose my gnome for a while there...ugh...I guess that I had disabled gdm because I needed to put a calibration for my touchscreen into the .xinit script, so I always boot to a line and startx. This is not true right, I can run any script from anywhere, right? I really am a Linux noob, I only use it for performance and tread very lightly on its cryptic modules and scripts.

And I just created a gemwindow, huzzah.

Now to invert the axes of the touch screen somehow...geez...

Typed the stuff from my xinit script, xinput set-int-prop blah blah blah and immediately fixed. Great. If anyone is setting up Elo TouchScreen I have posted that blah blah blah somewhere in the forum.

I was going to ask a question but I won't embarrass myself - yall know the expression "mickey-mouse" ? Lot's of what I do is "mickey-mouse" - like logging into Ubuntu as jhutchins, then typing sudo start gdm, then logging in as jhutchins.

G'night, time to make some gems.

performance: Slice//Jockey eats 40% of one core spinning at 800MHz

settings: Jack can't seem to get less than 256 Frames/Period which results in an 11.6 ms latency - I usually set PD's audiobuffer to 12ms because of the figure from Jack - is that correct practice? I will often set PD to 6ms without issue, but what is really going on here?

Hello mates:
Thank you very much for your replies.
There are two things: my log of compilation is something like try and error when following a not-so-clear path. It can be neater if I "reshape" the entire how-to/log as a tutorial. Thanks to @katjav for the suggestion. I will tidy up the document and see if I can include more general info. I'm sure that there should be a link to a wiki-lke tutorial in puredata.info page. By the way, I'm not a low level prorgammer or GNU/Linux expert. I'm into this OS since three years ago and less than a year in Pd. I learn a little more everyday.
Second thing: congratulations for your improvements! You made me laugh, @PonZo, with the "mickey-mouseing". Yes, I know the term. We took courage to obtain the results we needed. @katjav needed a fast and good attack detector and she swam in C code to make the slicerec~/slicecycle~ amazing objects, you needed rt kernel and GEM working (also with a working touchscreen) and took courage to tweak and configure your system, xorg, etc, and I compiled a rt-kernel. Hands on things. I feel like belonging to a very nice team.
About the audio buffer and jack setup, I did not research enough to give you an answer. I use a 23.2ms latency in jack (256 frames, 4 periods @44.1KHz) and 30ms in pd so as to give the CPU time for computation. Soon I will be finishing a sampler in Pd for which I will need performance, I'll check on that then and then post the performance.
Keep on coding and tweaking !!
Thank you, mates, for you kind sharing.

Sumidero

I'm just too lazy - I'll run a timer and see if the latency is the sum of jack and PD, one or the other, or what. Either way, at 12ms latency in each program it's good enough to play the midi keyboard.

Edit: Jack controls latency, PD's setting is irrelevant it seems?

Thanks for all of your hard work - between the old timers on here and the new energy Pure Data 0.42.5 is looking like a much more flexible machine than it did just 6 months ago!

I'm gonna go try this stuff:

http://subversion.ffado.org/wiki/IrqPriorities

IRQ prios were all in order, my A/D/A sync issues have been resolved by installing cpufreq allowing the CPU to run at 3200MHz instead of 800MHz - because of my phrase driven patches many atoms are sent flying on downbeats, especially at 8 bar phrases resulting in what I would compare to a "transient peak" of arithmetic. The CPU frequency scaling of course does not adjust fast enough to deal with this the result being audio dropouts...at last the pain of consistent A/D/A sync errors seems to have passed.

For the record, if you are running any firewire hardware under Linux you will need to make the rtirq.sh script described in the above link to achieve the lowest latencies.

Compiled a real time Linux kernel for Panasonic CF-74 toughbook with SigmaTel STAC9200 soundchip.

• kernel 2.6.33.13
• patch 2.6.33.9-rt31

The numbers do not exactly coincide but this was what came closest. Thanks to Sumidero's log, and also with help from a Linux friend, compilation proceeded without problems. In the 'staging drivers' section in the kernel source there's a lot of garbage code leading to warnings and errors (notably 'comedi drivers') so it's best to disable as much modules as possible here.

Pd can run with 10 ms buffer under the real time kernel. No DIO errors, even with fairly elaborate patches. I am using this kernel with Debian Squeeze. GEM works (unfortunately it is compiled without font support in this binary distribution, but this is unrelated to the real time kernel or to Debian Squeeze).

Regarding CPU load of Pd dsp, there is no difference with the non-rt kernel I used before (2.6.32). As I understand it, the real time kernel only differs from non-rt in the aspect that priority is given to real time processes so they are not interrupted by other tasks. Absence (or minimization) of xruns is the key feature, and that is indeed where I notice a difference. With the non-rt kernel, Pd window showed DIO errors regularly, though there were no audible drop outs yet. Then I had the buffer at 50 ms, and now with the rt kernel I can go down to 10 ms without errors.

Katja

Congratulations! You made my day happier, thank you. Keep on coding.
See you, mates.

Sumidero