OSX updates =< real-time audio?
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!
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
i'm still on tiger ppc, so i can't speak from experience. but i heard _bad_ things about the latest airport update. just a shot in the dark. volker. On 14 Apr 2008, at 09:42, 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
Some guesses; Considering that PD is rather like us in that it's cross-platform and for realtime stuff I'd predict that PD also uses RTAudio so it might not be so surprising that it behaves the same way. It might be a logical next step to try something realtime that uses a different library. Another possibility: if any one random program is taking a lot of CPU then there will be audio hickups but that needn't mean the audio system itself has a problem. Did you check how CPU usage is distributed? The world's history is full of incidences of blaming something (or preferably somebody) else first before doing a lot of work yourself so let's try if we can do this as well :¬). Kas.
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. I also heard that someone just re-installed the last Airport update: http://www.apple.com/support/downloads/airportextremeupdate2007004.htm and it solved the problems. Check this thread, also: http://discussions.apple.com/thread.jspa?threadID=1463824&tstart=0 brad http://music.columbia.edu/~brad 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
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
Apple dropped the ball on this one.
So, I performed the (totally unsafe) procedure described in the second
of Brad's links:
http://discussions.apple.com/thread.jspa?threadID=1463824&tstart=0
And it solved the problem. It's a roll-back to the previous version
of the Airport Extreme update by extracting the contents of the .pkg
and manually replacing the newer version with the old. A friend of
mine likened it to "doing open-heart surgery with a knife you found on
the floor of Denny's."
I don't like it, but it worked.
-Mike
On Tue, Apr 15, 2008 at 3:55 AM, Ge Wang
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
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- urls is coming...
Ge- I think I have encountered this same problem using the same LiSa patch on two different machines. Hiccups occur on one at about 30% CPU and the other at 17-20% CPU. Both are MacBook Pros running 10 .4.11. Maybe you can send me a simple test to run on both machines (since my poor hacking skills could always be an issue). What updates do you think cause the problems? My *good* running machine is the one least likely to have had any updates. I might be of service in identifying the problematic update(s) by examining the recent updates on both machines. *********** Van Stiefel Assistant Professor Department of Music Theory and Composition Swope Music Building College of Visual and Performing Arts West Chester University West Chester, PA 19383 Tel.: 610-436-2757 -----Original Message----- From: chuck-users-bounces@lists.cs.princeton.edu on behalf of Ge Wang Sent: Mon 4/14/2008 3:42 AM To: ChucK Users Mailing List Subject: Re: [chuck-users] OSX updates =< real-time audio? 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
participants (6)
-
Brad Garton -
Ge Wang -
Kassen -
mike clemow -
Stiefel, Van -
volker böhm