Re: I/O device with multiple *independent* SPDIF ports?
Re: I/O device with multiple *independent* SPDIF ports?
- Subject: Re: I/O device with multiple *independent* SPDIF ports?
- From: Stephen Davis <email@hidden>
- Date: Tue, 22 Jan 2008 09:13:09 -0800
On Jan 22, 2008, at 5:57 AM, Brian Willoughby wrote:
Thanks for the pointer to the RME FireFace 800. I have sent a
message to their support contact and identified myself as a Mac OS X
developer needing this feature.
That's cool but I still need a switcher. I found a 4-port one here
that looks promising, esp. because it has RS-232 control support for
changing inputs. Hook that up in front of an RME FireFace 800 and
now we're talking. :-)
http://www.inday.com/da4x/da4x.htm
But I am a still little surprised that you would see many zero
samples. I have encoded 4.0 audio into a 5.1 DTS stream, simply
because I had no need for a center channel, and I imagine that this
was very wasteful of bandwidth. But it seems like a full 5.1 mix
with audio in all channels and significant LFE energy would use
nearly all of the 1.5 Mbps bandwidth available. I will take your
word for it, though, since I have not done any analysis of
commercial releases to see if my assumptions are correct.
DD transmission over SPDIF theoretically can use the extra space to
send the bitstreams for secondary languages, up to 8. That way, the
receiver can pick which language it wants. I have yet to see any
sending devices that do this though.
For DTS, the DVD bit rate is typically less than 1.5Mbps -- I think
it's 768Kbps. For Red Book Audio CDs they typically use the entire
1.5Mbps. Neat point about the 14-bit usage though, I thought they
were being super clever and manipulating the bitstream layout such
that it sounds more like white noise. Of course, if you use all of
the bandwidth then you don't have the bursts + zeros either so that
might mitigate the issue too.
Going back to a previous question, yes the DD sync word is two valid
16-bit samples but the DD over SPDIF specification recommends
searching for 4 leading zeros first to reduce the likelihood of
collision even further. In practice (so far), I have not found the
extended sync word necessary.
stephen
If only all digital audio devices were interconnected with FireWire
and clocked by the final DAC rather than the data source, I think we
wouldn't be stuck with such unwieldy standards as S/P-DIF.
Brian Willoughby
Sound Consulting
On Jan 22, 2008, at 05:01, Mikael Hakman wrote:
That sounds cool -- which FW device is that?
What is the FireWire interface with 32-bit integer format for
digital audio (SPDIF)? Does it need a special driver to work with
a Mac?
It's RME Fireface 800. According to User's Guide there are drivers
for both operating systems on the disk, and installation procedures
are well described.
P.S. DTS only uses the lower 14 bits of the audio sample, so that
the digital noise is at -12 dB. Seems like a shame to lose 96
kbps of bandwidth.
Not only that! If you look at the actual content of SPDIF when
transmitting DD or DTS then you'll see that large parts of each
block do not transmit any information at all. All samples are set to
zero. This is because compressed data, even for 6 channels, require
much fewer bytes than 2 channels PCM for corresponding time length.
Each block in SPDIF is of fixed byte length, and for given rate,
also of fixed time length. Therefore they have to fill it with zeros
when actual data for this time length is shorter. Talk about wasting
bandwidth! All this seems to steam from the fact that SPDIF was
designed to transfer digital audio *signals* as opposed to *data*.
Then someone come up with the brilliant idea of sending compressed
data through it. Then AES adopted all this, and now we are where we
are.
Regards/Mikael
_______________________________________________
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