[PD] Real-time Linux; hard req. and suggestions?

Chuckk Hubbard badmuthahubbard at gmail.com
Fri Sep 8 06:51:53 CEST 2006

I was trying to do this too, and ended up compiling a Debian realtime
kernel, but the best suggestion I got was from Andy, who said to use
renice -10 pd
renice -10 jackd
*after* starting jack and Pd; the idea being to set the audio engine
of Pd to a higher priority than the gui part of it.
Beyond that I don't know.  I'm back to Windows, as the music notation
of Linux isn't quite where I would need it.

On 9/8/06, Charles Henry <czhenry at gmail.com> wrote:
> Hello, all,
>   We all have probably experienced some interruptions in sound when
> using Pd.  My usual solution has been to increase the size of the
> audio buffer til the interruptions occur less frequently, and I've
> tried using -rt.  I've tried hacking the kernel (the easy
> way--menuconfig) to enable preemptible options.  Somehow, it's just
> not satisfying.
> I've started learning a bit about alternative kernels for real-time
> linux, and I've got some masochistic notion to investigate Linux From
> Scratch.  One of my friends says this is his favorite way to build a
> system...I have a lot to learn.
> I'm currently using Fedora Core 4 with the 2.4.19 kernel on a 1.6 GHz
> Sempron processor (could be upgraded to an Athlon64).  I'm not sure
> which system specs are most important for getting good throughput,
> front side bus, memory access speed...how to balance them?
> The graphical interface run by Xwindows puts more demands on the
> system.  I admit to not knowing enough about how an OS really works,
> but one concern I have is that the graphical rendering can hurt audio
> performance.  If I follow through on this idea, I'll learn more as I
> go.
> I've been reading some articles on www.linuxdevices.com and
> www.realtimelinuxfoundation.org which of course raised some questions.
> The "hard real time" spec refers to a certain maximal time frame for
> execution of a block of code.  For instance, with Pd, there's an audio
> buffer of 64 samples transferred from sound card to RAM, which I think
> requires a system interrupt.  Then, Pd has to be scheduled to run
> every 64 samples as well.  At 44,100 Hz this is about .7 ms.  So, the
> vexing questions about this...Is there a lower bound (shortest time)
> for running a dsp cycle using Pd?  What would be a large enough "hard
> real time" spec to run Pd successfully?
> Just how low can your latency go?
> Any advice for choosing a kernel (my first step) is much appreciated ;)
> Chuck
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

"Far and away the best prize that life has to offer is the chance to
work hard at work worth doing."
-Theodore Roosevelt

More information about the Pd-list mailing list