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: Brian Willoughby <email@hidden>
- Date: Tue, 22 Jan 2008 05:57:55 -0800
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.
Meanwhile, I will comment that the zero-filled samples you see are
"by design" because SPDIF is a Constant Bit Rate (CBR) stream. When
storing a file, Variable Bit Rate (VBR) makes the most sense, because
there is no reason to waste unused data space. However, SPDIF is
real time, and you cannot skip time just because you run out of data
for a block. In fact, CBR in compressed audio formats was devised
primarily because of the prior existence of constant bit rate
transmission media such as SPDIF, ISDN, et cetera.
Even more important is the fact that SPDIF combines the clock with
the data, so those zero-filled samples must be there in order to
maintain the constant sample clock for the DAC. Even though the
surround channels must be decoded from less data, the timing of the
incoming blocks, sample by sample, determines the outgoing conversion
clock for the multiple DAC chips. The clock recovery still acts as
if 2 channels of 16- or 24-bit audio is coming in, recovering the
clock based on this, and then driving 6 channels of output (in the
case of 5.1 surround).
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.
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