Re: Timing issues with loopback driver on OS X Mavericks
Re: Timing issues with loopback driver on OS X Mavericks
- Subject: Re: Timing issues with loopback driver on OS X Mavericks
- From: Mikko Harju <email@hidden>
- Date: Thu, 21 Nov 2013 10:10:00 +0200
Hi,
I found the issue.
I was using interrupt based counting mechanism (I took the approach suggested by the “OS X and iOS Kernel Programming” book) to keep the driver’s timing in sync.
However there was a chance that it could go out of sync in a way it could not set the new timestamp correctly when wrapping (bufferOffset would not be exactly zero when wrapping).
I changed the implementation to buffer count based version that makes possible for it to test if it has exceeded the available count and reset correctly even if there were some issues with the timings. If someone has comments on this I’d be happy to hear them!
Setting the volume through the normal Core Audio Object API does to seem to have a lag still, but I think that one is unrelated to this issue.
Thanks,
:)Mikko
On 16 Nov 2013, at 01:43, Benjamin Rindt <email@hidden> wrote:
> Hey,
> I can't help you with that problem but I am experiencing the same with my application and it's play through. It takes a moment to stabilize but then it's working. It does not occur every time, more when not much ram is free.
>
> For me it's not just my application but mainstage 3 is doing the same thing
>
> -Benjamin
>
> Sent from my iPhone
>
>> Am 15.11.2013 um 15:38 schrieb Mikko Harju <email@hidden>:
>>
>> Hi all!
>>
>> We are implementing a loopback driver to work together with our application we are currently developing. We are having issues with losing sync with the input/output threads on the application.
>>
>> On OS X 10.8 the InputRenderProc starts to get samples with the correct count immediately. So for example if we should set buffer size to 512 samples, it starts getting them with timestamps with 512’s increments. On 10.9 it takes a while to stabilize, but gets eventually the timestamps consistent.
>>
>> After that, only minor glitches appear here and there. It is always the case that the OutputRenderProc’s timestamp is greater than the timestamp that we have received data for (we are storing the in a CARingBuffer, with 5x the buffer size as the size). I’ve tried adjusting the internal buffer size both from the driver, and also tried to adjust the interrupt timer frequency, but I’ve not gotten any better results with these.
>>
>> The console logs have this kind of entries in it:
>>
>> 15/11/13 15:56:48,000 kernel[0]: IOAudioStream[0xffffff803dbde600]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (39,11f4)->(3b,13f4).
>> 15/11/13 15:56:48,000 kernel[0]: IOAudioStream[0xffffff803dbde600]::clipIfNecessary() - adjusting clipped position to (3b,11f4)
>>
>>
>> Any ideas on this will be greatly appreciated!
>>
>> Thanks,
>> :)Mikko
>> _______________________________________________
>> 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