Re: Afatech AF9013 [TEST ONLY] AF9015 stream buffer size aligned with max packet size.

Commit Message

Malcolm Priestley Aug. 23, 2011, 9:43 p.m. UTC

On Tue, 2011-08-23 at 11:47 +1000, Jason Hecker wrote:
> Damn, this patch didn't help so maybe forget this patch.  Tuner A is
> still messed up.
Try this patch, applied to the latest media_build. it aligns buffer size to the max packet
size instead of TS packet size.

I think what might happening is that TS packets are getting chopped, as device seems to want
to align to max packet size.

Afatech seem to want create rather large buffers at considerable delay. The size of the buffer
has also been considerably reduced. If you want to increase it change TS_USB20_PACKET_COUNT
in multiplies of 2 (56 ... 112).

---
 drivers/media/dvb/dvb-usb/af9015.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

Comments

Jason Hecker Aug. 23, 2011, 10:29 p.m. UTC | #1

> I think what might happening is that TS packets are getting chopped, as device seems to want
> to align to max packet size.

Oh, I also noticed that the Linux driver uses a smaller USB packet
count than Windows.  Is there any discernible reason for this?  Lag on
DVB isn't an issue for me and probably everyone else due to the stream
going to secondary storage first.

Great, I'll try it out later.  I have been studying the source code
and noticed that the bus locking mechanism is TODOed and may be part
of the problem.  My symptom is that Tuner A fails when Tuner B is
started and I have a theory that somehow the TDA18271 is getting some
I2C data and being corrupted because of a gating problem with the I2C
signal.  The TDA18271 can change the last 2 bits of it's default I2C
address by setting a voltage on its AS pin (presumably with resistor
dividers) but I haven't delved in to determine if this what Leadtek
have done - both tuners might be set to address 0xC0.  I can only
truly test this by putting CRO probe on and seeing if the I2C is going
down the wrong path at the wrong time.

I just wish ITE/Afa would release their data sheet to the public and
make it as detailed and USEFUL as the TDA18271 data sheet.  This
obfuscation, need for NDAs and a half arsed data sheet and bloody
sniffing Windows USB transactions for programming clues is such a
waste of time and I fail to see how it benefits ITE to do this.  The
Afatech chips are 4+ years old anyway - what's the problem?  If anyone
wants to send me the data sheets and more importantly the DESIGN
MANUAL from the devkit I'd be most grateful.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index d7ad05f..eaf0800 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -404,21 +404,22 @@  static int af9015_init_endpoint(struct dvb_usb_device *d)
 	   We use smaller - about 1/4 from the original, 5 and 87. */
 #define TS_PACKET_SIZE            188
 
-#define TS_USB20_PACKET_COUNT      87
-#define TS_USB20_FRAME_SIZE       (TS_PACKET_SIZE*TS_USB20_PACKET_COUNT)
-
 #define TS_USB11_PACKET_COUNT       5
 #define TS_USB11_FRAME_SIZE       (TS_PACKET_SIZE*TS_USB11_PACKET_COUNT)
 
-#define TS_USB20_MAX_PACKET_SIZE  512
+#define TS_USB20_MAX_PACKET_SIZE  128
 #define TS_USB11_MAX_PACKET_SIZE   64
 
+#define TS_USB20_PACKET_COUNT      28
+#define TS_USB20_FRAME_SIZE       (TS_USB20_MAX_PACKET_SIZE\
+					*TS_USB20_PACKET_COUNT)
+
 	if (d->udev->speed == USB_SPEED_FULL) {
 		frame_size = TS_USB11_FRAME_SIZE/4;
 		packet_size = TS_USB11_MAX_PACKET_SIZE/4;
 	} else {
-		frame_size = TS_USB20_FRAME_SIZE/4;
-		packet_size = TS_USB20_MAX_PACKET_SIZE/4;
+		frame_size = TS_USB20_FRAME_SIZE;
+		packet_size = TS_USB20_MAX_PACKET_SIZE;
 	}
 
 	ret = af9015_set_reg_bit(d, 0xd507, 2); /* assert EP4 reset */