• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: I thought audio processing threads weren't supposed to call malloc
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I thought audio processing threads weren't supposed to call malloc

  • Subject: Re: I thought audio processing threads weren't supposed to call malloc
  • From: Taylor Holliday <email@hidden>
  • Date: Tue, 23 Dec 2014 01:15:33 -0800
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@hidden> 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: 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?


 _______________________________________________
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
  • Follow-Ups:
    • Re: I thought audio processing threads weren't supposed to call malloc
      • From: Paul Davis <email@hidden>
References: 
 >I thought audio processing threads weren't supposed to call malloc (From: Taylor Holliday <email@hidden>)
 >RE: I thought audio processing threads weren't supposed to call malloc (From: Steven Clark <email@hidden>)

  • Prev by Date: Re: RE: I thought audio processing threads weren't supposed to call malloc
  • Next by Date: Re: I thought audio processing threads weren't supposed to call malloc
  • Previous by thread: RE: I thought audio processing threads weren't supposed to call malloc
  • Next by thread: Re: I thought audio processing threads weren't supposed to call malloc
  • Index(es):
    • Date
    • Thread