Re: Native Device Formats
Re: Native Device Formats
- Subject: Re: Native Device Formats
- From: "Mikael Hakman" <email@hidden>
- Date: Fri, 6 Jun 2008 16:41:22 +0200
- Organization: Datakonsulten AB
Digging into details a little deeper, you discover that S/PDIF has only one
mode, the 24-bits mode. AES/EBU signal, which is a professional version of
S/PDIF has 2 modes, 20-bits and 24-bits mode. In AES/EBU standard there is a
bit in Channel Status stream indicating whether 20 or 24 bits mode is used.
According to the standard, when using 20-bits mode, the remaining 4 bits may
be used for optional talkback or inter/intra studio communication. In S/PDIF
standard this bit is used for different purpose (if used at all). Therefore,
a modern S/PDIF receiver circuit receives all 24-bits assuming that the
source has set not used bits to zero. Then the only way to tell how many
bits are used is by actually observing content of the audio stream, and
infer that e. g. if 8 lowest bits are constantly zero then it is 16-bits
signal. This may be right or wrong inference depending on the actual signal
and source. Conversely, a modern S/PDIF transmitter shall set the not used
bits to zero, when feed by a signal with less than 24 bits resolution.
Even when using AES/EBU signals, it has been observed that the indication of
20/24 bits modes isn't reliable. Therefore most modern units send and
receive 24-bits when not told differently; again setting not used bits to
zero. There simply isn't any advantage of doing something else, as all
24-bits have to be sent anyway on the wire.
This situation is analogous to the famous non-audio bit within the Channel
Status stream. Most modern devices do not rely on this bit alone, but do
also their own assessment based on the content of (non)-audio stream. They
have to do it anyway if they want to decode the non-audio data in some
meaningful way. Once upon the time we had only AC3 there. Nowadays it could
be AC3, DTS, WMA, AAC, MPEG or even FLAC or ALAC.
One reason for this situation is that it is more difficult to build hardware
and program the software that correctly sets and accesses these bits. Due to
interfaces provided by actual semiconductor components used in such
hardware, it is much simpler to set these bits to constant value on output
and ignore them on input.
On Friday, June 06, 2008 2:12 AM, Brian Willoughby wrote:
For those that care about the details, S/PDIF actually has two modes:
24-bit and 20-bit. Each is capable of carrying fewer significant bits by
zeroing out the excess LSBs. However, in 20-bit mode, 4 bits become meta
data, and thus would result in (minor) distortion of the audio if assumed
to be part of a 24-bit audio sample. In other words, S/PDIF does not
always send 24 bits, but it does always send 20 bits.
On a related note, TobyBear has an AU which displays the number of bits
being used. If you replace your AV receiver with a digital-in Mac with
this AU displayed, you could confirm the bits transmitted.
On Jun 5, 2008, at 06:23, Mikael Hakman wrote:
I don't know about MB but I have verified using an external AV receiver
connected to an MBP and an iMac by S/PDIF that if you select 44.1 or 48
or 96 kHz in SAM panel then this is the sample rate arriving to AV
receiver. Both my MBP and iMac use Realtek HD circuits, perhaps MB too.
I've been unable to verify number of bits because this isn't shown on my
AV receiver's status display but I would be surprised if the number of
bits isn't what you select. Note that S/PDIF sends always 24 bits even
if not all of them are used.
_______________________________________________
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