[PD] Key-related audio glitch, OS X Intel

[Phil Stone]

Hi Hans,

Thanks for checking.  You pointed out an important thing I forgot to 
factor out: my audio interface.  I was playing through the M-Audio Ozone 
when the glitch occurred.  I think I had subconsciously ruled out the 
Ozone because it performs so flawlessly on the Windows side of this 
MacBook.  However, it does indeed seem to be M-Audio's relatively new 
driver for Intel OS X that causes the trouble.

Using Macintel OS X's "built in" sound (PortAudio, i.e.), there is no 
glitch.  Using Windows and Ozone, there is no glitch.  Using MacIntel 
Ozone, the glitch is easy to reproduce.

PD seems to be in the clear, though, so sorry for the false alarm.  Time 
to file a bug report over at M-Audio.


Phil



Hans-Christoph Steiner wrote:
>
> On Jul 9, 2006, at 6:14 PM, Phil Stone wrote:
>
>> More information on this:
>>
>>> I've been playing with Miller's experimental version for Intel OS X 
>>> (see http://crca.ucsd.edu/~msp/Software/pd-imac-test.mac.tar.gz )
>>> and for the most part, it works great.
>>>
>>
>> [...]
>>
>>> Typing on the computer keyboard (e.g. to enter something in a number 
>>> box) after focus has just transferred to PD, makes a crunch or pop 
>>> in the sound right at the moment of the first key press.  Subsequent 
>>> key presses do not interfere with the sound, until focus is switched 
>>> to another app (or maybe even another PD window -- I can't reproduce 
>>> this very consistently) and then is returned to PD.
>>
>> More exacting testing shows that the glitch can be consistently 
>> reproduced using the simplest audio patch,  [osc~ 400] - [dac~]
>> or even the Media Menu -> Test audio app.
>>
>> Window focus has nothing to do with it:  it is related to time.  If a 
>> key on the computer keyboard hasn't been pressed for n seconds (n 
>> equals about 10 on my system), the next key press causes a 
>> significant audio glitch.  Further key presses, if made within n 
>> seconds, don't cause a glitch.  *After any pause of n seconds or 
>> more, the next key press causes the glitch.*  Also, there need not be 
>> any key-input controls on the PD screen; as I said, the simplest 
>> audio patch can reproduce this.
>>
>>> I've tried different latency settings and this has had no effect.
>>>
>>
>> The -rt startup flag makes no difference.  Completely disabling 
>> Dashboard, and effectively disabling Spotlight, makes no difference.
>>
>>> This seems like some bad interaction between the OS key-handling and 
>>> PD.
>>>
>> I would really appreciate it if:
>>  a) someone on PPC OS X could see whether this happens to them.
>>  b) someone else running the experimental Intel version of PD 
>> (anyone?) could try to replicate this.
>>
>> Also, I'd appreciate some noob-advice on whether I should I file a 
>> bug report on this.
>
>  I tried this using Pd-0.39.2-extended-test4 on a G5 using the "Test 
> Audio and MIDI" patch.  I could not make it click with realtime mode 
> on or off with the standard delay of 50ms.  I switched it down to 13ms 
> with realtime turned off and got some clicks when switching focus.  
> With realtime on, I got no clicks at 13ms.  It sounds to me that you 
> need to bump up the delay a bit perhaps.  I forgot to mention, I am 
> using portaudio, not jack.
>
> .hc
>