DVB-T with Cuse4BSD: bad signal quality

[Jan Henrik Sylvester]

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?

Cheers,
Jan Henrik

[Hans Petter Selasky]

Post by Jan Henrik Sylvester
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.

Fixed.

--HPS

[Hans Petter Selasky]

Post by Jan Henrik Sylvester
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

--HPS

[Jan Henrik Sylvester]

Post by Hans Petter Selasky

Post by Jan Henrik Sylvester
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

(I will not be able to answer anymore for a few hours.)

Cheers,
Jan Henrik

[Hans Petter Selasky]

Post by Jan Henrik Sylvester

Post by Hans Petter Selasky

Post by Jan Henrik Sylvester
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