Bug 10036 - Using v4l and dvb simultaneously on saa7134 causes corruption
Summary: Using v4l and dvb simultaneously on saa7134 causes corruption
Status: REJECTED DOCUMENTED
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: saa7134 (show other bugs)
Hardware: All Linux
: P1 low
Assignee: v4l-dvb_saa7134@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-18 03:25 UTC by James Le Cuirot
Modified: 2009-03-24 04:46 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.26
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
mplayer screenshot (721.63 KB, image/png)
2008-02-19 13:41 UTC, James Le Cuirot
Details

Description James Le Cuirot 2008-02-18 03:25:54 UTC
Trying to use v4l and dvb at the same time on an saa7134 card doesn't work, or at least it doesn't on the FlyDVB-S LR300. I'm pretty sure this is a hardware limitation but the driver does not prevent it from being tried. On my old machine, it used to just cause a lot of green lines to appear over the v4l capture. On my new machine, it causes the system to lock up hard. Of course, there's no reason you'd want to try this if you know it doesn't work but I have done it by accident a few times because I usually have mythbackend running. It shouldn't be that easy to crash the machine, even if you are doing something stupid. (-;
Comment 1 Mauro Carvalho Chehab 2008-02-18 09:47:14 UTC
Could you please provide us the logs of the issue?
Comment 2 James Le Cuirot 2008-02-19 13:41:29 UTC
Created attachment 14905 [details]
mplayer screenshot

I just tried it again. It didn't crash this time so I've attached a screenshot, which shows the v4l capture corruption. If you actually try to view dvb at the same time (usually just running mythbackend is enough) then you get very heavy corruption of the MPEG stream as you might expect. Apart from mythfrontend complaining about the stream, there are no unusual log messages, even from the kernel. As far as the system is concerned, the card appears to be working normally, data corruption aside. Using v4l and dvb on this card at the same time simply needs to be prevented by the driver.

Just to clarify, I am not talking about two separate cards here, the FlyDVB-S LR300 is a combined v4l/dvb saa7134-based card.

You'll probably notice from the screenshot that I'm using fglrx. No point trying to hide it! I know I shouldn't be when reporting bugs here but the problem was just the same on my old machine, which didn't use any closed drivers.
Comment 3 Natalie Protasevich 2008-06-01 13:52:50 UTC
James, if the problem is still there, can you provide full traces from /var/log/messages or the like, and also while running open source drivers. It might be not possible to do any meaningful debugging with the binary driver involved.
Comment 4 James Le Cuirot 2008-07-17 06:58:56 UTC
I just tried it on vanilla Linux 2.6.26. I'm using the open ati/radeon Xorg driver (not radeonhd) at the moment. No closed drivers in the system at all. Yet again, there are no messages in the kernel or elsewhere, and as I explained above, this makes sense because the conflict is occuring within the hardware and not the driver. There is no mystery to solve here, you just need to ensure the DVB part of the card is blocked when the V4L part of the card is in use and vice-versa.
Comment 5 Stefan de Konink 2008-10-19 12:28:27 UTC
This might be the same origin of my problem. I am unable to unprobe the modules. When trying I get a load of 100. Usage of the analogue part or the digital part is something I didn't get to work yet.

saa7134 0000:01:06.0: PCI INT A -> Link[LNKA] -> GSI 18 (level, low) -> IRQ 18
saa7133[0]: found at 0000:01:06.0, rev: 209, irq: 18, latency: 64, mmio: 0xfebff
800
saa7133[0]: subsystem: 1131:2004, board: UNKNOWN/GENERIC [card=0,autodetected]
saa7133[0]: board init: gpio is 0
saa7133[0]: i2c eeprom 00: 31 11 04 20 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 b2 ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff 35 00 c0 96 10 03 32 21 05 ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0

Also the DVB devices are never created.
Comment 6 James Le Cuirot 2008-10-19 12:56:01 UTC
To be honest, that sounds totally unrelated. My card works fine, I'm just asking for the digital and analog parts of the card to block each other.
Comment 7 Stefan de Konink 2008-10-19 12:59:23 UTC
(In reply to comment #6)
> To be honest, that sounds totally unrelated. My card works fine, I'm just
> asking for the digital and analog parts of the card to block each other.

So in your case /dev/dvb/* is created?
Comment 8 James Le Cuirot 2008-10-19 13:02:01 UTC
Yes.
Comment 9 Hermann 2009-01-13 13:45:58 UTC
(In reply to comment #4)
> I just tried it on vanilla Linux 2.6.26. I'm using the open ati/radeon Xorg
> driver (not radeonhd) at the moment. No closed drivers in the system at all.
> Yet again, there are no messages in the kernel or elsewhere, and as I
> explained
> above, this makes sense because the conflict is occuring within the hardware
> and not the driver. There is no mystery to solve here, you just need to
> ensure
> the DVB part of the card is blocked when the V4L part of the card is in use
> and
> vice-versa.
> 

Yes, there is no proper locking between dvb and v4l yet.
It is most visible with shared hybrid tuners.

But this case here is indeed caused by a hardware limitation of the dma engines.
When the ts/mpeg interface is in use, only packed video formats can come through at once for analog video. The driver has no means yet to disallow planar formats on such cards and should at least print some warning.

Mplayer uses by default planar and you must change it, tvtime should work fine.
Comment 10 James Le Cuirot 2009-01-14 10:33:22 UTC
Are you saying that the card actually does allow both? Because I came across the box the other week and noticed that it does say something along the lines of "watch digital and analogue at the same time" but forgot to post about it. I'll give your suggestion a try soon. I may not use this card for very much longer though.
Comment 11 Stefan de Konink 2009-01-14 10:37:27 UTC
The box says "Picture in Picture".
Comment 12 Hermann 2009-01-15 13:10:21 UTC
(In reply to comment #10)
> Are you saying that the card actually does allow both? Because I came across
> the box the other week and noticed that it does say something along the lines
> of "watch digital and analogue at the same time" but forgot to post about it.
> I'll give your suggestion a try soon. I may not use this card for very much
> longer though.
> 

Yes, both at once, but only with packed video formats for analog.

DVB TransportStream and planar formats use the same DMA channel 5.
So this is not possible at once!

I use "kaffeine" for DVB-T and DVB-S and "tvtime" for analog tuners and external analog inputs on some triple saa7134 cards.

For mplayer and especially for mencoder it is important to change to a packed format like ":outfmt=yuy2"! Else you might get corrupted files with mencoder or even more trouble. You likely also need the saa7134-alsa module for dma sound.

If you want to watch DVB-T, DVB-S and analog video/TV at once, we support such cards on the saa7134 driver, you also need a graphics card driver, which supports multiple overlays. For multiple recordings and watch immediately at least one (xine?) it is not required.

You can test with something like that.

/usr/local/bin/mencoder -v tv:// -tv driver=v4l2:device=/dev/video0:input=1:width=640:height=480:chanlist=europe-west:alsa:adevice=hw.1,0:audiorate=32000:amode=1:forceaudio:volume=95:immediatemode=0:norm=PAL:outfmt=yuy2 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=3600 -vf pp=lb -oac mp3lame -lameopts cbr:br=128:mode=0 -o /mnt/non-root-partition/mytest.avi

You might adjust for your conditions, check the inputs printed by mencoder and those on cards with an extra tuner for analog should set the channel previously.
Comment 13 Alan 2009-03-24 04:46:42 UTC
Closing out stale bugs

Note You need to log in before you can comment on or make changes to this bug.