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