Apple

It doesn’t look like this is taking place during the critical time.

When the thread calls into client code to obtain audio data, it is under tight time constraints to get that data to the hardware before the hardware runs out of data to play. Then (unless it’s doing something I don’t know about) the thread can go on a short vacation until the next time the hardware gets low on data.

By the way, the last time I checked malloc() was actually bounded (and short) time; free() is the potential problem. And, implementations these days are pretty smart about free() too.

Steven J. Clark

VGo Communications

From: coreaudio-api-bounces+steven.clark=email@hidden [mailto:coreaudio-api-bounces+steven.clark=email@hidden] On Behalf Of Taylor Holliday
Sent: Monday, December 22, 2014 5:09 PM
To: CoreAudio API
Subject: I thought audio processing threads weren't supposed to call malloc

Yet I see CoreAudio doing it:

* thread #10: tid = 0x4b78b, 0x00007fff95ea436b libsystem_malloc.dylib`malloc, name = 'DSP thread', stop reason = breakpoint 6.11

* frame #0: 0x00007fff95ea436b libsystem_malloc.dylib`malloc

frame #1: 0x00007fff936f923e libc++abi.dylib`operator new(unsigned long) + 30

frame #2: 0x00007fff901dbf0c CoreAudio`void std::__1::vector<CAPropertyAddress, std::__1::allocator<CAPropertyAddress> >::__push_back_slow_path<CAPropertyAddress>(CAPropertyAddress&&) + 180

frame #3: 0x00007fff901d05ea CoreAudio`CAPropertyAddressList::AppendItem(AudioObjectPropertyAddress const&) + 74

frame #4: 0x00007fff901aefb3 CoreAudio`HALObject::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 441

frame #5: 0x00007fff901aecde CoreAudio`HALDevice::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 438

frame #6: 0x00007fff901bb9ee CoreAudio`HALSystem::AudioObjectPropertiesChanged(AudioHardwarePlugInInterface**, unsigned int, unsigned int, AudioObjectPropertyAddress const*) + 158

frame #7: 0x00007fff901c4009 CoreAudio`HALC_ProxyIOContext::IOWorkLoop() + 1121

frame #8: 0x00007fff901c3b0e CoreAudio`HALC_ProxyIOContext::IOThreadEntry(void*) + 88

frame #9: 0x00007fff901c39eb CoreAudio`HALB_IOThread::Entry(void*) + 157

frame #10: 0x00007fff8dcc02fc libsystem_pthread.dylib`_pthread_body + 131

frame #11: 0x00007fff8dcc0279 libsystem_pthread.dylib`_pthread_start + 176

frame #12: 0x00007fff8dcbe4b1 libsystem_pthread.dylib`thread_start + 13

Am I misreading this?