For the longest time I have wanted an SPDIF interface for the Mac
(FireWire?) which allows access to the full 32-bit word. Problem is that
the Crystal part interprets the bits and delivers audio sample bits (up
to 24) on a separate pin from the control bits (up to 16). This is handy
if you don't have a processor available, but it limits what can be done
if you do. It would certainly be possible to just give the Mac a 32-bit
stream and let the Mac split that into audio and control, but it would
require custom silicon - unless there is already such a chip and I've
missed it. Flags and block starts would be a cinch this way.
Brian Willoughby
Sound Consulting
On Jan 21, 2008, at 04:12, Mikael Hakman wrote:
Stephen Davis <email@hidden> wrote:
As for the auto-detecting of bitstream vs. PCM goes, I have that
working for DD but haven't looked into the audio/video sync issue very
closely yet. In cursory experiments, it seems to be fine. The DD
bitstream lets you decide pretty quickly what mode you're in but I'm
sure it will take some work to get the latency down low enough.
When I did my experiments, I had to buffer more than one whole SPDIF
block before knowing for sure whether it was PCM or DD or DTS. Then I
needed a whole block before I could decode it, and then there was
decoding time, and then there was some latency in OS and devices (both in
and out). All this together made an unacceptable delay between audio and
video. This is when I gave up. The problem is that the syncword used in
DD and DTS is a valid PCM value and that the DD/ DTS flag in SPDIF is
normally not available outside the device, and not always set, and that
you don't see in your code where each SPDIF block starts - you only see a
buffered continuous stream. Perhaps you found a clever algorithm for
this - could you share it with me, please?
Thanks/Mikael
__________ NOD32 2811 (20080121) Information __________
Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com
