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: [email protected] 
[mailto:[email protected]] 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?
 _______________________________________________
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]

Reply via email to