[linux-dvb] Re: Pinnacle PCTV

[Michael Rickmann <mrickma@gwdg.de>]

Hello Peter,

> The problem you describe next, does it give you problems while viewing DVB
> video, or is this a question of general interest?
>
> > For me the value in bt->writebuf as it is given to the tasklet appears
> > not very reliable. When I insert something like

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.

> > into the tasklet everything looks fine for the first 30 to 45 sec. But
> > then things become congested somehow and I get discontinuities in the
> > writebuf, mostly by 1. This is independent from the kind of spinlocks. I
> > use dvbstream to write to a file or to /dev/nul.

Let me illustrate this. Sorry for the length of the following kernel logs. I 
have shortened the lines to make them more readable on the mailing list.

:~/source/DVB-cvsexpi/driver # ./ins

......
06:08:40  kernel: i2c-core.o: client [cx24110] registered to adapter [bt848 
#0](pos. 0).
06:08:40  kernel: cx24110: attaching cx24106 at 0x55 to adapter bt848 #0
06:08:40  kernel: bt878: AUDIO driver version 0.0.0 loaded
06:08:40  kernel: bt878: Bt878 AUDIO function found (0).
06:08:40  kernel: PCI: Found IRQ 5 for device 00:0b.1
06:08:40  kernel: PCI: Sharing IRQ 5 with 00:07.2
06:08:40  kernel: PCI: Sharing IRQ 5 with 00:0b.0
06:08:40  kernel: bt878(0): Bt878 (rev 17) at 00:0b.1, irq: 5, latency: 32, 
memory: 0xda007000
06:08:40  kernel: bt878 debug: bt878_get_buffers(d8a3b3a0, bpl=0xc00, lpf=0x8, 
n=0x4
06:08:40  kernel: dvb: 1 dvb(s) found!

:~/source/DVB-cvsexpi/driver # dvbstream -o -d 1 -ps -f 12596 -p v  -s 27500 
163 92 > $HOME/test.mpg
That is BBC-World somewhere on Hotbird,  for me diseqc 1.

06:08:51  kernel: bttv0: IRQ lockup, cleared int mask
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
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
06:09:29  kernel: pctv debug: tasklet: writebuf 1, expected 2, read 0
06:09:34  kernel: bt848 debug: writebuf 1, expected 0
06:09:34  kernel: pctv debug: tasklet: writebuf 2, expected 3, read 1
06:09:34  kernel: pctv debug: tasklet: writebuf 0, expected 3, read 2
06:09:34  kernel: pctv debug: tasklet: writebuf 2, expected 1, read 0
06:09:34  kernel: bt848 debug: writebuf 1, expected 0
06:09:34  kernel: bt848 debug: writebuf 2, expected 1
06:09:34  kernel: pctv debug: tasklet: writebuf 2, expected 3, read 2
06:09:39  kernel: bt848 debug: writebuf 3, expected 2
06:09:39  kernel: bt848 debug: writebuf 2, expected 1
06:09:39  kernel: bt848 debug: writebuf 1, expected 0
06:09:39  kernel: pctv: panic, less than 188 Bytes left and no sync. Program 
me!
06:09:39  kernel: pctv: panic, less than 188 Bytes left and no sync. Program 
me!
06:09:39  kernel: pctv debug: tasklet: writebuf 0, expected 3, read 1
......

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.

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:

07:26:43  kernel: bttv0: IRQ lockup, cleared int mask
07:26:43  kernel: function : BtStart
07:26:43  kernel: pctv debug: tasklet: no do r=0, w=0
07:26:43  kernel: function : BtStart
07:27:05  kernel: pctv debug: tasklet called 4096 times
07:27:26  kernel: pctv debug: tasklet called 8192 times
07:27:47  kernel: pctv debug: tasklet called 12288 times
07:28:08  kernel: pctv debug: tasklet called 16384 times
07:28:26  kernel: via82cxxx: timeout while reading AC97 codec (0x9A0000)
07:28:29  kernel: pctv debug: tasklet called 20480 times
07:28:50  kernel: pctv debug: tasklet called 24576 times
07:29:12  kernel: pctv debug: tasklet called 28672 times
07:29:33  kernel: pctv debug: tasklet called 32768 times
07:29:54  kernel: pctv debug: tasklet called 36864 times
07:30:15  kernel: pctv debug: tasklet called 40960 times
07:30:35  kernel: function : BtStop

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".

> If it does not create a problem, it is a feature, decoupling the software
> demuxer from the ISR. If it does, it is probably as bug.

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.
 Regards
 Michael Rickmann



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