• 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: does CoreAudio respect the server plugin driver properties?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: does CoreAudio respect the server plugin driver properties?


  • Subject: Re: does CoreAudio respect the server plugin driver properties?
  • From: Frederic De Jaeger <email@hidden>
  • Date: Tue, 04 Nov 2014 15:29:57 +0100

IMHO, 441 samples for your circular buffer size looks way too small.  I would pick a much larger value, if I were you.  I would not be surprise if a so small value could confuse CoreAudio.  All the audio interfaces I have show a Max IO Buffer Size greater than 4096.  Usually, the IO Buffer size is set to 512 frames (but to be able to provide that size, your circular buffer must be at least twice as big).

Have you look at how your driver responds to:

    kAudioDevicePropertyBufferFrameSize                 = 'fsiz',

    kAudioDevicePropertyBufferFrameSizeRange            = 'fsz#',



It does not harm latency to have a big circular buffer.  CoreAudio always tries to write the closest possible to the "Tape head".  But if there is more room on the tape, there is less risk for an overrun and CoreAudio feels happier.

Fred

2014-10-29 16:14 GMT+01:00 hagen <email@hidden>:
Hi all,

I must admit I am pushing it, but (test-wise) I configure my CoreAudio server plugin with a 10ms circular buffer (i.e. 441 sample frames at 44.1kHz, following is all at 44.1kHz), accordingly the plugins answers kAudioDevicePropertyZeroTimeStampPeriod request with 441. No matter how the plugin answers the kAudioDevicePropertySafetyOffset request DoIOOperation (kAudioServerPlugInIOOperationWriteMix) is called with upto 441 sample frames and a sample time of upto 610+safety offset sample frames in the future.

Why does CoreAudio think the plugin can receive 441 sample frames at once (when a non-zero kAudioDevicePropertySafetyOffset was provided?) and why does CoreAudio think the plugin can handle upto 610+safety offset+441 sample frames in the future?

CoreAudio (via HALLab Default device alert) seems to call DoIOOperation at least 150 sample frames in the future. Which is an inherent “safety offset” of 3.4ms.

What would be the minimal and what the optimal buffer size in sample frames (or msec) the CoreAudio server plugin should provide? Does this scale well with high channel counts?

Cheers and thanks,
Hagen


 _______________________________________________
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

 _______________________________________________
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:
    • Logic x64, Yosemite & FSMakeFSRefUnicode
      • From: Thomas Rehaag <email@hidden>
  • Prev by Date: Audio setup is extremely slow on iPhone 6
  • Next by Date: Logic x64, Yosemite & FSMakeFSRefUnicode
  • Previous by thread: Audio setup is extremely slow on iPhone 6
  • Next by thread: Logic x64, Yosemite & FSMakeFSRefUnicode
  • Index(es):
    • Date
    • Thread