[PD] PD audio and Gem quest.

[chris clepper]

On Feb 29, 2004, at 9:59 AM, timon botez wrote:

> Hi,
> Im a OSX.3 user and I just recently started adding pd sound with my 
> Gem patches. I remember having read about audio glitches occurring, 
> but I had no idea it was that bad. Can anyone provide a good 
> explanation to why this is? Are there certain operations that can 
> improve this problem and Is there a future plan to make the two work 
> better together? Being a the powerful MULTI media tool it is, this 
> would make sense (sorry, I dont mean to rant).

The answer is quite simple: Pd is not designed to do what you want to 
do.

Now, specifically to your problem the key issue is time.  Audio 
requires buffer transfer between the software and hardware a specific 
and regular interval.  This is on the order of sample rate / buffer 
size in samples, meaning a 48hkz sample rate with a 64 sample buffer or 
roughly every 1.33 ms a buffer has to be handed from Pd to the output 
hardware.  If that fails a dropout occurs.  GEM runs a user selectable 
rate for it's processing and for this example that will be 30 fps or 
33ms per frame.  On OSX, with a recent Mac, it takes about 10ms or less 
to grab a DV frame off disk, decompress it and put it on the screen, 
which is not bad but that's 10ms of time that Pd spent doing video and 
not doing audio.  This causes a few of those audio buffer transfers to 
not happen in their given time allotment.  You like that 30 cycle 
machine gun dropout effect right?  No. Not many do.

Some possible solutions to try in this case are:  Try increasing the 
I/O audio buffer size which will put more time between each buffer 
handoff from Pd to the hardware.  That's not a good solution really 
because this will give longer latency and since Pd on OSX already has a 
larger than average buffer size as a default the delay will be 
noticeable.  Also, this won't in any way guarantee the audio not 
dropping out.  Solution two involves running two copies of Pd, one with 
audio and one with video.  On a dual CPU machine this will allow the 
OSX kernel scheduler to do what Pd can't do itself - give time to each 
process independently of each other.  Of course if you try to do things 
that exceed the computational limits of one of the CPUs then nothing 
apart from getting faster software or hardware will help.  On a single 
CPU machine this might also work if you set the audio Pd process to 
-rt.  The -rt flag should enable a pthread scheduling hack that tells 
the OSX kernel 'hey this process is more important than the others!' 
and the kernel should give CPU time to that Pd process more often than 
other running apps.  This is not an ideal solution either because that 
little hack will adversely affect other application's performance 
including your video Pd process, and basically it exists to attempt to 
circumvent design decisions in Pd.  DO NOT use the -rt pthread hack 
with GEM on OSX!!!  You will discover all to quickly why this is not a 
solution to the problem as a CPU intensive patch will lock the OSX GUI 
(which is an OpenGL app)!  You can try writing your patches with 
netsend/receive or OSC and run a third GUI Pd process for control of 
the other two.  It's a pain and, no, it shouldn't really be this way.

cgc

> Timon.
>