• 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: William Stewart <email@hidden>
  • Date: Mon, 5 Apr 2004 12:20:22 -0700

On 05/04/2004, at 2:12 AM, Stiphane Letz wrote:
=I think the question here is to see if they are differences for the
scheduler in the following cases:
>>>
>>> - a real-time thread is prempted because it reached the end of it's
>>> "computation" slice (the "computation" parameter defined in the time
>>> constraints setting)
>>>
>>> - a real-time thread finished it's job, control go back to the HAL
>>> that finally suspend the thread with something like
>>> "pthread_cond_timedwait" and return control to the scheduler
>>>
>>> - a real-time thread suspend itself with "pthread_cond_wait", but
>>> it will be resumed in the same audio cycle.
>>
>> As an example, my app runs multiple threads for drawing: a rendering
>> thread, and one or more threads per-screen for synchronization
>> purposes. The sync threads use extended policy with priority 63, and
>> the rendering thread is normal timeshare 31. While profiling a
>> certain DSP computation, its period would increase 150% when a flush
>> thread had more work to do, in which case it was blocked on
>> mach_msg_trap, while the window server of priority 79 would blit the
>> window backing store.
>
> Where did you see this 79 priority? I always though the Windows server
> had a 63 priority...

The Window Server has a few threads, and a few priorities...

63 for its event handling - ie. very little work at highest user
priority
51 for its compositing.. that way user threads that have higher
priority tasks than UI (like disk reading data for a realtime consumer)
can get above the WS's UI...

>
> Darwin source. CGS runs at 76, and max pri is 79 unless it gets
> bumped to realtime.

It might ask for it - but you should look at ps axM to see if it
actually gets it at run time...

me 233 ?? 1.3 S 51 9:50.33 16:52.37
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/
CoreGraphics.framework/Resources/WindowServer -daemon
233 0.0 S 63 0:14.32 0:17.03

Real-Time???? for the WS??? Now that would be a bug and a big problem...

I'm not entirely sure what you mean by CGS - are we talking about the
same thing here?

Bill

--
mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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: Shaun Wexler <email@hidden>
References: 
 >Re: Audio threads scheduling (Modifié par St éphane LETZ) (From: Stéphane LETZ <email@hidden>)
 >Re: Audio threads scheduling (From: Shaun Wexler <email@hidden>)
 >Re: Audio threads scheduling (From: Stéphane LETZ <email@hidden>)
 >Re: Audio threads scheduling (From: Shaun Wexler <email@hidden>)
 >Re: Audio threads scheduling (From: Stéphane Letz <email@hidden>)

  • Prev by Date: Re: MusicSequence and virtual sources...
  • Next by Date: Re: MusicSequence and virtual sources...
  • Previous by thread: Re: Audio threads scheduling
  • Next by thread: Re: Audio threads scheduling
  • Index(es):
    • Date
    • Thread