Hi Brad and all!
I had heard it was the latest Airport Extreme update (2008-001, I think). You might try turning off your Airport to see if it helps.
Whoa, it appears to make a huge difference! As far as I can tell, that's the problem! Thanks Brad!!!!
I also heard that someone just re-installed the last Airport update:
Hmm, this appears to require first installing a third-party application. Less than spectacular - way to go, Apple. Going to figure out a workaround, while hoping for OS X to update the update to unbreak things. Thanks to all for all the suggestions! Best, Ge!
On Apr 14, 2008, at 3:42 AM, Ge Wang wrote:
Greetings again!
Following up... after additional testing on the inconsistent real-time behavior, we have found:
* buffer size has no apparent effect * system scheduling priority (--level) has no apparent effect * number of buffers has no apparent effect * BLOCKING nearly fixes the problem, but this is undesirable because it is a bit more inefficient and also less amenable to really small buffer sizes, compared to CALLBACK.
To help make sure I am not going insane (faster than expected), I also tried running PD (both 40-2 and 41-4). In both cases, similar audio hickups were occurring even when playing a single sine wave on my newly upgraded system. At least on my setup, something is fairly wrong. Not sure if it's the new software/firmware updates, or me doing something ill-advised (fairly standard M.O.), or something else altogether.
Any thoughts would be greatly appreciated!
Best, Ge!
On Sun, 13 Apr 2008, Ge Wang wrote:
Greetings,
We are experiencing some rather unfriendly real-time behavior on OS X, seemingly after doing the latest apple upgrades... here are some details, at least on my machine:
* system: Macbook Pro / OS X (10.4.11) * updates: Quicktime 7.4.5 + MPB EFI Firmware Update 1.5 * symptoms: real-time audio "goes to poop", even under moderate loads. * workaround: running command line chuck in BLOCKING mode (via --blocking) seems to work, however the default CALLBACK mode seems completely hosed, even with bigger buffer sizes. This is especially problematic for the miniAudicle, which doesn't have the option currently to choose between blocking vs. callback.
Has anyone else noticed similar behavior, either on Tiger or Leopard? Or is this an isolated case for my system? We'd appreciate any input!
Thanks!!
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users