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.