7 Nov
2011
7 Nov
'11
10:53 p.m.
Hi!
A few days ago in the alsa users mailing list, Clemens pointed to a
recent patch for the EHCI driver [1] [2] for solving the following problem:
The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.
In connection with this, there was a discussion here some months ago
[3]. Some users said that they were not able to get jack working in
duplex mode . I also tried to prepare my sister's notebook with a UA25EX
and duplex did not work either. I encountered the same problem in the
laptop of a friend of mine. In both cases, the computers have an Intel 5
Series/3400 Series Chipset USB2 controller. Jack always says "broken
pipe".
I have not tried the patch yet but it seems to work if you read the
whole thread in alsa-users. Has someone else tried? Joan? Jeremy?
Regards, Pablo
[1]
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28007.html
[2] http://marc.info/?l=linux-usb&m=131973404328622
[3]
http://old.nabble.com/USB-audio-interface-and-a-buggy-USB-controller-td2963…
8 Nov
8 Nov
6:22 p.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
On 11/07/2011 10:53 PM, Pablo Fernández wrote:
Hi!
A few days ago in the alsa users mailing list, Clemens pointed to a
recent patch for the EHCI driver [1] [2] for solving the following problem:
The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.
I've had the same problem.
From what I've been able to gather from the LKML is that this occurred
before the 3.2 staging merge.
I'm looking forward to trying it out UA25EX / Asus N53SV (7 series) -
would have done so already but my equipment is still in transit. Will
let you know in a week or so when my container gets here.
regards,
Brendan
26 Mar
26 Mar
8:37 a.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
On 11/08/2011 06:22 PM, Brendan Jones wrote:
On 11/07/2011 10:53 PM, Pablo Fernández wrote:
This patch has made it to the 3.3 kernel in Fedora and for some users
this has fixed the error "cannot submit datapipe for urb 0, error -28:
not enough bandwidth" on USB fullspeed devices like the UA25-EX.
regards,
Brendan
Hi!
A few days ago in the alsa users mailing list, Clemens pointed to a
recent patch for the EHCI driver [1] [2] for solving the following
problem:
The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.
I've had the same problem.
From what I've been able to gather from the LKML is that this occurred
before the 3.2 staging merge.
I'm looking forward to trying it out UA25EX / Asus N53SV (7 series) -
would have done so already but my equipment is still in transit. Will
let you know in a week or so when my container gets here.
regards,
Brendan
8 Nov
8 Nov
8:25 p.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
On 11/07/2011 10:53 PM, Pablo Fernández wrote:
I have not tried the patch yet but it seems to work if
you read the
whole thread in alsa-users. Has someone else tried? Joan? Jeremy?
Hello Pablo,
Thanks for the links, unfortunately I have no access to a machine with
such a chipset anymore (new job).
Best,
Jeremy
10:55 p.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
Jeremy Jongepier wrote:
On 11/07/2011 10:53 PM, Pablo Fernández wrote:
This problem affects all full speed (i.e., most) audio devices connected
through a high-speed hub, so it could be reproduced on all machines, if
actually desired. :) The problem with Intel's "rate matching" chipset
controller is that it has a built-in hub which cannot be disabled.
Regards,
Clemens
I have not tried the patch yet but it seems to
work if you read the
whole thread in alsa-users. Has someone else tried? Joan? Jeremy?
Thanks for the links, unfortunately I have no access to a machine with
such a chipset anymore (new job).
11:40 p.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
On 11/08/2011 10:55 PM, Clemens Ladisch wrote:
Jeremy Jongepier wrote:
So what your saying is there is no way way around it? Originally I
thought is was limited to a particular chipset - is impossible to find
the bandwidth on the bus?
On 11/07/2011 10:53 PM, Pablo Fernández wrote:
This problem affects all full speed (i.e., most) audio devices connected
through a high-speed hub, so it could be reproduced on all machines, if
actually desired. :) The problem with Intel's "rate matching" chipset
controller is that it has a built-in hub which cannot be disabled.
I have not tried the patch yet but it seems to
work if you read the
whole thread in alsa-users. Has someone else tried? Joan? Jeremy?
Thanks for the links, unfortunately I have no access to a machine with
such a chipset anymore (new job).
9 Nov
9 Nov
12:39 p.m.
New subject: No duplex mode with the EHCI driver and USB hub. Is the problem solved?
Brendan Jones wrote:
On 11/08/2011 10:55 PM, Clemens Ladisch wrote:
There seems to be a miserunderstanding.
The Linux EHCI driver has (and has always had) a bug in the TT scheduler
that makes it unable to allocate enough bandwidth for more than one
stream for full-speed audio devices connected through a high-speed hub.
The mentioned patch fixes this bug (mostly).
As long as the patch didn't exist, a workaround was to connect the
device directly to the computer (so that not EHCI but another controller
would be used). This workaround is not possible with recent Intel
chipsets because those have only EHCI controllers and handle high-speed
devices with a built-in hub.
All this is completely unrelated with a hardware bug in the first
revision of these Intel chipsets, which made USB audio just break.
Regards,
Clemens
Jeremy Jongepier wrote:
So what your saying is there is no way way around it? Originally I
thought is was limited to a particular chipset - is impossible to find
the bandwidth on the bus? On 11/07/2011 10:53 PM, Pablo Fernández wrote:
This problem affects all full speed (i.e., most) audio devices connected
through a high-speed hub, so it could be reproduced on all machines, if
actually desired. :) The problem with Intel's "rate matching" chipset
controller is that it has a built-in hub which cannot be disabled. I have not tried the patch yet but it seems to
work if you read the
whole thread in alsa-users. Has someone else tried? Joan? Jeremy?
Thanks for the links, unfortunately I have no access to a machine with
such a chipset anymore (new job).
4407
days inactive
4547
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Brendan Jones -
Clemens Ladisch -
Jeremy Jongepier -
Pablo Fernández