| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Feb 4, 2005, at 2:01 PM, Jeff Moore wrote:Do you know why the dropouts are happening in the first place? It's hard to offer a strategy to avoid them if you don't know why they are happening. Can you provide some more detail?
On the whole, there are no written rules against doing work in the IOProc. In fact, many apps do. The trouble usually comes in due to unforeseen interactions with the other threads in the process.
What I'm doing is pretty simple. I set up the callbacks and some codec-specific handles, start the output audio unit, and then in the callback just iteratively pull decoded samples out of the codec until I've read enough to satisfy the requested number of samples. This *does* require going to disk, which I gather from other discussions on the list is discouraged. The glitches happen a lot more regularly when I'm playing files over nfs, which also makes me suspect that blocking I/O is the problem. I can post some short sample code if that would help.
This makes me wonder - would I be better off doing a minimal read from the codec and returning fewer than the requested number of frames, forcing the output AU to call back sooner, rather than spending enough time in the callback to provide all the requested frames?
Thanks for taking the time to help.
--
miles
| References: | |
| >dumb newbie question on avoiding dropouts in ioproc (From: Miles Egan <email@hidden>) | |
| >Re: dumb newbie question on avoiding dropouts in ioproc (From: Jeff Moore <email@hidden>) | |
| >Re: dumb newbie question on avoiding dropouts in ioproc (From: Miles Egan <email@hidden>) |
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.