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.
Phil Stone pkstone, ucdavis
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
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
-
Hans-Christoph Steiner -
Phil Stone