[PD-dev] [PD] wierd feedback popping with pd/freebob/jack/rt

[Rich E]

IOhannes,

First off, sorry for getting your name wrong in the last post :)

I just got a 64 Studio setup going with the latest pd-extended and
jack/freebob - no wierd pops, it actually sounds great at about 5ms
latency.  So, Ubuntu looses I guess. There are other problems I was
experiencing in Ubuntu (my touchpad would flip out on occasion, clicking on
about 20 random things a second), so I guess the bug I found is going to
have to stay an Ubuntu problem and not a pd dev problem.

Now, on to fiddle around in my new OS...

cheers,
Rich

On Mon, Jun 9, 2008 at 10:49 PM, Rich E <reakinator at 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 at iem.at> wrote:
>
>> Quoting Rich E <reakinator at 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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080621/69ab28c1/attachment.htm>