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: "Mikael Hakman" <email@hidden>
- Date: Wed, 23 Jan 2008 14:50:00 +0100
- Organization: Datakonsulten AB
The chat that Stephen, you and me have here is indeed very interesting. I
only hope that the other list members overlook this being a little off
topic.
Brian Willoughby <email@hidden> wrote:
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).
As you say S/PDIF (Sony/Philips Digital Interconnect Format) is real time
and, what not many people understand, it transports audio sample values in
digital form but the transported time information is analog. The clock is
given by real-time analog time differences between zero-crossings of
incoming, symmetric around zero, wave signal. This signal is sent out as
long as S/PDIF transmitter is active, even when there is nothing to send.
When a transported bit is 1 then there is an additional zero crossing in the
middle between 2 clock crossings, when it is 0 then there is no additional
crossing. In this sense it is a signal, not a data transport protocol. It is
a direct digital equivalent of an analog audio signal. When PCM audio is
transported then there is 1:1 relation between the pulse train and PCM bits.
Therefore in this mode, for which it was designed to beginning with, S/PDIF
is CBR. Years later, when surround audio had become popular, S/PDIF was
retrofitted by an extension allowing it to transport any data. This was done
because S/PDIF doesn't have the capacity to transport more than 2 channels
of uncompressed audio. The data that is transferred may now be anything, DD,
DTS, MP3 or any other compression format (or any data not even related to
audio), whether CBR or VBR. The only requirement is that the number of
actual bits transported is less than 2304000 per second (24 * 2 * 48000),
which is the maximum capacity as defined by the standard. This maximum
capacity yields actual bit rate of 3072000 bit/sec because there are
additional 8 bits for each 24 data bits. When PCM audio is transferred all
data bits are used. When non-audio data is transferred then it uses as many
bits as it needs and the rest is "empty", meaning zero.
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.
That depends on compression ratio and resulting (maximum) bit rate. I was
referring to a very common case, at least over here, a DVB stream with 5.1
DD audio which normally has 448000 bit/sec rate. Because the S/PDIF
transports 2304000 bits in a second there will be 2304000 - 448000 unused
bits in each second which will be zero. In my case, DVB is the actual reason
that I need to recognize and decode DD in my Mac computer. This is because a
DVB receiver is the only external DD source right now. DD or DTS coming from
a file or DVD drive is already decoded right. Exactly as you say, even when
the data is less than the capacity of the stream, you need the whole stream
because it defines the clock tics at which to output decoded audio (to a
DAC). Every DAC needs a clock, no clock = no DAC, the better clock - the
better DAC. However the clock in DAC must run in sync with the source clock,
otherwise the DAC will either over- or underflow. For multiple channels you
also need to sync the channels with each other, otherwise they will become
unsynchronized more and more as the time goes on. This is because no 2
clocks run at *exactly* the same rate. Which leads us to.
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.
As long as you have only one DAC, or a group of DACs with one common clock
using a protocol such as FireWire, USB, Ethernet etc that allows the
receiver to stop and resume the sender (handshaking) this should work very
well. However if you imagine an environment with multiple active devices,
each with own DAC and clock, such as active digital speakers in a 5.1 or 7.1
configuration, then you still need to synchronize to one clock. Also, during
live sessions, when the audio is coming real-time, you have to use the clock
from the source (the clock used by ADC at the source). A digital speaker
cannot say to a football game or a concert, "please wait until I catch up"!
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