Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: [Mplayer-dvb] DTS Sound





Uwe Weissbach wrote:

> Please correct me, but is'nt it a fact that we don't have
> to create the DTS data (because they came from DVD)
> but only wrapping them in...
>

In principle you are right, but we have to understand the principle bitstream
architecture how DTS frames looks like. Furthermore we have to extract some basic
information like frame length, mode, ...). But as Joachim says, Xine could be a good
reengineering address. It's worth to start a trial.

>
> and my second question, can *you* as the inventor of the
> AC3-over-DVB say something about things I discussed in
> http://www.linuxtv.org/mailinglists/vdr/2002/03-2002/msg01947.html
> about the status bit 1 in the channel status word?

You are right, it seems the mystery of the V-bit caused our problems. A short
description what this means:
In IEC958 format each audio sample is embedded in a 32 bit frame granularity. It
looks like the following bit structure:
Sync Preamle : 0-3
Auxillary Audio Data : 4-7
Audio sample word : 8-27
(V)alidity bit: 28
(U)ser data: 29
(C)hannel status: 30
(P)arity bit: 31

As you can see in principle there is room for 24 bit audio data. But most
transmitter/receiver handles only up to 16-20 bit.
The interested part is now the Validity bit. This flag is associated with each audio
sample word and indicates wether its value is reliable or not.
Ok, in case of raw PCM transmission it has to be zero to signalise the D/A converter
true audio data. In case of error's like changing of sampling rate the V-Flag is "1"
for some frame to force muting the D/A converter.
In our situation (IEC61937) it is recommend to set the validity bit to logical "1"
because we deliver not really more raw PCM data!!!
Unfortunatly as Uwe find out this bit is always "0". I can imagine that some
A/V-Receiver could have some trouble decoding such wrongly embedded AC-3 data.
Perhaps the decoder analyses the PCM data and finds out a discrepancy between
content and control bits-> mutes the output completly.
This is a very creditable behaviour and shows a exemplary implementation how to do
it (Sony was one of them). All other Decoders shows are more or less simply
understanding of the rules (what a shame).

How can we now change the V-Flag to "1"?
On the DVB card the job will be done by the TMS320AV7110 MPEG Decoder chip. It
delivers audio on a simple 16-bit PCM and our digital SPDIF interface. It works in
two audio modes:
- Normal operation: decode the Audio PES data (MPEG-Layer2)
- Bypass mode (direct pass through of memory 16-bit PCM data to audio output) - AC-3
mode

There is one control register (0) for muting audio output (bit 1). It seems to be
the only control feature. But i'm not sure that this flag modifies really the V-Flag
instead of disabling the complete audio stream output. Here we need more info from
the driver experts (Convergence).
If this bit is the way to do it, we have also to clarify how we can access this
control register. In principle the ARM processor manages all these control features
but the API allows to change these values through the ARM (e.g set bypass mode).
There is also a way to do it (in worst case - gdb).

I think we should solve this problem to be really compatible with all DD receiver.
I'll start investigation next week.

Wolfi




Home | Main Index | Thread Index