On Mon, Dec 22, 2014 at 5:23 PM, Steven Clark <[email protected]> wrote: > > It doesn’t look like this is taking place during the critical time. >
indeed, some hardware property change which effectively means that audio processing is likely interrupted. > By the way, the last time I checked malloc() was actually bounded (and > short) time; > how did you check this? if the malloc mechanism needs to call brk(2), it will not be bounded. free() is the potential problem. And, implementations these days are > pretty smart about free() too. > there are many different implementations of malloc/free, some of which are almost RT safe. i'd be extremely suprised if the one that comes with the Darwin C library meets that description, and it almost certainly doesn't avoid locks.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
