• 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: Fighting Classic for CPU in audio callback
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fighting Classic for CPU in audio callback


  • Subject: Re: Fighting Classic for CPU in audio callback
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 19 May 2003 16:21:23 -0700

I should point out that there is an AudioCodec SDK in /Developer/Examples/CoreAudio/AudioCodecs. Feel free to post questions about it here.

On Monday, May 19, 2003, at 03:37 PM, Bill Stewart wrote:

I'd use the same priority/policy that we use in the AudioFile feeder thread - take a look in PublicUtility/AudioFileImpl in the SDK - it has the code there as well..

BTW - are you bringing FLAC up as an AudioCodec? that would be good for reasons we'll be going into more at WWDC this year

(AudioUnit/AudioCodec.h)

- look forward to trying this Brian

Bill

On Monday, May 19, 2003, at 02:40 PM, Brian Willoughby wrote:

Hello all,

I have been working on a player for flac 1.1 files (Free Lossless Audio
Codec). It has been working flawlessly with the feeder thread using the time
constraint scheduling policy and double buffers of about 1 second each (less if
there are more than two channels). Typical Window Service activities, like
fidgety dragging of large windows or extreme magnification in the dock, have no
adverse effect on the playback.

I just discovered that Classic can cause audio stuttering when an application
running in Classic saves a file, even one that is only 8K. In this case, my
buffers may have been only 1/3 second because I was playing to a 6-channel
device - not sure if it was in 2-channel or 6-channel mode.

I have not set the priority or importance of the feeder thread. Is there a
minimum value I can use which will guarantee that my feeder thread will win any
battle with Classic? I know that it is best to stay below the CoreAudio
threads themselves, or else everything will stop working, but it be possible to
set my player between Classic and CoreAudio.

I noticed the problem running 10.2.6, but I would also like to know if Classic
has a higher or lower priority in 10.1.5 (and what that priority is).
Obviously, I can avoid Classic if there is no solution, but my hunch is that it
should not be too hard to beat Classic.

Brian Willoughby
Sound Consulting
_______________________________________________
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.


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

_______________________________________________________________________ ___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________ ___
_______________________________________________
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.



--

Jeff Moore
Core Audio
Apple
_______________________________________________
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: 
 >Re: Fighting Classic for CPU in audio callback (From: Bill Stewart <email@hidden>)

  • Prev by Date: Re: Fighting Classic for CPU in audio callback
  • Next by Date: An important note on AUPreset data
  • Previous by thread: Re: Fighting Classic for CPU in audio callback
  • Next by thread: An important note on AUPreset data
  • Index(es):
    • Date
    • Thread