Re: Is there any clock drift compensation mechanism in the HAL?
Re: Is there any clock drift compensation mechanism in the HAL?
- Subject: Re: Is there any clock drift compensation mechanism in the HAL?
- From: Kurt Bigler <email@hidden>
- Date: Mon, 23 Feb 2004 20:06:11 -0800
on 2/23/04 2:40 PM, Jose Commins <email@hidden> wrote:
>
Thinking about it, here's an idea - how about supplying an internally
>
generated word clock to audio (and indeed video) card manufacturers to
>
sync their streams to?
>
>
Regards,
>
Jose.
This is a very nice idea and no doubt lots of us would like it.
However synchronizing to a soft host-provided "clock" probably requires an
entirely different implementation from what audio devices currently use to
synchronize to external *hardware* clocks. You can't really do a soft word
clock per se. It would probably require that each device's driver keep each
device updated with regular clock rate corrections so that an actual
hardware clock in each device could be updated.
But this would be different from hardware clock locking: useful for
avoiding net drift but no substitute for an actual clock cable between
external devices. Buffered data transport can't simulate what a dedicated
hardware line can do.
But yes, I was thinking the very same thing as I was struggling with my
hardware clocks to get multiple devices to sync reliably. Maybe it is still
a useful idea for limited purposes but each manufacturer would also have to
decide to implement it if indeed CoreAudio people wanted to support it.
Two particularly good uses for a CoreAudio soft clock I can think of are:
(1) to synchronize another device with built-in audio, which has no other
synchronization mechanism available, unless you are connecting the built-in
digital out to your other device, perhaps.
(2) to synchronize with CD transport. My past experience was that playing a
CD (one loaded in the Mac itself) through my high-quality output device is
fruitless due to unavoidable clicks caused by lack of synchronization. I
seem to recall that the same problem might even have existed when playing
CDs through built-in audio, but I can't remember now. The question there is
whether even built-in audio has a way of synchronizing with CD transport.
Off-hand it would seem much better to have the software CD player be smart
enough to read the CD directly and only read when more data is actually
needed - thus in effect synchronizing the CD transport with the device it is
being output to. Getting off-topic here though.
-Kurt
_______________________________________________
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.