BATC Forum

Dear forum,

Several, if not most, FM ATV repeaters in NL use, in addition to 2 (or more) FM audio carriers, a Nicam sub-carrier for hi-fi stereo sound.
So does PI6ALK.
At PI6ALK vision and sound quality is one of the main drivers, as well as cross-band full-duplex operations with multiple users. (Typical operation looks like a video conference. At busy times people compare it to a cafe.)
At PI6ALK we are currently contemplating a move to DATV, but most users, although interested in technical progress (e.g. HD), expressed their concern with the latency in the audio that comes with the 'traditional' DATV implementations. Video latency and lack of lip-sync is considered not a big issue, but >500ms delay (Tx+Rx) in audio is expected to kill interactive discussions.

So, the challenge is to devise and implement a DATV mode that provides the best of both worlds; HDTV and zero-latency hi-fi audio. There are a few boundaries to an implementation:
- reasonably easy to build/implement Rx for users of PI6ALK (and users of other repeaters that might wish to follow this route)
- not require more RF bandwidth than the currently occupied 27 MHz
- not require more RF Tx power (We realize that a digital solution will require a higher power PA (in back-off), or some kind of linearization scheme, which is fine)

Current, fully untested, ideas are:
1. to include Nicam bits in the transport stream and somehow get them out at the Rx-end to be decoded in a Nicam decoder chip or a dedicated DSP.
2. to add a NIcam subcarrier to the DVB-S(2) TX signal and Rx-ed like a normal FM-ATV signal with Nicam sub-carrier

Any more from you forum readers?

Regards,
Herman, PE1GTA/PI6ALK

As I understand, you prefere to have a very short audio latency even not lipsinked (means audio coming before video).
About latency in general, in DATV and paricularly with high bitrate latency should be around 100ms for audio and video. There is of course some tweaks to use for very low latency in H264 parameters (decreasing a litlle video quality).

73's Evariste F5OEO

I proposed a similar system called 'Fast Audio' in my CAT15 talk https://www.youtube.com/watch?v=3cnKtctquAQ about 23 minutes in. The problem is that every part of the system wants to buffer and it all adds up.

The receive end of the process is the easier. Now that we have the MiniTiouner, the parallel transport stream is available as it comes out of the receiver module (NIM) with no buffering. A processor (without an operating system) could monitor the transport stream and process the packets that have fast audio in them and send the audio directly to a speaker.

The transmit end is more difficult. There needs to be a similar type of processor to the one at the receive end, that digitises the audio and inserts the packets into the transport stream. This processor needs to be able to get at the transport stream before the DVB-S error correction steps have been applied and then either apply the error correction itself, or pass the transport stream on to a device that can.

The transport stream must have dummy packets in, so that the transmit processor can replace them with the fast audio packets. It may be possible to use padding packets, if there are enough of them. Extra packets cannot be inserted, as that would cause the PCR timing data in the transport stream to be incorrect.

If the repeater also has digital inputs, then the repeater and the user need both the fast audio processors. The repeater needs to be effectively a network packet switcher, transmitting packets from users or inserting test card packets.

Would you want to continue to use NICAM? With so much data bandwidth available, you could sample the audio at 16 bit, 32/44.1/48k samples/second.

Brian

Evariste, you think an overall delay (encoding + decoding) can be less than 100 ms? One frame is already 40 ms, 100ms hardly leaves room for temporal compression. If possible (2-3 frame gops), does this not increase bit-rate a lot?

Brian, I watched your CAT15 video. Much aligned with the idea of treating audio as a bit stream separate from the video. Needs some better understanding of TS multiplexing and some experimenting on this end.
Indeed Nicam with its 728kbits/s is rather 'expensive' in bandwidth. We are just so used to and fond of it that we weren't even thinking of straight PCM. Which at 44kbs sampling, 2x16 bits, still requires 1.4Mbs, but benefits from DVB-S TS error correction and would be dead-easy to DA convert at the Rx end when extracted from the the TS.

Just thought of how the audio in a MPEG-2 transport stream is 'synchronized' with the video. Would it not be possible in the encoder to give the audio time stamps a negative (positive) offset wrt the video to make the receiver deliver it prior to the video?

Herman.

A transport stream is effectively lots of separate streams mixed together, with the packets for each particular stream being identified by a PID (packet ID).

You could use the raw NICAM sampling rate of 14 bits at 32kHz to give 896kps to reduce the bit rate.

A transport stream has a 'master clock on the wall', the PCR, that other times in the stream are relative to. Each bit of data has a PTS (presentation time stamp) that tells the receiver at what time to send it to the video or audio output. I looked at the PVR-150 MPEG-2 capture card data to see if I could manipulate the PTS for the audio and make the receiver output it earlier, but it still wasn't available from the PVR-150 early enough. The receiver would still want to do some buffering of it, so that would degrade the real-time requirement.

Brian