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