On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 9 Apr 2014, Clemens Ladisch wrote:
Alan Stern wrote:
The IN transfer was 1 frame long and scheduled for frame 1123, so its
completion indicates that the current frame number is = 1123. The OUT
transfer was 6
On 04/16/2014 01:17 PM, Russel Hughes wrote:
On 9 April 2014 19:53, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 9 Apr 2014, Clemens Ladisch wrote:
Alan Stern wrote:
The IN transfer was 1 frame long and scheduled for frame 1123, so its
completion indicates that the current frame
From: Alan Stern
...
Furthermore, I clearly recall Sarah Sharp (the original maintainer for
xhci-hcd) saying that the support for isochronous transfers needed
attention. This may well be an example.
You also definitely don't want to cancel an isoc urb.
Doing so is likely to corrupt the kernel
On Thu, 10 Apr 2014, David Laight wrote:
You also definitely don't want to cancel an isoc urb.
Doing so is likely to corrupt the kernel heap.
If an isoc urb generates multiple TRB the code allocates a little
structure 'per TRB' and links it to the urb.
This seems to be done so that it can
Alan Stern wrote:
The IN transfer was 1 frame long and scheduled for frame 1123, so its
completion indicates that the current frame number is = 1123. The OUT
transfer was 6 frames long and scheduled for frame , so it should
have completed in frame 1117. But the timestamps show that the
On Wed, 9 Apr 2014, Clemens Ladisch wrote:
Alan Stern wrote:
The IN transfer was 1 frame long and scheduled for frame 1123, so its
completion indicates that the current frame number is = 1123. The OUT
transfer was 6 frames long and scheduled for frame , so it should
have completed
On Wed, 9 Apr 2014, Clemens Ladisch wrote:
Alan Stern wrote:
The IN transfer was 1 frame long and scheduled for frame 1123, so its
completion indicates that the current frame number is = 1123. The OUT
transfer was 6 frames long and scheduled for frame , so it should
have completed
-- Forwarded message --
From: Russel Hughes russel.hug...@gmail.com
Date: 6 April 2014 11:32
Subject: Isochronos audio
To: linux-usb linux-usb@vger.kernel.org
Can you describe the actual problem ? How can you trigger it ? What are
you doing when the problem arises ? Do you
On Tue, 8 Apr 2014, Russel Hughes wrote:
Hi,
I put in a new kernel and get the response from uname -r of
3.14.0-031400-generic, apologies for the pedantry I am not that sure
what I am doing. The device behaves exactly the same as default Linux
kernel, buffer is erratic not stable like USB
