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
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. -Chuckk
On 9/8/06, Charles Henry czhenry@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Charles Henry wrote:
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?
First step would be to split Pd into a "hard real time" DSP thread and a "non real time" Message Processing thread, because message processing does not have an upper bound in processing time (while once a DSP chain is compiled, it generally takes the same amount of time to execute each block - the lower bound would be with something like [adc~]--[dac~] but it's the upper bound that's important).
For example, "bang"--[until] - if you run this in a "hard real time" thread, behaviour is "undefined", possibly as bad as a complete system freeze, because the software has acted outside its *guarantee* to the OS as to how it will behave. (I think my understanding of "hard real time" is correct: "program X guarantees operation Y will take at most Z time", moreover "if operation Y takes more than Z time then Undefined Bad Things Happen").
Just how low can your latency go?
I don't know enough about sound card architecture to answer.
Claude
On Fri, 8 Sep 2006, Claude Heiland-Allen wrote:
First step would be to split Pd into a "hard real time" DSP thread and a "non real time" Message Processing thread,
Hmmm, how far is devel_0_39 from having implemented this? I don't recall what's the state of this feature in devel_0_39.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 2006-09-08 at 00:58 -0400, Mathieu Bouchard wrote:
On Fri, 8 Sep 2006, Claude Heiland-Allen wrote:
First step would be to split Pd into a "hard real time" DSP thread and a "non real time" Message Processing thread,
well, IMO message processing should be done in the dsp thread to have a tight messaging/dsp interaction ... however longer-lasting or blocking operations should be moved to a separate thread
Hmmm, how far is devel_0_39 from having implemented this? I don't recall what's the state of this feature in devel_0_39.
i started to implement a separation of realtime and nonrealtime threads for devel_0_39, but mainly to be able to sync the dsp scheduler with the audio driver (mainly portaudio). there is no real separation of operations like object creation, gui interaction or buffer operations, though ... however, the synthesis engine, that i'm currently developing, takes this into account ...
concerning realtime kernels ... taking the current implementation of the audio backends of vanilla pd into account, running a -rt patched kernel would have a similar effect as upgrading a viennese fiaker with a formula 1 engine ...
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
On Fri, Sep 08, 2006 at 02:11:20PM EST, Charles Henry 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.
Have you looked into trying Ingo's real-time preempt patch? You can find it at http://people.redhat.com/~mingo/realtime-preempt/
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?
try CCRMA packages on top of your FC4 system, they come with 2 realtime kernels: 50% preepmption (rdt kernels) and 100% preemption (rtt ones). see http://ccrma.stanford.edu/planetccrma/software/node3.html
I think the interrupt priority of your soundcard should be high and it should not be shared with other devices, jackd should be executed with realtime priority ( -R flag). I'd really like to know how to set the irq priority.. but i don't.. i guess it has something to do with APIC/ACPI... If anyone knows how to set:
- the process priority
- the irq priority
could please tell how? i can't find anything on the web..
ciao, davide.
pci tuning is done using the lspci (for viewing pci bus ids, etc) and setpci commands. review the man pages of both of these, and have a look in google for "linux pci latency"
ibm has a good article on this: http://www-128.ibm.com/developerworks/linux/library/l-hw2.html
On Fri, 2006-09-08 at 09:41 +0200, Davide Morelli wrote:
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?
try CCRMA packages on top of your FC4 system, they come with 2 realtime kernels: 50% preepmption (rdt kernels) and 100% preemption (rtt ones). see http://ccrma.stanford.edu/planetccrma/software/node3.html
I think the interrupt priority of your soundcard should be high and it should not be shared with other devices, jackd should be executed with realtime priority ( -R flag). I'd really like to know how to set the irq priority.. but i don't.. i guess it has something to do with APIC/ACPI... If anyone knows how to set:
- the process priority
- the irq priority
could please tell how? i can't find anything on the web..
ciao, davide.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
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?
If you run a stock 2.4 kernel you will get really bad latency behaviour. You can fix this by using some realtime-patched 2.4 kernel but I would recommend to go a different route: Just install a recent 2.6 kernel, enable preemptible kernel etc. in the config and live happily with it.
Stock 2.6 kernels now have excellent latency behaviour in the range of 1-3 msec. The so called "hard realtime" latency that can be achieved with Ingo Molnar's rt-patches will give latencies even below that, but do you really need them? In my opninion most Pd users don't need them and the time spend figuring out a good combination of rt-patch version and kernel version is better spent optimizing your Pd patches.
Use Linux from Scratch if you are bored and have too much time on your hands. It will not give you relevantly better performance and IMO is not worth the effort. If you like to watch the output of make and gcc, Gentoo will satisfy you as well, but if you rather spend your time using, than compiling software, something like Fedora, Ubuntu or Debian (my fav.) is a better choice.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 2006-09-08 at 11:11 +0200, Frank Barknecht wrote:
Stock 2.6 kernels now have excellent latency behaviour in the range of 1-3 msec.
what do this values correspond to? when i set the latency of jackd to 2.9ms, i get a round trip in pd of about 7.4ms. so when the term 'latency' with no further specificataions is used, the full round trip (analog signal -> adc~ > dac~ -> analog singal) is meant or the value set in pd or jackd? i just wonder if one could expect a round trip with the mentioned values (1-3 msec) with a well made setup.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
The filters on hardware A/D and D/A filters typically each add about 3 msec latency at 44K1 - so if the software is doing 2 Msec, you can easily end up seeing 8. Theoretically, it should be possible to cut the filter latencies in half by going to 48K, or to .3 msec apiece if you run at 96K. (It's inversely proportional to the Nyquist minus 20 KHz.)
cheers Miller
On Fri, Sep 08, 2006 at 06:46:33PM +0200, Roman Haefeli wrote:
On Fri, 2006-09-08 at 11:11 +0200, Frank Barknecht wrote:
Stock 2.6 kernels now have excellent latency behaviour in the range of 1-3 msec.
what do this values correspond to? when i set the latency of jackd to 2.9ms, i get a round trip in pd of about 7.4ms. so when the term 'latency' with no further specificataions is used, the full round trip (analog signal -> adc~ > dac~ -> analog singal) is meant or the value set in pd or jackd? i just wonder if one could expect a round trip with the mentioned values (1-3 msec) with a well made setup.
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Fri, 2006-09-08 at 11:11 +0200, Frank Barknecht wrote:
Stock 2.6 kernels now have excellent latency behaviour in the range of 1-3 msec.
what do this values correspond to?
Actually I'm not talking about soundcard latency at all here, but about "worst case scheduling latency" in the kernel, that is, the guaranteed maximum time the kernel will let a realtime task be interrupted.
I got my numbers from the talk and paper, Lee Revell presented at LAC2006: http://lac.zkm.de/2006/proceedings.shtml#lee_revell
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello all,
As has been mentioned, installing planet CCRMA is probably the easiest way to get out-of-the-box good latency. I've been using Ubuntu linux recently though, since I like how easy they're making it to install/update/configure (finally!). ubuntustudio.com is a resource that I've found for setting up Ubuntu linux for audio work. http://ubuntustudio.com/wiki/index.php/Welcome%2C_Musicians%21
On the front page they mention Mubuntu, an alleged multimedia derivitave of Ubuntu, that is still in the works. https://wiki.ubuntu.com/Mubuntu
I've been using Ubuntu for PD with pretty good latency results - by applying the realtime/preemptive patch I got my [adc~] -> [dac~] latency down to about 8msec. This was for the "Breezy" distro of Ubuntu, and the explanation of how to do it is here: http://ubuntustudio.com/wiki/index.php/Breezy:Vanilla_Kernel_With_Realtime_P...
Now that I've updated to the lateset Ubuntu (Dapper), the how-to no longer applies, but I think I'm still getting decent latency, running pd with the -rt flag. -David M.
Frank Barknecht wrote:
Hallo, Charles Henry hat gesagt: // Charles Henry wrote:
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?
If you run a stock 2.4 kernel you will get really bad latency behaviour. You can fix this by using some realtime-patched 2.4 kernel but I would recommend to go a different route: Just install a recent 2.6 kernel, enable preemptible kernel etc. in the config and live happily with it.
Stock 2.6 kernels now have excellent latency behaviour in the range of 1-3 msec. The so called "hard realtime" latency that can be achieved with Ingo Molnar's rt-patches will give latencies even below that, but do you really need them? In my opninion most Pd users don't need them and the time spend figuring out a good combination of rt-patch version and kernel version is better spent optimizing your Pd patches.
Use Linux from Scratch if you are bored and have too much time on your hands. It will not give you relevantly better performance and IMO is not worth the effort. If you like to watch the output of make and gcc, Gentoo will satisfy you as well, but if you rather spend your time using, than compiling software, something like Fedora, Ubuntu or Debian (my fav.) is a better choice.
Ciao
Thanks for the great suggestions, everyone, and resources. There's a lot of things I need to check out, now. irq/pci settings (lspci & cat /proc/interrupts), the 2.6 kernels, Ingo Molnar's patch, disable hyper-threading if possible,... I think I'll have to take a closer look at source code to understand Claude's multi-threaded idea.
Use Linux from Scratch if you are bored and have too much time on your hands.
Thanks for that Frank...I just might be bored enough. I maybe have learned enough to try to design a system. I haven't abandoned the idea just yet. I think I'll try the other ideas listed first, before trying LFS after all....
Thanks for everyone's suggestions, Chuck
-
Charles Henry -
Chuckk Hubbard -
Claude Heiland-Allen -
David Merrill -
Davide Morelli -
Frank Barknecht -
Luke Yelavich -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli -
shift8 -
Tim Blechmann