• 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: Multi-threading and glitchless audio
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multi-threading and glitchless audio


  • Subject: Re: Multi-threading and glitchless audio
  • From: Kurt Revis <email@hidden>
  • Date: Wed, 26 Feb 2003 20:36:41 -0800

On Wednesday, February 26, 2003, at 11:40 AM, Amar wrote:

The audio architecture is as followss: CoreAudio callback fires-off audio
processing activity in one or more other threads, and waits until those
threads complete before returning.

This setup pretty much guarantees that you will have problems. The CoreAudio callback happens very frequently and periodically. It sounds like the other threads are taking too long to finish, causing your callback to block for a long time. So your callback doesn't return in time for CoreAudio to supply data to the hardware, and you get dropouts.

You want to do as little as possible in your CoreAudio callback as possible. Ideally you would just copy data from your own buffers into CoreAudio's buffers, and then return. You absolutely do *not* want to block waiting for other threads to do anything, because then you're dependent on the other thread getting time and finishing its work.

(Or you can do your processing directly in the callback, but you should be very certain that it doesn't take too long.)

I have attempted to use the Mach real-time threading procedures to make the
audio-processing threads higher-priority than the UI, and I think I'm doing it
right (I took the code directly from either this list or a related list hosted
by Apple), but I still get cut outs.

Even if you boost the priority of your other threads, the CoreAudio thread is getting blocked for too long. You probably want to decouple the CoreAudio thread from your other threads entirely, using some kind of buffering scheme. It's possible to do this without blocking at all.

Trying to re-write the architecture of my software to run its processing exclusively in the audio-callback procedure would be rather difficult

You don't have to. Just introduce some buffering between the audio producer thread(s) and the CoreAudio thread.

Is anyone else attempting to process audio in multiple threads, and if so
is there a trick to doing this that I'm missing?

Here's how I do it:
http://www.snoize.com/Code/PlayBufferedSoundFile.tar.gz

Apologies to the list for posting this for the hundredth time.

--
Kurt Revis
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

References: 
 >Multi-threading and glitchless audio (From: "Amar" <email@hidden>)

  • Prev by Date: Re: Audio Units and virtual memory
  • Next by Date: Why I failed to read from my hid device, while I can write to it?
  • Previous by thread: Re: Multi-threading and glitchless audio
  • Next by thread: Audio Units and virtual memory
  • Index(es):
    • Date
    • Thread