[vdr] Re: AC3 and receiver probs - latest findings

[Stefan.Hagendorn@lindy.cc]

Hi Uwe,

sorry to bother you, but if you have the equipment to analyze digital 
packets traveling over a digital connection, could you analyze a DTS 
signal and give as a clue how such "DTS-Data - embedded in - PCM" looks 
like ?!  It should be possible to send the stream as raw as possible and 
get the external receiver to decode it. The Goal is absolutly not to 
decode the stream an create multi channel output .. we are just looking 
for a way to send the data to the receiver.

Thanks
Stefan




"Uwe Weissbach" <uw@hfe.de>
Sent by: vdr-bounce@linuxtv.org
25.03.2002 12:26
Please respond to vdr

 
        To:     vdr@linuxtv.org
        cc: 
        Subject:        [vdr] AC3 and receiver probs - latest findings


two weeks ago I tried to explore the problems with
AC3 and some receivers:
http://www.linuxtv.org/mailinglists/vdr/2002/03-2002/msg01444.html
now I had compared the measurements with measurements from
data streams wich *accept* my receiver as correct AC3 streams
( from a commercial DVD player and from a Technisat receiver)
and the *only* significant difference I found is the second bit (bit 1)
of the channel status byte 0 (wich is set and means "no audio but
digital data"). 

The AC3 white paper 
(http://www.atsc.org/standards/a_52.pdf)
says in Annex B Chapter 5
----------
5. AUTO DETECTION OF AUDIO/DATA MODE
The IEC958 interface can convey either PCM audio, or data.
The receiver needs to know whether the IEC958 information
is to be considered PCM audio, or data. This information is best
conveyed by setting bit 1 of the channel status word to indicate data.
In some cases this bit may not be set correctly. 
In some applications it may be useful for receivers to be able to 
determine whether the IEC958 contents are PCM audio or data, 
without referring to bit 1 of the channel status word. 
This may be done quite reliably by recognizing that the 32-bit sync 
code formed by the first two 16-bit words of the preamble....(cont.)
---------------

so I suppose some receivers do this auto detection 
and others does'nt...
The goal is therefore to set this bit correctly.
until yesterday I had in my mind Technotrend's card
can't set this bit because of the hardware so I don't 
explore it furthermore, but in meantime i found in 
the TMS320AV7110 tech spec
http://www.linuxdvb.tv/documentation/AV711x_3_1.pdf
chapter 10 wich wrotes about the user API and (esp.
on 10.5 the possibility to changing the validation bit
to mute audio during sample frequency changes)
This validation bit *is* IMHO the bit we need, because
there is no other bit in the status byte wich can do that.
Maybe it depends on bit 1 in Register 0 of the audio module
register, described in the same chapter.

I'm not a api- or driver hacker so eventually the guys from
Convergence can have a look of it or (better) have already
made it possible to set/reset this status bit in the linux driver, 
and give us the opportunity to create a standard conform AC3 
data stream wich is valid for all receivers.

any help/suggestions are welcome...

--

Uwe Weissbach

Don't flame in public ... please 
use my PM address and use 
subject: goto dev/null