I'm a bit confused as to why there is a non-critical time for this thread. Evidently, between DSP callbacks it does some other work where dynamic allocation happens. What if that malloc were to block long enough to overlap with when the next DSP callback needs to happen? (It might call free() also, I haven't tried that breakpoint)
- Taylor On Mon, Dec 22, 2014 at 2:23 PM, Steven Clark <[email protected]> wrote: > 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]
