Re: Buffer size change property?
Re: Buffer size change property?
- Subject: Re: Buffer size change property?
- From: Jeff Moore <email@hidden>
- Date: Tue, 26 Mar 2013 12:53:42 -0700
This may not help you much, but the core model we use for keeping the IO machinery in sync with the hardware is the same mechanism we have always been using. So anything you might have learned from writing IOAudio-based drivers would be applicable here too. The server plug-ins are just the first time we've expressed this model in user-space.
At any rate, here's a quick recap of how sync works. The hardware provides a sequence of time stamps that map the sample clock to the host clock. The interval between these time stamps is precisely the number of frames that kAudioDevicePropertyZeroTimeStampPeriod reports. This corresponds precisely with the zero time stamps that an IOAudio-based driver provides that are based on the driver's ring buffer.
The HAL takes this sequence of time stamps and uses them as the input into a predictor. The predictor provides the HAL with the ability to know what host time a given sample time will correspond to. This is then used to schedule all the IO threads so that they do their work at the appropriate time.
Hope this helps shed a little light on things for you.
--
Jeff Moore
Core Audio
Apple
On Mar 26, 2013, at 12:31 PM, Eric Gorouben <email@hidden> wrote:
> Thanks Jeff,
>
> That explain the variations of the IOBufferFrameSize.
> The kAudioDevicePropertyZeroTimeStampPeriod is used by the server to evaluates it's "degree of freedom" and get the sync values in GetZeroTimeStamp , right?
> The use of these time stamp mechanisms is still confusing for me, and the way the plugin and the server keep in sync.
>
> Eric
> Le 26 mars 2013 à 18:42, Jeff Moore <email@hidden> a écrit :
>
>>
>> On Mar 26, 2013, at 6:23 AM, Eric Gorouben <email@hidden> wrote:
>>
>>> In the HAL plugin design, the buffer size changes used the kAudioDevicePropertyBufferFrameSize property.
>>> This property doesn't seem to exist in the new audio server plugin implementation.
>>
>> That's correct. kAudioDevicePropertyBufferFrameSize represents the IO buffer size (in frames) for the client process. It is probably a non-intuitive thing, but this value actually has surprisingly little meaning for the server plug-in.
>>
>>
>>> AudioServerPlugin.h:
>>>> RequestDeviceConfigurationChange:
>>>> When a plug-in's device object needs to change its structure or change any state related to IO for any reason, it must begin this operation by invoking this Host method.(...)The sorts of changes that must go through this mechanism are anything that affects either the structure of the device or IO. This includes (...), changing the size of the ring buffer...
>>>
>>> While I can easily find the property associated with such changes in AudioHardwareBase.h (kAudioDevicePropertyNominalSampleRate, kAudioDevicePropertySafetyOffset
>>> , etc) I can't find the mechanism for the buffer size.
>>> How does in work?
>>
>> Basically, your sever plug-in doesn't get to say anything about the IO buffer size for the client. That is by design as different clients can have different IO buffer sizes at the same time. For example, Logic might want an IO buffer size of 64 frames whereas iTunes is generally pretty happy with the default size of 512. The mix engine in the HAL handles dealing with the various buffer sizes and implementing the coloring algorithm to know when each client has actually provided the data for a given time segment.
>>
>> The net effect is that the server plug-in has to be prepared for the fact that the HAL will call to read/write data of the various sizes that will come up as one client's IO cycle beats against another clients.
>>
>>
>> --
>>
>> Jeff Moore
>> Core Audio
>> Apple
>>
>>
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
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