Hi,
I have been having this problem off and on for a while, but never thought it would do any good to post on this forum about it. However, I have a lead now.
I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the rt kernel. If pd is running by itself, everything sounds great. If jack is running in non-realtime and there are lots of things going on, everything sounds great except there are big pauses in midi/audio throughput. If jack is running in realtime everything BUT pd sounds great, while pd produces feint pops, with feedback.
And what I just noticed today, if I start another JACK application afterwards, the pops go away and everything is runnnig smooth in realtime. I don't know if it is just any application, but what I am explaining happened when I opened audacity to try to record the output of pd's wierdness.
I've only had this issue with pd. Does this make sense to anyone?
-rich
Which version of Pd is this? There are large differences, so you
need to be specific.
.hc
On May 20, 2008, at 2:15 PM, Rich E wrote:
Hi,
I have been having this problem off and on for a while, but never
thought it would do any good to post on this forum about it.
However, I have a lead now.I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the
rt kernel. If pd is running by itself, everything sounds great.
If jack is running in non-realtime and there are lots of things
going on, everything sounds great except there are big pauses in
midi/audio throughput. If jack is running in realtime everything
BUT pd sounds great, while pd produces feint pops, with feedback.And what I just noticed today, if I start another JACK application
afterwards, the pops go away and everything is runnnig smooth in
realtime. I don't know if it is just any application, but what I
am explaining happened when I opened audacity to try to record the
output of pd's wierdness.I've only had this issue with pd. Does this make sense to anyone?
-rich _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
Currently, Pd-0.40.3-extended from the autobuiilds. While I think this is occurring on every version on Pd I have tried since I installed Hardy (which is alot), I should do some testing to verify that.
Another thing; opening Audacity only cures things for a bit, until I do something like open another patch in pd. Then, the glitch happens again, I restart audacity, and it goes away.
I'll try some testing on 0.39 - .41 vanilla when I have a moment.
rich
On Tue, May 20, 2008 at 7:59 AM, Hans-Christoph Steiner hans@eds.org wrote:
Which version of Pd is this? There are large differences, so you need to be specific.
.hc
On May 20, 2008, at 2:15 PM, Rich E wrote:
Hi,
I have been having this problem off and on for a while, but never thought it would do any good to post on this forum about it. However, I have a lead now.
I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the rt kernel. If pd is running by itself, everything sounds great. If jack is running in non-realtime and there are lots of things going on, everything sounds great except there are big pauses in midi/audio throughput. If jack is running in realtime everything BUT pd sounds great, while pd produces feint pops, with feedback.
And what I just noticed today, if I start another JACK application afterwards, the pops go away and everything is runnnig smooth in realtime. I don't know if it is just any application, but what I am explaining happened when I opened audacity to try to record the output of pd's wierdness.
I've only had this issue with pd. Does this make sense to anyone?
-rich _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
The date matters for the auto-builds. There were jack-related
patches checked in on certain dates.
.hc
On May 20, 2008, at 5:38 PM, Rich E wrote:
Currently, Pd-0.40.3-extended from the autobuiilds. While I think
this is occurring on every version on Pd I have tried since I
installed Hardy (which is alot), I should do some testing to verify
that.Another thing; opening Audacity only cures things for a bit, until
I do something like open another patch in pd. Then, the glitch
happens again, I restart audacity, and it goes away.I'll try some testing on 0.39 - .41 vanilla when I have a moment.
rich
On Tue, May 20, 2008 at 7:59 AM, Hans-Christoph Steiner
hans@eds.org wrote:Which version of Pd is this? There are large differences, so you
need to be specific..hc
On May 20, 2008, at 2:15 PM, Rich E wrote:
Hi,
I have been having this problem off and on for a while, but never
thought it would do any good to post on this forum about it.
However, I have a lead now.I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the
rt kernel. If pd is running by itself, everything sounds great.
If jack is running in non-realtime and there are lots of things
going on, everything sounds great except there are big pauses in
midi/audio throughput. If jack is running in realtime everything
BUT pd sounds great, while pd produces feint pops, with feedback.And what I just noticed today, if I start another JACK application
afterwards, the pops go away and everything is runnnig smooth in
realtime. I don't know if it is just any application, but what I
am explaining happened when I opened audacity to try to record the
output of pd's wierdness.I've only had this issue with pd. Does this make sense to anyone?
-rich _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
kill your television
Hans, the patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=1942258&gro...
I tried the may 15th pd-extended and I don't have the problem, but I do with the may 16th one. Also, I just manually patched pd-0.40.3 with the diff file on that page and I again have bad audio. I use pd-0.40.3 without the patch, I get very nice audio.
There is another problem that I have been having for about 1/2 a year now, which I think is completely separate. It has to do with running multiple realtime audio apps.. pd tends to start skipping in these situations until I use the chrt command on it.. but I guess I'll leave that until I can better isolate the problem.
regards, Rich
On Tue, May 20, 2008 at 12:46 PM, Hans-Christoph Steiner hans@eds.org wrote:
The date matters for the auto-builds. There were jack-related patches checked in on certain dates.
.hc
On May 20, 2008, at 5:38 PM, Rich E wrote:
Currently, Pd-0.40.3-extended from the autobuiilds. While I think this is occurring on every version on Pd I have tried since I installed Hardy (which is alot), I should do some testing to verify that.
Another thing; opening Audacity only cures things for a bit, until I do something like open another patch in pd. Then, the glitch happens again, I restart audacity, and it goes away.
I'll try some testing on 0.39 - .41 vanilla when I have a moment.
rich
On Tue, May 20, 2008 at 7:59 AM, Hans-Christoph Steiner hans@eds.org wrote:
Which version of Pd is this? There are large differences, so you need to be specific.
.hc
On May 20, 2008, at 2:15 PM, Rich E wrote:
Hi,
I have been having this problem off and on for a while, but never thought it would do any good to post on this forum about it. However, I have a lead now.
I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the rt kernel. If pd is running by itself, everything sounds great. If jack is running in non-realtime and there are lots of things going on, everything sounds great except there are big pauses in midi/audio throughput. If jack is running in realtime everything BUT pd sounds great, while pd produces feint pops, with feedback.
And what I just noticed today, if I start another JACK application afterwards, the pops go away and everything is runnnig smooth in realtime. I don't know if it is just any application, but what I am explaining happened when I opened audacity to try to record the output of pd's wierdness.
I've only had this issue with pd. Does this make sense to anyone?
-rich _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
kill your television
Rich E wrote:
Hans, the patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=1942258&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1942258&group_id=55736&atid=478072
I tried the may 15th pd-extended and I don't have the problem, but I do with the may 16th one. Also, I just manually patched pd-0.40.3 with the diff file on that page and I again have bad audio. I use pd-0.40.3 without the patch, I get very nice audio.
interesting.
btw, does it make a difference if jack is running before you start, and pd is starting jack.
the latter is only possible with the patch applied, and i guess it is the main source of trouble.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
Rich E wrote:
Hans, the patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=1942258&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1942258&group_id=55736&atid=478072
I tried the may 15th pd-extended and I don't have the problem, but I do with the may 16th one. Also, I just manually patched pd-0.40.3 with the diff file on that page and I again have bad audio. I use pd-0.40.3 without the patch, I get very nice audio.
interesting.
btw, does it make a difference if jack is running before you start, and pd is starting jack.
the latter is only possible with the patch applied, and i guess it is the main source of trouble.
anyhow, as i don't have any machine to reproduce your problem i have checked in some changes to the pd-extended 0.40 branch that might fix the issue. the main difference now is that Pd does not try to automatically start a jackd by itself, so you have to do this manually (which is compatible to the usage instructions before my original patch)
tell us whether it helped. and if not, also please give a complete step-by-step description on how to reproduce it (preferrably without the need of special hardware)
mfasdr IOhannes
PS: if you use the sf-tracker for this, please create a bugreport instead of adding to the "patches"
IOhannes, thanks for the commit..
The problem wasn't automatically starting jack. After swapping out lines of code from the vanilla version, I discovered the source of bad audio is coming from "#define NUM_JACK_PORTS 1024" . This seems to be making pd fall behind for reasons unknown to me, but if I set it to 256 or below, the audio is fine again (I don't know the exact number that is 'over the limit', when I switched to 512, I got the pops/clicks).
One more thing; this only happens with my firewire soundcard (edirol FA-101), whereas I don't have the problem with the built-in intel soundcard. So it seems maybe the freebob driver is trying to open all the extra ports it doesn't need, thereby making audio fall behind? I don't know if this makes sense, because again, if I open audacity while pd's audio is on and popping/clicking, the audio chain is corrected and everything sounds fine. This was my first time looking at jack code and really don't understand how it all ties together yet.
PS: if you use the sf-tracker for this, please create a bugreport instead of adding to the "patches"
Sounds good. Should I file a bug report for the above mentioned #define? I would submit a patch, but I don't think just setting the #define to a number that works on my computer is good for everyone else.
regards, Rich
After more testing...
With pd compiled with "JACK_NUM_PORTS 256", audio runs fine at first, but if the cpu gets a big hit, like when I open a soundfont in [fluid~], the audio falls behind and I get the pops/clicks again. If I compile pd with "JACK_NUM_PORTS 32", this doesn't appear to happen; [fluid~] does its thing, the gui freezes for a couple seconds, but the audio is fine afterwards.
Hopefully this hints at what the problem really is.
regards, Rich
On Wed, May 28, 2008 at 12:37 PM, Rich E reakinator@gmail.com wrote:
IOhannes, thanks for the commit..
The problem wasn't automatically starting jack. After swapping out lines of code from the vanilla version, I discovered the source of bad audio is coming from "#define NUM_JACK_PORTS 1024" . This seems to be making pd fall behind for reasons unknown to me, but if I set it to 256 or below, the audio is fine again (I don't know the exact number that is 'over the limit', when I switched to 512, I got the pops/clicks).
One more thing; this only happens with my firewire soundcard (edirol FA-101), whereas I don't have the problem with the built-in intel soundcard. So it seems maybe the freebob driver is trying to open all the extra ports it doesn't need, thereby making audio fall behind? I don't know if this makes sense, because again, if I open audacity while pd's audio is on and popping/clicking, the audio chain is corrected and everything sounds fine. This was my first time looking at jack code and really don't understand how it all ties together yet.
PS: if you use the sf-tracker for this, please create a bugreport instead of adding to the "patches"
Sounds good. Should I file a bug report for the above mentioned #define? I would submit a patch, but I don't think just setting the #define to a number that works on my computer is good for everyone else.
regards, Rich
Quoting Rich E reakinator@gmail.com:
After more testing...
With pd compiled with "JACK_NUM_PORTS 256", audio runs fine at first, but if the cpu gets a big hit, like when I open a soundfont in [fluid~], the audio falls behind and I get the pops/clicks again. If I compile pd with "JACK_NUM_PORTS 32", this doesn't appear to happen; [fluid~] does its thing, the gui freezes for a couple seconds, but the audio is fine afterwards.
Hopefully this hints at what the problem really is.
no, unfortunately this does not make sense at all.
NUM_JACK_PORTS is only used for sizing arrays properly and setting the
maximum possible numbers of channels Pd can use. as the default number
of channels is still 2, jack should actually not notice anything about
this parameter.
nevertheless, i will re-think....
(but i really need at least 64 channels, most likely more; this was
the main motivation to start writing the entire patch...)
fgmads IOhannes
This message was sent using IMP, the Internet Messaging Program.
i got the same problems since i update to hardy with pd and jack (freebob) using my fa-66, and in general, with all the sound ... noise when the pointer of the mouse moves a window, unstability of jack and so on,i just use another distro for audio stuff
2008/5/20 Rich E reakinator@gmail.com:
Currently, Pd-0.40.3-extended from the autobuiilds. While I think this is occurring on every version on Pd I have tried since I installed Hardy (which is alot), I should do some testing to verify that.
Another thing; opening Audacity only cures things for a bit, until I do something like open another patch in pd. Then, the glitch happens again, I restart audacity, and it goes away.
I'll try some testing on 0.39 - .41 vanilla when I have a moment.
rich
On Tue, May 20, 2008 at 7:59 AM, Hans-Christoph Steiner hans@eds.org wrote:
Which version of Pd is this? There are large differences, so you need to be specific.
.hc
On May 20, 2008, at 2:15 PM, Rich E wrote:
Hi,
I have been having this problem off and on for a while, but never thought it would do any good to post on this forum about it. However, I have a lead now.
I have an Edirol FA-101 hooked up to pd in Ubuntu Gutsy, with the rt kernel. If pd is running by itself, everything sounds great. If jack is running in non-realtime and there are lots of things going on, everything sounds great except there are big pauses in midi/audio throughput. If jack is running in realtime everything BUT pd sounds great, while pd produces feint pops, with feedback.
And what I just noticed today, if I start another JACK application afterwards, the pops go away and everything is runnnig smooth in realtime. I don't know if it is just any application, but what I am explaining happened when I opened audacity to try to record the output of pd's wierdness.
I've only had this issue with pd. Does this make sense to anyone?
-rich _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2008/5/20 Rich E reakinator@gmail.com:
Currently, Pd-0.40.3-extended from the autobuiilds. While I think this is occurring on every version on Pd I have tried since I installed Hardy (which is alot), I should do some testing to verify that.
Another thing; opening Audacity only cures things for a bit, until I do something like open another patch in pd. Then, the glitch happens again, I restart audacity, and it goes away.
I'll try some testing on 0.39 - .41 vanilla when I have a moment.
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
The "pops/clicks" phenomenon you are noticing that gets resolved by starting or killing another JACK app, is something I've experienced before. It happens when some app gets an Xrun or otherwise can't process audio in time. From that point forward it "clicks" and, in my experience, distorts as well with some bitcrushing-style aliasing distortion. When you start or stop any JACK app, the entire JACK graph structure gets re-ordered (this isn't true with jackdmp, just with single-processor JACK), and that causes the misbehaving app to "start from scratch" somewhat and get its audio organized properly.
I'd suggest 64Studio, Musix, Pure::Dyne, or some other distro that has the really serious RT set up with the Ingo patches. With one of those distros, everything should run very well on a machine of any decent heft.
-ken
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
Where are you getting this info from? This is not what I have read, but maybe I am missing something somewhere. I thought that the Ubuntu kernel packagers recently switched to using full realtime preemption... I find this in the package description of linux-image-2.6.22-14-rt : Ingo Molnar's full real time preemption patch (2.6.22.1-rt9)
Here is the output of uname -a: Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008 i686 GNU/Linux
.. and here are the kernel settings from cat /boot/config-2.6.22-14-rt | grep PREEMPT # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set
Looks realtime to me.. also the latency is really low (5-10ms conservatively), much lower than I have experienced on other OS's, with or without realtime. But, if you know something I don't... I have open ears. Ubuntu runs so nicely on a laptop though... would hate to switch after finding such an easy-to-operate linux distribution because pd and only pd doesn't like jack in realtime.
regards, rich
The "pops/clicks" phenomenon you are noticing that gets resolved by starting or killing another JACK app, is something I've experienced before. It happens when some app gets an Xrun or otherwise can't process audio in time. From that point forward it "clicks" and, in my experience, distorts as well with some bitcrushing-style aliasing distortion. When you start or stop any JACK app, the entire JACK graph structure gets re-ordered (this isn't true with jackdmp, just with single-processor JACK), and that causes the misbehaving app to "start from scratch" somewhat and get its audio organized properly.
I'd suggest 64Studio, Musix, Pure::Dyne, or some other distro that has the really serious RT set up with the Ingo patches. With one of those distros, everything should run very well on a machine of any decent heft.
-ken
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
Where are you getting this info from? This is not what I have read, but maybe I am missing something somewhere. I thought that the Ubuntu kernel packagers recently switched to using full realtime preemption... I find this in the package description of linux-image-2.6.22-14-rt : Ingo Molnar's full real time preemption patch (2.6.22.1-rt9)
Here is the output of uname -a: Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008 i686 GNU/Linux
.. and here are the kernel settings from cat /boot/config-2.6.22-14-rt | grep PREEMPT # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set
Looks realtime to me.. also the latency is really low (5-10ms conservatively), much lower than I have experienced on other OS's, with or without realtime. But, if you know something I don't... I have open ears. Ubuntu runs so nicely on a laptop though... would hate to switch after finding such an easy-to-operate linux distribution because pd and only pd doesn't like jack in realtime.
regards, rich
The "pops/clicks" phenomenon you are noticing that gets resolved by starting or killing another JACK app, is something I've experienced before. It happens when some app gets an Xrun or otherwise can't process audio in time. From that point forward it "clicks" and, in my experience, distorts as well with some bitcrushing-style aliasing distortion. When you start or stop any JACK app, the entire JACK graph structure gets re-ordered (this isn't true with jackdmp, just with single-processor JACK), and that causes the misbehaving app to "start from scratch" somewhat and get its audio organized properly.
I'd suggest 64Studio, Musix, Pure::Dyne, or some other distro that has the really serious RT set up with the Ingo patches. With one of those distros, everything should run very well on a machine of any decent heft.
-ken
On Wed, May 21, 2008 at 02:23:20PM -0700, Rich E wrote:
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
Where are you getting this info from? This is not what I have read, but maybe I am missing something somewhere. I thought that the Ubuntu kernel packagers recently switched to using full realtime preemption... I find this
My info is from having installed Ubuntu and used it... but that was a few years ago. Glad they're using Ingo's patches now.
in the package description of linux-image-2.6.22-14-rt : Ingo Molnar's full real time preemption patch (2.6.22.1-rt9)
Here is the output of uname -a: Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008 i686 GNU/Linux
.. and here are the kernel settings from cat /boot/config-2.6.22-14-rt | grep PREEMPT # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set
Looks realtime to me.. also the latency is really low (5-10ms conservatively), much lower than I have experienced on other OS's, with or without realtime. But, if you know something I don't... I have open ears.
Nope, you got real-time there, for sure. I was wrong then.
Ubuntu runs so nicely on a laptop though... would hate to switch after finding such an easy-to-operate linux distribution because pd and only pd doesn't like jack in realtime.
Dunno. You're playing Xrun whack-a-mole. Done that; it's not fun.
Here's what I did to RT-ify my system (on Debian, but Ubuntu is based on it): http://www.restivo.org/blog/archives/preparing-a-debian-etch-system-for-audi...
Also, I expect you know to use chrt to give the IRQ of your audio interface top priority, higher than JACK and any other process. That's a crucial step. If I omit that, then I get clicks and pops too, which is why I wrote a script to do it automatically. You could also install and configure the "rtirq" package, which works great too.
-ken
On Wed, May 21, 2008 at 3:20 PM, Ken Restivo ken@restivo.org wrote:
On Wed, May 21, 2008 at 02:23:20PM -0700, Rich E wrote:
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
Where are you getting this info from? This is not what I have read, but maybe I am missing something somewhere. I thought that the Ubuntu kernel packagers recently switched to using full realtime preemption... I find
this
My info is from having installed Ubuntu and used it... but that was a few years ago. Glad they're using Ingo's patches now.
in the package description of linux-image-2.6.22-14-rt : Ingo Molnar's full real time preemption patch (2.6.22.1-rt9)
Here is the output of uname -a: Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008
i686
GNU/Linux
.. and here are the kernel settings from cat /boot/config-2.6.22-14-rt | grep PREEMPT # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set
Looks realtime to me.. also the latency is really low (5-10ms conservatively), much lower than I have experienced on other OS's, with
or
without realtime. But, if you know something I don't... I have open
ears.
Nope, you got real-time there, for sure. I was wrong then.
Ubuntu runs so nicely on a laptop though... would hate to switch after finding such an easy-to-operate linux distribution because pd and only pd doesn't like jack in realtime.
Dunno. You're playing Xrun whack-a-mole. Done that; it's not fun.
Ken, this made me laugh for quite a while. Thank you.
Here's what I did to RT-ify my system (on Debian, but Ubuntu is based on it):
http://www.restivo.org/blog/archives/preparing-a-debian-etch-system-for-audi...
Also, I expect you know to use chrt to give the IRQ of your audio interface top priority, higher than JACK and any other process. That's a crucial step. If I omit that, then I get clicks and pops too, which is why I wrote a script to do it automatically. You could also install and configure the "rtirq" package, which works great too.
I had it on my last setup, but for got to do it this time. Thanks for reminding me :) Also, as my other post mentions, I sometimes got clicks with pd even with the script. I actually had to change the irq priority of pd to get rid of them, which is bad since it changes all the threads pd has instead of only the scheduler. I would get "I/O stuck... closing audio" all the time.
-ken
I made a comment on the patch tracker concerning this, directly on the jack patch. However, looking at the patch, I cannot see how it would effect pd's audio when running in real-time. All I know is I ran pd-0.40.3-extended from April 15th yesterday, using jack in real-time, for a few hours and the audio was almost flawless.
On Wed, May 21, 2008 at 3:34 PM, Rich E reakinator@gmail.com wrote:
On Wed, May 21, 2008 at 3:20 PM, Ken Restivo ken@restivo.org wrote:
On Wed, May 21, 2008 at 02:23:20PM -0700, Rich E wrote:
IIRC, Ubuntu "RT" kernel is not actually Real Time (i.e. with Ingo patches), just a "desktop RT" which is not very useful for audio and certainly not enough for JACK apps of any heft.
Where are you getting this info from? This is not what I have read, but maybe I am missing something somewhere. I thought that the Ubuntu
kernel
packagers recently switched to using full realtime preemption... I find
this
My info is from having installed Ubuntu and used it... but that was a few years ago. Glad they're using Ingo's patches now.
in the package description of linux-image-2.6.22-14-rt : Ingo Molnar's full real time preemption patch (2.6.22.1-rt9)
Here is the output of uname -a: Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008
i686
GNU/Linux
.. and here are the kernel settings from cat /boot/config-2.6.22-14-rt
|
grep PREEMPT # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set
Looks realtime to me.. also the latency is really low (5-10ms conservatively), much lower than I have experienced on other OS's, with
or
without realtime. But, if you know something I don't... I have open
ears.
Nope, you got real-time there, for sure. I was wrong then.
Ubuntu runs so nicely on a laptop though... would hate to switch after finding such an easy-to-operate linux distribution because pd and only
pd
doesn't like jack in realtime.
Dunno. You're playing Xrun whack-a-mole. Done that; it's not fun.
Ken, this made me laugh for quite a while. Thank you.
Here's what I did to RT-ify my system (on Debian, but Ubuntu is based on it):
http://www.restivo.org/blog/archives/preparing-a-debian-etch-system-for-audi...
Also, I expect you know to use chrt to give the IRQ of your audio interface top priority, higher than JACK and any other process. That's a crucial step. If I omit that, then I get clicks and pops too, which is why I wrote a script to do it automatically. You could also install and configure the "rtirq" package, which works great too.
I had it on my last setup, but for got to do it this time. Thanks for reminding me :) Also, as my other post mentions, I sometimes got clicks with pd even with the script. I actually had to change the irq priority of pd to get rid of them, which is bad since it changes all the threads pd has instead of only the scheduler. I would get "I/O stuck... closing audio" all the time.
-ken
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Ken Restivo -
Mario Mora -
Rich E -
zmoelnig＠iem.at