On Mon, Jun 9, 2008 at 10:49 PM, Rich E <reakinator@gmail.com> wrote:

Hi IOhanens,

I moved this thread from the pd-list, since it is now only discussing pd's audio jack in c.

Did you ever find time to look at s_audio_jack.c again? I suspect it is a freebob -only problem, but I have only experienced it in pd. Somehow the buffer alignment is getting knocked off track - making JACK_NUM_PORTS smaller only seems to help this, but problems still arise when a big cpu hit occurs.

It is also curious that audacity can effectively reset the audio buffers coming from pd (or summed from both most likely) when it starts, but this cannot be done from pd. With JACK_NUM_PORTS > 512, pd even starts with audio residue.

Maybe I should file a bug or move this question to the jack list..

regards,
Rich

On Wed, May 28, 2008 at 11:37 PM, <zmoelnig@iem.at> wrote:

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.