[linux-dvb] Re: Pinnacle PCTV

[peter.hettkamp@t-online.de (Peter Hettkamp)]

Hello Michael,

On Fri, Aug 30, 2002 at 11:19:49AM +0200, Michael Rickmann wrote:
> Hello Peter,
> 
...
> 
> I can watch TV with only a few noticeable glitches, so the PCTV-Sat driver is 
> working mostly fine. My problem started when I tried to edit a recorded mpeg 
> file. Running the file through pvastrumento (under wine) shows quite a number 
> of missing audio and video bits. When I tried to find out where parts of the 
> stream were lost I stumbled about the writebuf inconsistency. And my real 
> problem now is understanding linux kernel sources. However, I understood the 
> concept of tasklets and how you applied it.
Just a quick estimation: Symbol rate from the satellite is 27.5MS/s, a
symbol delivers 2 bits, 3/4 of the bits are information bits (code rate
3/4), for every 188 Bytes of information there are additional 16 bytes of RS
parity. so the information data rate is ~38MBit/s or 4.75MByte/s. Each
buffer is 8*0xc00 (=24k) bytes in size, it fills in 5.17msec, or approx.
193 per second. Thus, the interrupt rate is not extraordinarily high.
 
> 
> 06:09:24  kernel: pctv debug: tasklet: writebuf 3, expected 0, read 2
> 06:09:24  kernel: pctv debug: tasklet: writebuf 1, expected 0, read 3
The writebuf number is generally determined through the bt878 dma hardware.
Each bt878 dma processor command contains a field to set/reset four special
status bits. I coded the commands so that any command transferring data to
buffer n sets these status bits to n. Whenever the buffer number changes, an
interrupt is triggered. The ISR in turn simply copies these bits from the
status register to the writebuf variable. Thus, if the wrbuf numbers in the
ISR are not in sequence, either my assumptions about the timing
relationships in the hardware are wrong, or your system may suffer from long
interrupt latencies. If they are in sequence in the ISR but skipping numbers
in the tasklet only, the tasklet code should be able to handle it (1 skipped
buffer, that is).

> 06:09:29  kernel: pctv debug: tasklet: writebuf 0, expected 3, read 1
> 06:09:29  kernel: bt848 debug: writebuf 0, expected 3
> 06:09:29  kernel: bt848 debug: writebuf 1, expected 0
Where are these debug messages signalled?

> 06:09:39  kernel: pctv: panic, less than 188 Bytes left and no sync. Program 
> me!
The (re-)synchronization code is not in a very good shape currently. In
order to avoid falling for a 0x47 within the data stream, it wants to make
sure there is another one exactly one TS_SIZE beyond. This is made more
difficult by crossing buffer borders, and the buffer wraparound location.
It also contains an error which may trigger a kernel oops.
This message, however, is just a placeholder for a piece if synchronization
code I never wrote.

> Data rate during this recording was about 585 kbyte/sec.
> Note the 33 sec in the beginning which are apprently error free.
> If I had not stopped the recording it would have shown the same kind of 
> messages at a cycle of about 5 sec.
I have no idea why this happens.

> 
> When I have the tasklet return immediately before entering the spinlock or 
> even when I outcomment only the three DvbDmxSWFilterPackets feedings 
> everything seems ok also the finding of syncs:
...
> with a little increase in verbosity and counting done directly before the sync 
> check. Could be the culprit is hidden somewhere beyond "dvb_demux.c".
dvb_demux and everything else concerning demuxing was taken unaltered from
the standard dvb driver. I did not even look into this code. Maybe you can
try to replace these files with those from the standard driver, on the
assumption that they have been improved since I copied them into the
experimental-pinnacle branch?

> I think that there is a problem when you wish to have a rather clean stream.
> Maybe my writebuf inconsistency is related to the Oopses you found and posted 
> earlier.
Probably not. The resynching code does not work as good as planned, an has a
border condition where it can create an oops, but it should not give rise to
a loss of sync in the first place.

By the way, I have been watching BBC from Hotbird while typing this
response. I did not notice any glitches, except mplayer lost A/V sync once.
But then, my system is pretty fast.
There is one person using my driver and mplayer on a ~300MHz system
successfully, but I think his tolerance level for glitches/losses may be
somewhat higher.

>  Regards
>  Michael Rickmann

Regards,
Peter
-- 
"Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)"
(Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi)


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.