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
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.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.
PS: if you use the sf-tracker for this, please create a bugreport instead of adding to the "patches"
regards,
Rich