DVB-T with Cuse4BSD: bad signal quality

[Hans Petter Selasky]

On Sunday 14 February 2010 15:12:03 Jan Henrik Sylvester wrote:
> On 02/14/2010 14:44, Hans Petter Selasky wrote:
> > On Sunday 14 February 2010 14:36:57 Jan Henrik Sylvester wrote:
> >> After I tried video4bsd last weekend for the first time and was able to
> >> make my webcam work, but not my DVB-T device. This weekend, I found
> >> Cuse4BSD on your homepage replacing video4bsd.
> >>
> >> Now my DVB-T stick basically work. Thanks a lot for all your effort!
> >>
> >> I wanted to complain about the firmware path being /, but since you
> >> added the '-f' switch that comes down to the rather unimportant default
> >> being / and not -- for example -- /boot/modules/. Having to call webcamd
> >> twice, once to load the firmware and once to actually do its job is a
> >> little counter intuitive.
> >>
> >> My major problem at the moment is the quality of the signal. That has
> >> always been dependent on the location of the antenna in my apartment,
> >> but I just tried Raaf's dvbusb driver under FreeBSD 7 without having any
> >> distortions and immediately booted back into FreeBSD 8: The distortions
> >> are so high that it is unwatchable and after a few seconds audio and
> >> video are out of sync using Raaf's typhony (Kaffeine seems a little
> >> better at keeping the streams at sync even with a bad signal).
> >>
> >> I already checked the system load on my atom based system: 15% user, 10%
> >> system, 70% idle (8% python, 8% mplayer, 4% webcamd) or 15% user, 20%
> >> system, 60% idle (20% kaffeine, 7% webcamd, 5% Xorg) -- that does not
> >> seem problematic. (I thought with the driver now partially in user space
> >> there might be higher load than before due to context switching.)
> >>
> >> I am currently on FreeBSD 8.0-RELEASE with the libusb patch you
> >> advertised last week on your homepage. I would not like to bring my atom
> >> based system to 8-STABLE or 9-CURRENT. Would that help?
> >>
> >> Any idea or fix for my distortions?
> >
> > It might be that the Linux driver is setting up to small buffers. I have
> > some patches for some of the V4L drivers, but not all. What is the
> > VID+PID of your device?
> >
> > usbconfig -u X -a Y dump_device_desc
> 
> ugen4.4: <Digital TV Receiver Digital TV Receiver> at usbus4, cfg=0
> md=HOST spd=HIGH (480Mbps) pwr=ON
> 
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0200
>    bDeviceClass = 0x0000
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0040
>    idVendor = 0x14aa
>    idProduct = 0x0226
>    bcdDevice = 0x0521
>    iManufacturer = 0x0001  <Digital TV Receiver>
>    iProduct = 0x0002  <Digital TV Receiver>
>    iSerialNumber = 0x0003  <20060503>
>    bNumConfigurations = 0x0001
> 

Hi,

It looks like this driver, linux/drivers/media/dvb/dvb-usb/dtt200u.c, uses 
BULK transfers. We would need to add some debug prints to the code to figure 
out what is going on.

Meanwhile, try to get your system to 8-STABLE. There are some libusb fixes in 
there, if you didn't install the latest version of libusb already.

--HPS