• 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: Audio threads scheduling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Audio threads scheduling


  • Subject: Re: Audio threads scheduling
  • From: Stéphane Letz <email@hidden>
  • Date: Fri, 2 Apr 2004 11:47:42 +0200

--__--__--

Message: 7
From: Jeff Moore <email@hidden>
Subject: Re: Audio threads scheduling
Date: Thu, 1 Apr 2004 15:43:52 -0800
To: CoreAudio API <email@hidden>

You have a point about MillionMonkeys. It is a good example of the
priority inversion I was talking about in my other messages and why the
HAL does things a little differently with it's IO threads.

Yes.

I tested using 2 copies of the program, one running a thread with a buffer size of 64, the other with a buffer size of 1024, both using a real-time feeder thread. Indeed the thread with buffer size of 64 can not meet it's dealdine. Now if I correct the setThreadToPriority function to allocate values for the computation period the way you described it for the IO thread, then things start to work.

Actually how are *computed* these values for the computation value? Are then coming from a theoritical framework?

I saw also that the Midi IOThread (that call a RedadpProc callback) has the following values:

period : 0 (no periodicity)
computation : 250 us
constraint : 500 us
preemptable = 1

I guess these value are carefully choosen to be compatible the values taken for the Audio IO thread?


I wouldn't stress to hard over it. MillionMonkeys was originally
written to help stress out the system, all the while trying to simulate
the different strategies a real world audio engine might use for it's
threading. One of the lessons we learned from it is that having your
feeder threads be real-time isn't normally a good thing.

Buy why?
Actually using fixed priority 63 for the feeder threads does not work so well...
And using real-time 96 for the feeder threads with properly choosen values for the computation parameter work quite well and solve interleaving problems.

So what are the *technical* issues to prevent using real-time feeder threads?

Thanks

Stephane Letz


On Apr 1, 2004, at 3:20 PM, Stiphane LETZ wrote:
_______________________________________________
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.


  • Follow-Ups:
    • Re: Audio threads scheduling
      • From: William Stewart <email@hidden>
  • Prev by Date: Re: MIDI processing question
  • Next by Date: RE: MIDI processing question
  • Previous by thread: Re: Audio threads scheduling
  • Next by thread: Re: Audio threads scheduling
  • Index(es):
    • Date
    • Thread