linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* TT-USB2.0 and high bitrate packet loss (DVB-C/T)
@ 2013-05-30  8:00 Hans Petter Selasky
  2013-06-02 12:19 ` Hans Petter Selasky
  0 siblings, 1 reply; 4+ messages in thread
From: Hans Petter Selasky @ 2013-05-30  8:00 UTC (permalink / raw)
  To: linux-media, Juergen Lock

Hi there,

I need to get in concat with someone that can handle, test and review a 
patch for TT-USB2.0. I've found that for certain high-bitrate streams, 
the TT-USB2.0 sends more ISOCHRONOUS MPEG data than is specified in the 
wMaxPacketSize fields. I have a USB analyzer capture which shows this 
clearly. This of course won't be received at the USB host and packet 
drops appear inside the stream. The solution is to use another alternate 
setting. The technotrend chip has many of these. I've now tested using 
alternate setting 7 instead of 3.

Alternate setting 7 allows transferring a maximum of 3 * 1024 bytes.
Alternate setting 3 allows transferring a maximum of 1 * 940 bytes.

--HPS

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: TT-USB2.0 and high bitrate packet loss (DVB-C/T)
  2013-05-30  8:00 TT-USB2.0 and high bitrate packet loss (DVB-C/T) Hans Petter Selasky
@ 2013-06-02 12:19 ` Hans Petter Selasky
  2013-06-02 21:02   ` Antti Palosaari
  0 siblings, 1 reply; 4+ messages in thread
From: Hans Petter Selasky @ 2013-06-02 12:19 UTC (permalink / raw)
  Cc: linux-media, Juergen Lock

On 05/30/13 10:00, Hans Petter Selasky wrote:
> Hi there,
>
> I need to get in concat with someone that can handle, test and review a
> patch for TT-USB2.0. I've found that for certain high-bitrate streams,
> the TT-USB2.0 sends more ISOCHRONOUS MPEG data than is specified in the
> wMaxPacketSize fields. I have a USB analyzer capture which shows this
> clearly. This of course won't be received at the USB host and packet
> drops appear inside the stream. The solution is to use another alternate
> setting. The technotrend chip has many of these. I've now tested using
> alternate setting 7 instead of 3.
>
> Alternate setting 7 allows transferring a maximum of 3 * 1024 bytes.
> Alternate setting 3 allows transferring a maximum of 1 * 940 bytes.
>
> --HPS

Hi,

It turns out that this device, at least the version I bought, does not 
work with the XHCI at all when using multi-packet transfers, alternate 
setting 7, because DATA2 PID is used when transfer is less than 1024 
bytes. It should be DATA0 PID first, then 1 and 2 in the end. Probably a 
firmware update can fix this, but I'm not aware about if such exists. 
The PID issue was found using a USB analyzer.

Apparently this bug has gone undetected, because at least the EHCI high 
speed only controller I've got silently ignores this kind of errors and 
receives the data whilst the XHCI not. Conclusion:
Existing alternate setting must be used.

I think I will have to get another USB based receiver with CI slot. Any 
recommendations for DVB-T ?

--HPS


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: TT-USB2.0 and high bitrate packet loss (DVB-C/T)
  2013-06-02 12:19 ` Hans Petter Selasky
@ 2013-06-02 21:02   ` Antti Palosaari
  2013-06-05  1:34     ` Antti Palosaari
  0 siblings, 1 reply; 4+ messages in thread
From: Antti Palosaari @ 2013-06-02 21:02 UTC (permalink / raw)
  To: Hans Petter Selasky

On 06/02/2013 03:19 PM, Hans Petter Selasky wrote:
> On 05/30/13 10:00, Hans Petter Selasky wrote:
>> Hi there,
>>
>> I need to get in concat with someone that can handle, test and review a
>> patch for TT-USB2.0. I've found that for certain high-bitrate streams,
>> the TT-USB2.0 sends more ISOCHRONOUS MPEG data than is specified in the
>> wMaxPacketSize fields. I have a USB analyzer capture which shows this
>> clearly. This of course won't be received at the USB host and packet
>> drops appear inside the stream. The solution is to use another alternate
>> setting. The technotrend chip has many of these. I've now tested using
>> alternate setting 7 instead of 3.
>>
>> Alternate setting 7 allows transferring a maximum of 3 * 1024 bytes.
>> Alternate setting 3 allows transferring a maximum of 1 * 940 bytes.
>>
>> --HPS
>
> Hi,
>
> It turns out that this device, at least the version I bought, does not
> work with the XHCI at all when using multi-packet transfers, alternate
> setting 7, because DATA2 PID is used when transfer is less than 1024
> bytes. It should be DATA0 PID first, then 1 and 2 in the end. Probably a
> firmware update can fix this, but I'm not aware about if such exists.
> The PID issue was found using a USB analyzer.
>
> Apparently this bug has gone undetected, because at least the EHCI high
> speed only controller I've got silently ignores this kind of errors and
> receives the data whilst the XHCI not. Conclusion:
> Existing alternate setting must be used.
>
> I think I will have to get another USB based receiver with CI slot. Any
> recommendations for DVB-T ?

There is no many alternatives available. I suspect Anysee E7 serie is 
the only one. And I am not even sure if its CI works anymore. Lastly 
when I tested it I didn't get scrambled channels working - but it could 
be due to card entitlements were not upgraded. Anyhow, if there is bug 
then it should be easy to fix.

regards
Antti

-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: TT-USB2.0 and high bitrate packet loss (DVB-C/T)
  2013-06-02 21:02   ` Antti Palosaari
@ 2013-06-05  1:34     ` Antti Palosaari
  0 siblings, 0 replies; 4+ messages in thread
From: Antti Palosaari @ 2013-06-05  1:34 UTC (permalink / raw)
  To: Hans Petter Selasky

On 06/03/2013 12:02 AM, Antti Palosaari wrote:
> On 06/02/2013 03:19 PM, Hans Petter Selasky wrote:

>> I think I will have to get another USB based receiver with CI slot. Any
>> recommendations for DVB-T ?
>
> There is no many alternatives available. I suspect Anysee E7 serie is
> the only one. And I am not even sure if its CI works anymore. Lastly
> when I tested it I didn't get scrambled channels working - but it could
> be due to card entitlements were not upgraded. Anyhow, if there is bug
> then it should be easy to fix.

I just tested, actually first bisecting back to Kernel 3.3 and VLC2 and 
it didn't work... That makes me suspect it was VLC which has gone 
broken. So I tried gnutv & mplayer and surprise CI was working! Both 
Anysee E7 TC and Anysee E7 T2C. Tested only DVB-C as I don't have DVB-T 
subscription card. CI/CAM worked earlier for VLC somehow too.

Start tuning on terminal:
gnutv -channels /path/to/channels.conf "scrambled channel"
Start mplayer on the another terminal:
mplayer /dev/dvb/adapter0/dvr0

It is a little bit boring situation as there is no very good Gnome 
Desktop TV application. Have never been...

regards
Antti

-- 
http://palosaari.fi/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-06-05  1:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-30  8:00 TT-USB2.0 and high bitrate packet loss (DVB-C/T) Hans Petter Selasky
2013-06-02 12:19 ` Hans Petter Selasky
2013-06-02 21:02   ` Antti Palosaari
2013-06-05  1:34     ` Antti Palosaari

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).