Re: CAPlayThrough Unreliable/Busted?
Re: CAPlayThrough Unreliable/Busted?
- Subject: Re: CAPlayThrough Unreliable/Busted?
- From: tahome izwah <email@hidden>
- Date: Mon, 20 Dec 2010 22:53:46 +0100
CAPlayThrough never worked right and had long term stability issues,
especially when using anything other than the default built-in
devices. I ended up rewriting the whole thing because it was totally
unstable.
HTH
--th
2010/12/20 Christopher Liscio <email@hidden>:
> Hey folks,
>
> I've been looking at the CAPlayThrough sample code in order to see whether I could include it in a future update for TapeDeck, but some testing has led me to question whether this code is actually worth using.
>
> When I set my input device to a simple USB device (The ART USB DualPre), and the output to my MOTU Traveler, I notice that the audio starts to go out of whack after a few minutes. First it starts buzzing a little bit, and then a bit more, and after some period of time it'll transition to delaying the output audio by 500ms or more.
>
> I've experienced this regardless of having mixed or matched sample rates between the devices.
>
> Furthermore, spending some time looking through the latest code for CARingBuffer.cpp has left me absolutely puzzled about how this code ever worked…
>
> For instance, check out this line of execution from CARingBuffer::Fetch(). Follow along here for the line numbers I'm referring to: https://gist.github.com/f91d436e8027c81451b9
>
> 1. On line 245, the 2nd and 3rd parameters, nFrames and startRead, are specified in frames.
> 2. Then, on line 257, a variable called 'destStartOffset' is calculated in terms of those values (and hence specifies a number of frames).
> 3. On line 273, FetchABL() is called, passing 'destStartOffset' as the 2nd parameter.
> 4. On line 130, the parameter destOffset (passed in from 'destStartOffset') is used to offset a (Byte*) pointer. So it's expected to be specified in bytes, and not frames!!
>
> Anyway, I've filed a bug (rdar://8790297) against CAPlayThrough to track the issue.
>
> I'm finding it a bit hard to follow exactly what CARingBuffer is doing enough to attempt to fix the issues myself, but I'll keep pressing on. If anyone knows of a workaround, I'd love to hear about it.
>
> Cheers,
>
> Chris Liscio
_______________________________________________
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