Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi Matthieu, I committed a modification to finally fix it. regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ On Sun, 20 Aug 2006, matthieu castet wrote: Patrick Boettcher wrote: Hi Matthieu, I added something to my repository which should fix it: Can you give it a try: http://linuxtv.org/hg/~pb/v4l-dvb The patch doesn't work : in OUTMODE_MPEG2_FIFO you still erase the pid parse bit. Here a patch that works. Unfortunately on french tnt, the bandwidth share on a transponder is not usb1 friendly : - the transponder bandwidth is 24 Mbps - there are 5 or 6 channels per transponder (it make an average 4Mbps bandwidth) Instead of having all channel near the average 4Mbps, they put the average lower (2.5-3 Mbps) and the extra bandwidth is given (sometimes randomly) to some channels. This make peak 7 Mbps on some channels [1] and usb1 mode doesn't seem to support such bandwidth (may be if iso were used, it could have worked). Some transponder are more usb1 friendly and put the extra bits in pid 8191 (up to 4-5 Mbps)... [1] -PID--FREQ-BANDWIDTH-BANDWIDTH- 9 p/s 1 kb/s14 kbit 0017 0 p/s 0 kb/s 1 kbit 001810 p/s 1 kb/s16 kbit 0021 1 p/s 0 kb/s 2 kbit 0110 9 p/s 1 kb/s14 kbit 0120 2156 p/s 395 kb/s 3242 kbit 0130 132 p/s24 kb/s 198 kbit 0140 2 p/s 0 kb/s 4 kbit 0210 9 p/s 1 kb/s14 kbit 0220 2992 p/s 549 kb/s 4499 kbit 0230 131 p/s24 kb/s 197 kbit 0240 1 p/s 0 kb/s 2 kbit 0310 9 p/s 1 kb/s14 kbit 0320 4785 p/s 878 kb/s 7197 kbit 0330 131 p/s24 kb/s 197 kbit 0340 2 p/s 0 kb/s 4 kbit 0410 9 p/s 1 kb/s14 kbit 0420 1458 p/s 267 kb/s 2193 kbit 0430 132 p/s24 kb/s 198 kbit 0440 2 p/s 0 kb/s 4 kbit 0510 9 p/s 1 kb/s14 kbit 0520 1743 p/s 320 kb/s 2622 kbit 0530 132 p/s24 kb/s 198 kbit 0531 132 p/s24 kb/s 198 kbit 0541 2 p/s 0 kb/s 4 kbit 0542 3 p/s 0 kb/s 5 kbit 0610 9 p/s 1 kb/s14 kbit 0620 1419 p/s 260 kb/s 2134 kbit 0630 132 p/s24 kb/s 198 kbit 0640 1 p/s 0 kb/s 2 kbit 0660 8 p/s 1 kb/s13 kbit 1010 9 p/s 1 kb/s14 kbit 8191 926 p/s 170 kb/s 1393 kbit 8192 16540 p/s 3036 kb/s 24877 kbit Signed-off-by: Matthieu CASTET [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Patrick Boettcher wrote: Hi Matthieu, I committed a modification to finally fix it. Thanks, but with our fix does other modes will still works : you don't set anymore bit 1 ? Do you think there is a way to better handle hight bandwidth stream (usb urb tunning, some register tunning) or it is hopeless with usb1 ? Matthieu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi Patrick, Patrick Boettcher wrote: Hi Matthieu, I added something to my repository which should fix it: Can you give it a try: http://linuxtv.org/hg/~pb/v4l-dvb The patch doesn't work : in OUTMODE_MPEG2_FIFO you still erase the pid parse bit. Here a patch that works. Unfortunately on french tnt, the bandwidth share on a transponder is not usb1 friendly : - the transponder bandwidth is 24 Mbps - there are 5 or 6 channels per transponder (it make an average 4Mbps bandwidth) Instead of having all channel near the average 4Mbps, they put the average lower (2.5-3 Mbps) and the extra bandwidth is given (sometimes randomly) to some channels. This make peak 7 Mbps on some channels [1] and usb1 mode doesn't seem to support such bandwidth (may be if iso were used, it could have worked). Some transponder are more usb1 friendly and put the extra bits in pid 8191 (up to 4-5 Mbps)... [1] -PID--FREQ-BANDWIDTH-BANDWIDTH- 9 p/s 1 kb/s14 kbit 0017 0 p/s 0 kb/s 1 kbit 001810 p/s 1 kb/s16 kbit 0021 1 p/s 0 kb/s 2 kbit 0110 9 p/s 1 kb/s14 kbit 0120 2156 p/s 395 kb/s 3242 kbit 0130 132 p/s24 kb/s 198 kbit 0140 2 p/s 0 kb/s 4 kbit 0210 9 p/s 1 kb/s14 kbit 0220 2992 p/s 549 kb/s 4499 kbit 0230 131 p/s24 kb/s 197 kbit 0240 1 p/s 0 kb/s 2 kbit 0310 9 p/s 1 kb/s14 kbit 0320 4785 p/s 878 kb/s 7197 kbit 0330 131 p/s24 kb/s 197 kbit 0340 2 p/s 0 kb/s 4 kbit 0410 9 p/s 1 kb/s14 kbit 0420 1458 p/s 267 kb/s 2193 kbit 0430 132 p/s24 kb/s 198 kbit 0440 2 p/s 0 kb/s 4 kbit 0510 9 p/s 1 kb/s14 kbit 0520 1743 p/s 320 kb/s 2622 kbit 0530 132 p/s24 kb/s 198 kbit 0531 132 p/s24 kb/s 198 kbit 0541 2 p/s 0 kb/s 4 kbit 0542 3 p/s 0 kb/s 5 kbit 0610 9 p/s 1 kb/s14 kbit 0620 1419 p/s 260 kb/s 2134 kbit 0630 132 p/s24 kb/s 198 kbit 0640 1 p/s 0 kb/s 2 kbit 0660 8 p/s 1 kb/s13 kbit 1010 9 p/s 1 kb/s14 kbit 8191 926 p/s 170 kb/s 1393 kbit 8192 16540 p/s 3036 kb/s 24877 kbit Signed-off-by: Matthieu CASTET [EMAIL PROTECTED] --- dib3000mc.c 2006-08-20 12:57:32.0 +0200 +++ dib3000mc.c 2006-08-20 12:59:32.0 +0200 @@ -193,8 +193,7 @@ u16 outreg = 0; u16 outmode = 0; u16 elecout = 1; - u16 smo_reg = (0 6) | (0 5) | (0 3) | (1 1) | 0 | - (dib3000mc_read_word(state, 206) 0x0010); /* keep the pid_parse bit */ + u16 smo_reg = (0 6) | (0 5) | (0 3) | (1 1) | 0; dprintk(-I- Setting output mode for demod %p to %d\n, state-demod, mode); @@ -239,6 +238,9 @@ if ((state-cfg-output_mpeg2_in_188_bytes)) smo_reg |= (1 5); // P_smo_rs_discard [1;5:5] = 1 + /* keep the pid_parse bit */ + smo_reg |= dib3000mc_read_word(state, 206) (14); + outreg = dib3000mc_read_word(state, 244) 0x07FF; outreg |= (outmode 11); ret |= dib3000mc_write_word(state, 244, outreg); ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi Matthieu,
I added something to my repository which should fix it:
Can you give it a try:
http://linuxtv.org/hg/~pb/v4l-dvb
Thanks for finding the problem,
Patrick.
--
Mail: [EMAIL PROTECTED]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
On Fri, 18 Aug 2006, matthieu castet wrote:
Hi,
Patrick Boettcher wrote:
Hi,
On Thu, 17 Aug 2006, matthieu castet wrote:
Are you running on USB2.0?
No usb1.1
On usb2.0 it seems to work (but the configuration is a bit different).
Is there a way to check if the usb bandwidht don't overflow because of
bad
filtering ?
So OK, it is definitely only the PID filter functionality somewhere. It can
be the dib3000mc or the use of the interface.
It will only be a small fix and there is only a few people having only
USB1.1. It is save to merge it into mainline and then send a patch for
fixing later.
How are you coding abilities? Can you check if dib3000mc_pid_parse is called
with onoff 1 and if the bit is set correcly by reading it back.
Yes it is set correctly, but look what you do in dib3000mc_set_output_mode :
case OUTMODE_MPEG2_FIFO:// e.g. USB feeding
elecout = 3;
/*ADDR @ 206 :
P_smo_error_discard [1;6:6] = 0
P_smo_rs_discard [1;5:5] = 0
P_smo_pid_parse [1;4:4] = 0
ooppps we don't whant
to touch this one : it is set by dib3000mc_pid_parse.
P_smo_fifo_flush [1;3:3] = 0
P_smo_mode [2;2:1] = 11
P_smo_ovf_prot [1;0:0] = 0
*/
smo_reg = (0 6) | (0 5) | (0 4) | (0
3) |(3 1) | 0;
fifo_threshold = 512;
outmode = 5;
break;
If I put smo_reg = (0 6) | (0 5) | (1 4) | (0 3) |(3 1) | 0;
it works :)
There is 2 solutions to solve the problem :
- smo_reg is only set at init time
- we don't touch bit 4 in dib3000mc_set_output_mode
Matthieu
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi, On Thu, 17 Aug 2006, matthieu castet wrote: Are you running on USB2.0? No usb1.1 On usb2.0 it seems to work (but the configuration is a bit different). Is there a way to check if the usb bandwidht don't overflow because of bad filtering ? So OK, it is definitely only the PID filter functionality somewhere. It can be the dib3000mc or the use of the interface. It will only be a small fix and there is only a few people having only USB1.1. It is save to merge it into mainline and then send a patch for fixing later. How are you coding abilities? Can you check if dib3000mc_pid_parse is called with onoff 1 and if the bit is set correcly by reading it back. Using dvbtraffic shows that there no filtering on usb1.1 (I got more than 800 pids) : that should be my problem :) Those 800 pids are misassumptions due to broken buffers. I saw that the video pid take lot's of bandwidht (that's normal), but the pid 2000 takes also the same amount of bandwidht. Do you know what it is (from google it seems the transponder pid) and why it is needed ? When the video bandwidht is hight ( ~7 Mbps) I saw some artefacts, may be it is because video pid + 0x2000 pids bandwidht usb bandwidht. It seems pid 0x2000 is the total under dvbtraffic... Exactly. thanks, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi, Patrick Boettcher wrote: Hi, On Thu, 17 Aug 2006, matthieu castet wrote: Are you running on USB2.0? No usb1.1 On usb2.0 it seems to work (but the configuration is a bit different). Is there a way to check if the usb bandwidht don't overflow because of bad filtering ? So OK, it is definitely only the PID filter functionality somewhere. It can be the dib3000mc or the use of the interface. It will only be a small fix and there is only a few people having only USB1.1. It is save to merge it into mainline and then send a patch for fixing later. How are you coding abilities? Can you check if dib3000mc_pid_parse is called with onoff 1 and if the bit is set correcly by reading it back. Yes it is set correctly, but look what you do in dib3000mc_set_output_mode : case OUTMODE_MPEG2_FIFO:// e.g. USB feeding elecout = 3; /*ADDR @ 206 : P_smo_error_discard [1;6:6] = 0 P_smo_rs_discard [1;5:5] = 0 P_smo_pid_parse [1;4:4] = 0 ooppps we don't whant to touch this one : it is set by dib3000mc_pid_parse. P_smo_fifo_flush [1;3:3] = 0 P_smo_mode [2;2:1] = 11 P_smo_ovf_prot [1;0:0] = 0 */ smo_reg = (0 6) | (0 5) | (0 4) | (0 3) |(3 1) | 0; fifo_threshold = 512; outmode = 5; break; If I put smo_reg = (0 6) | (0 5) | (1 4) | (0 3) |(3 1) | 0; it works :) There is 2 solutions to solve the problem : - smo_reg is only set at init time - we don't touch bit 4 in dib3000mc_set_output_mode Matthieu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi, On Wed, 16 Aug 2006, matthieu castet wrote: I found a bug in the mt2060, the VGAG wasn't set to a correct level. Now I get the signal level from the old driver, but there still no picture... The rate of the dvb stream reported by femon (from vdr is very low) : 0.5 Mb/s instead of 5 Mb/s. Any news on that ? I have no idea what can cause this. What happens when you use just dvbscan + tzap + mplayer. The new driver is broken for me (no picture, no autosearch) while the old driver was working. Are you running on USB2.0? The autosearch problem is indeed a problem, but I'm not sure when I have time to reproduce and fix that. The new driver is now integrated in the hg repo, but it seems a big regression for configuration like mine (ok there weren't mt2060 support, but it could have been added without rewriting the driver). Shouldn't we have to wait a new driver with no regression before merging it ? Yes. I hope it will be fixed before it hits linus git repo. best regards, Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi Patrick, Patrick Boettcher wrote: Hi, On Wed, 16 Aug 2006, matthieu castet wrote: I found a bug in the mt2060, the VGAG wasn't set to a correct level. Now I get the signal level from the old driver, but there still no picture... The rate of the dvb stream reported by femon (from vdr is very low) : 0.5 Mb/s instead of 5 Mb/s. Any news on that ? I have no idea what can cause this. What happens when you use just dvbscan + tzap + mplayer. The new driver is broken for me (no picture, no autosearch) while the old driver was working. thanks for your reply. Are you running on USB2.0? No usb1.1 On usb2.0 it seems to work (but the configuration is a bit different). Is there a way to check if the usb bandwidht don't overflow because of bad filtering ? Using dvbtraffic shows that there no filtering on usb1.1 (I got more than 800 pids) : that should be my problem :) I saw that the video pid take lot's of bandwidht (that's normal), but the pid 2000 takes also the same amount of bandwidht. Do you know what it is (from google it seems the transponder pid) and why it is needed ? When the video bandwidht is hight ( ~7 Mbps) I saw some artefacts, may be it is because video pid + 0x2000 pids bandwidht usb bandwidht. Matthieu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
matthieu castet wrote: Hi Patrick, Patrick Boettcher wrote: Hi, On Wed, 16 Aug 2006, matthieu castet wrote: I found a bug in the mt2060, the VGAG wasn't set to a correct level. Now I get the signal level from the old driver, but there still no picture... The rate of the dvb stream reported by femon (from vdr is very low) : 0.5 Mb/s instead of 5 Mb/s. Any news on that ? I have no idea what can cause this. What happens when you use just dvbscan + tzap + mplayer. The new driver is broken for me (no picture, no autosearch) while the old driver was working. thanks for your reply. Are you running on USB2.0? No usb1.1 On usb2.0 it seems to work (but the configuration is a bit different). Is there a way to check if the usb bandwidht don't overflow because of bad filtering ? Using dvbtraffic shows that there no filtering on usb1.1 (I got more than 800 pids) : that should be my problem :) I saw that the video pid take lot's of bandwidht (that's normal), but the pid 2000 takes also the same amount of bandwidht. Do you know what it is (from google it seems the transponder pid) and why it is needed ? When the video bandwidht is hight ( ~7 Mbps) I saw some artefacts, may be it is because video pid + 0x2000 pids bandwidht usb bandwidht. It seems pid 0x2000 is the total under dvbtraffic... ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DiB3000MC rewritten and MT2060 is ready to go into main
Hi, matthieu castet wrote: matthieu castet wrote: [EMAIL PROTECTED] wrote: Hi, Selon Patrick Boettcher [EMAIL PROTECTED]: Might be a mistake: Do you say that when you convert the data from the old buffer to the new agc-structure it works better? Otherwise I don't see why it changed. I didn't try that yet. I wanted first to know your opinion on it. I will try it this evening. No it still doesn't help :( As I don't have a datasheet nor a knowlege of the driver, I don't know what to try. With your mt2060 dongle, don't you see a signal strength loose between old driver (with patched signal strength report) and new driver ? Can't you attenuate your reception quality in order to check if you see the same behaviour ? I found a bug in the mt2060, the VGAG wasn't set to a correct level. Now I get the signal level from the old driver, but there still no picture... The rate of the dvb stream reported by femon (from vdr is very low) : 0.5 Mb/s instead of 5 Mb/s. Any news on that ? The new driver is broken for me (no picture, no autosearch) while the old driver was working. The new driver is now integrated in the hg repo, but it seems a big regression for configuration like mine (ok there weren't mt2060 support, but it could have been added without rewriting the driver). Shouldn't we have to wait a new driver with no regression before merging it ? I hope it will be fixed before it hits linus git repo. Matthieu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
