Re: dumb newbie question on avoiding dropouts in ioproc
Re: dumb newbie question on avoiding dropouts in ioproc
- Subject: Re: dumb newbie question on avoiding dropouts in ioproc
- From: Jeff Moore <email@hidden>
- Date: Fri, 4 Feb 2005 14:01:36 -0800
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.
On Feb 4, 2005, at 1:22 PM, Miles Egan wrote:
After spending some time browsing around in the list archives, I'm
getting the idea that the recommended method for avoiding dropouts in
render callbacks is to feed the callback with data from a separate
feeder thread and to do minimal work in the actual callback function.
Is this still the best approach? It's a clever solution but it seems
fairly complex for simple audio playback.
To be more specific, I'm working on a simple music player that
generally eats less than 5% of a 2ghz G5. Playback quality is very
good for several different input codecs but I do get the occasional
glitch. I'd prefer to find a simpler solution than a full-blown
lock-free ring buffer setup, but I guess I'll just bite the bullet if
that's the only way.
Does it help that I have very relaxed latency restraints? Could I get
any significant mileage out of tricks like increasing the output
device's buffer size or changing the priority of the core audio
playback thread? Since I'm practically just shoveling data out of a
file into the output unit I'm hoping I can get off a little easier
here.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden