8 Mar
2008
8 Mar
'08
3:58 a.m.
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt. Does anyone have a recommendation for a good usb
soundcard that works well with Linux/Jack, and is not too
expensive?
James
8 Mar
8 Mar
4:44 a.m.
The ESI maya 44 USB is nice.
VERY cheap, 4 i/o, and working just fine with linux.
I can't see how it can be beaten on price/performance.
In europe it's sold for around 100$
-But no midi i/o on it - but i don't care about that.
On Sat, 2008-03-08 at 07:58 +0000, James Stone wrote:
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt. Does anyone have a recommendation for a good usb
soundcard that works well with Linux/Jack, and is not too
expensive?
James
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
6:32 a.m.
Hallo,
James Stone hat gesagt: // James Stone wrote:
I am wanting to use the eeepc for a mobile sound
generation unit,
but unfortunately the gfx card and sound card share the same
interrupt. Does anyone have a recommendation for a good usb
soundcard that works well with Linux/Jack, and is not too
expensive?
That's hard to answer: What does "works well" and "not too
expensive"
mean to you? Is a 10 $/Euro soundstick enough? How many channels do
you want? Midi? Balanced in/outs? Mic preamps? 24bit? LAU cannot do
this market research for you.
Some general remarks: Practically every USB-1.1 soundcard on the
market (except some M-Audio models) is well supported by ALSA. So I'd
suggest you check out some online vendors for a card that you like
feature- and pricewise then g**gle that model with "linux ALSA" added
and/or check qbik.ch for user comments.
Ciao
--
Frank Barknecht _ ______footils.org__
9 Mar
9 Mar
4:33 a.m.
On Sat, Mar 08, 2008 at 10:52:17AM +0100, Frank Barknecht wrote:
Hallo,
James Stone hat gesagt: // James Stone wrote:
Thanks.
Do you have any idea what kind of latency under jack I would
expect from a CM-106 based card vs. a "Burr-Brown from TI"
chipset (Behringer UCA 202).
James
I am wanting to use the eeepc for a mobile sound
generation unit,
but unfortunately the gfx card and sound card share the same
interrupt. Does anyone have a recommendation for a good usb
soundcard that works well with Linux/Jack, and is not too
expensive?
That's hard to answer: What does "works well" and "not too
expensive"
mean to you? Is a 10 $/Euro soundstick enough? How many channels do
you want? Midi? Balanced in/outs? Mic preamps? 24bit? LAU cannot do
this market research for you.
Some general remarks: Practically every USB-1.1 soundcard on the
market (except some M-Audio models) is well supported by ALSA. So I'd
suggest you check out some online vendors for a card that you like
feature- and pricewise then g**gle that model with "linux ALSA" added
and/or check qbik.ch for user comments.
7:12 a.m.
Hallo,
James Stone hat gesagt: // James Stone wrote:
Do you have any idea what kind of latency under jack I
would
expect from a CM-106 based card vs. a "Burr-Brown from TI"
chipset (Behringer UCA 202).
All USB cards (in ALSA) have the same latency.
Ciao
--
Frank Barknecht _ ______footils.org__
8:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Barknecht schrieb:
Hallo,
James Stone hat gesagt: // James Stone wrote:
Is that a fact? [SHOCK] So, if I use a Edirol UA-101 for appr. 550 Eur
it would force me to use the same settings for jack (for 17ms that is)
as my crude Behringer U-Control??
best
HZN
Do you have any idea what kind of latency under
jack I would
expect from a CM-106 based card vs. a "Burr-Brown from TI"
chipset (Behringer UCA 202).
All USB cards (in ALSA) have the same latency. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH08YY1Aecwva1SWMRAgsKAJ414pEsD0ZNPZqpYZhQOiArDAl5+ACfW1Zi
dOLBDBy/IajQBuiNo7v7vH4=
=LIPE
-----END PGP SIGNATURE-----
9:21 a.m.
On Sunday 09 March 2008 12:12:24 Hartmut Noack wrote:
You should be able to achieve much better latencies than that, even with the
U-Control.
I can run all my USB devices, including the crappy UCA 202, at 4ms latency
(48000/64/3). I don't get any xruns, except when starting some JACK clients
(but there a higher latency doesn't help much either).
This is with a -rt kernel, of course, and tuning the IRQ priorities with chrt
made a huge difference. I got the best results when I increased the
priorities for rtc and usb, but not for the machine's built-in soundcard
(which I don't use at the same time).
Dominic
James Stone
hat gesagt: // James Stone wrote:
Is that a fact? [SHOCK] So, if I use a Edirol UA-101 for appr. 550 Eur
it would force me to use the same settings for jack (for 17ms that is)
as my crude Behringer U-Control?? Do you have any idea what kind of latency under
jack I would
expect from a CM-106 based card vs. a "Burr-Brown from TI"
chipset (Behringer UCA 202).
All USB cards (in ALSA) have the same latency.
11:26 a.m.
Hallo,
Hartmut Noack hat gesagt: // Hartmut Noack wrote:
Frank Barknecht schrieb:
USB-audio-guru Clemens Ladisch on LAU in 2005:
"Due to how the USB protocol works, all USB audio devices have the
same latency."
http://lalists.stanford.edu/lau/2005/06/0200.html
Which might also mean that any vendor bragging about how the latency
of his USB device is lower than that of the competition is lying. ;)
Ciao
--
Frank Barknecht _ ______footils.org__
All USB cards (in ALSA) have the same latency.
Is that a fact? [SHOCK] So, if I use a Edirol UA-101 for appr. 550 Eur
it would force me to use the same settings for jack (for 17ms that is)
as my crude Behringer U-Control?? 
1:38 p.m.
On Sun, Mar 09, 2008 at 03:26:56PM +0100, Frank Barknecht wrote:
USB-audio-guru Clemens Ladisch on LAU in 2005:
"Due to how the USB protocol works, all USB audio devices have the
same latency."
http://lalists.stanford.edu/lau/2005/06/0200.html
Does Firewire get lower latency, or just better throughput?
What about USB 2 if/when freebob supports it?
And just to be clear - if I run jackd -r 48000 -p 64 -n3, is it
correct that the one-way latency in seconds is 64 * 3 / 48000.0 =
0.004? So round-trip latency is twice that?
(Plus any converter overhead of course.)
--
Paul Winkler
http://www.slinkp.com
2:48 p.m.
Am Sonntag, 9. März 2008 schrieb Paul Winkler:
On Sun, Mar 09, 2008 at 03:26:56PM +0100, Frank
Barknecht wrote:
Probably the same latency. But higher throughput than usb1. Which leaves room
for more channels. :-)
USB-audio-guru Clemens Ladisch on LAU in 2005:
"Due to how the USB protocol works, all USB audio devices have the
same latency."
http://lalists.stanford.edu/lau/2005/06/0200.html
Does Firewire get lower latency,
or just better throughput? What about USB 2 if/when freebob supports it?
freebob will support usb2?
freebob won't even get any further release! The next generation is called
ffado and is (still) firewire only. And I don't think there are any plans on
extending it to usb2.
And just to be clear - if I run jackd -r 48000 -p 64
-n3, is it
correct that the one-way latency in seconds is 64 * 3 / 48000.0 =
0.004? So round-trip latency is twice that?
(Plus any converter overhead of course.)
That value is the time inside the computer. Additional are the times of the
converters buffers and the transfer over cable (from the systems memory to
the output-buffer of the usb and back).
With ffado the latency reported by jack will be the full latency without the
converts latency. So its compensating the transports latency...
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
3:18 p.m.
On Sun, Mar 09, 2008 at 06:48:12PM +0100, Arnold Krille wrote:
Am Sonntag, 9. März 2008 schrieb Paul Winkler:
It's a full-time job keeping up with this stuff ;-)
What about USB 2 if/when freebob supports it?
freebob will support usb2?
freebob won't even get any further release! The next generation is called
ffado and is (still) firewire only. And I don't think
there are any plans on
extending it to usb2.
Bridgeco said at NAMM that they're extending bebob to support USB 2.
And I heard off-list that there might be a possibility of linux
developers getting specs andr samples. But I assume that's long-term.
--
Paul Winkler
http://www.slinkp.com
10 Mar
10 Mar
7:30 a.m.
Paul Winkler wrote:
On Sun, Mar 09, 2008 at 06:48:12PM +0100, Arnold
Krille wrote:
I will query the bridgeco guys about this when I see them next week.
In theory it should be possible to extend ffado for USB audio, but I
have to be honest and say that I don't really feel like doing that any
time soon. It will probably take some time before bridgeco based usb
devices will hit the market. So who knows...
Greets,
Pieter
Am Sonntag, 9. März 2008 schrieb Paul Winkler:
It's a full-time job keeping up with this stuff ;-)
What about USB 2 if/when freebob supports it?
freebob will support usb2?
freebob won't even get any further release! The next generation is called
ffado and is (still) firewire only. And I don't
think there are any plans on
extending it to usb2.
Bridgeco said at NAMM that they're extending bebob to support USB 2.
And I heard off-list that there might be a possibility of linux
developers getting specs andr samples. But I assume that's long-term.
17 Apr
17 Apr
6:09 p.m.
* Frank Barknecht:
Some general remarks: Practically every USB-1.1
soundcard on the
market (except some M-Audio models) is well supported by ALSA. So I'd
suggest you check out some online vendors for a card that you like
feature- and pricewise then g**gle that model with "linux ALSA" added
and/or check qbik.ch for user comments.
So would an Edirol UA-1EX work and provide decent sound quality (mostly
for output)? I'm kind of surprised that USB sound is so unproblematic,
but this probably explains why there is so little information on driver
support on the web. 8-)
8 Mar
8 Mar
8:03 p.m.
On Sat, Mar 8, 2008 at 2:58 AM, James Stone <jamesmstone(a)gmail.com> wrote:
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt.
This is not necessarily a showstopper. At least in theory. Do you
have any empirical evidence that it's a problem for you?
I would think that if you can disable the VSYNC interrupt from the gfx
card, that it would be even less of a problem. In my experience,
VSYNC interrupts on Linux don't help anyway - I've compared the
results with and without it enabled on both ATI and NVIDIA cards and
the display tears horribly (esp. when playing movies or moving windows
quickly) either way.
Lee
9 Mar
9 Mar
5:15 a.m.
On Sat, Mar 08, 2008 at 07:03:30PM -0500, Lee Revell wrote:
On Sat, Mar 8, 2008 at 2:58 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
xruns..
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt.
This is not necessarily a showstopper. At least in theory. Do you
have any empirical evidence that it's a problem for you?
I would think that if you can disable the VSYNC interrupt from the gfx
card, that it would be even less of a problem. In my experience,
VSYNC interrupts on Linux don't help anyway - I've compared the
results with and without it enabled on both ATI and NVIDIA cards and
the display tears horribly (esp. when playing movies or moving windows
quickly) either way.
Sounds good. How do I disable that?
James
10 Mar
10 Mar
2:56 p.m.
On Sun, Mar 9, 2008 at 3:15 AM, James Stone <jamesmstone(a)gmail.com> wrote:
In the control panel for your video card. nvidia-settings for nvidia,
amdcccle for ATI, no idea for Intel.
Lee
On Sat, Mar 08, 2008 at 07:03:30PM -0500, Lee Revell
wrote:
OK. And you're sure the IRQ priorities were set correctly, realtime
kernel used, JACK in realtime mode, etc?
On Sat, Mar 8, 2008 at 2:58 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
xruns..
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt.
This is not necessarily a showstopper. At least in theory. Do you
have any empirical evidence that it's a problem for you?
I would think that if you can disable the VSYNC interrupt from the gfx
card, that it would be even less of a problem. In my experience,
VSYNC interrupts on Linux don't help anyway - I've compared the
results with and without it enabled on both ATI and NVIDIA cards and
the display tears horribly (esp. when playing movies or moving windows
quickly) either way.
Sounds good. How do I disable that?
4:53 p.m.
On Mon, Mar 10, 2008 at 12:56:17PM -0500, Lee Revell wrote:
In the control panel for your video card. nvidia-settings for nvidia,
amdcccle for ATI, no idea for Intel.
I am not sure it is possible, but I will do some more digging.
James
On Sun, Mar 9, 2008 at 3:15 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
Yes. but IRQ tuning is not much use with the video on the same
interrupt as the sound card. Basically whenever a widget moves,
sound dropout occurs.
On Sat, Mar 08, 2008 at 07:03:30PM -0500, Lee
Revell wrote:
OK. And you're sure the IRQ priorities were set correctly, realtime
kernel used, JACK in realtime mode, etc?
On Sat, Mar 8, 2008 at 2:58 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
xruns..
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt.
This is not necessarily a showstopper. At least in theory. Do you
have any empirical evidence that it's a problem for you?
I would think that if you can disable the VSYNC interrupt from the gfx
card, that it would be even less of a problem. In my experience,
VSYNC interrupts on Linux don't help anyway - I've compared the
results with and without it enabled on both ATI and NVIDIA cards and
the display tears horribly (esp. when playing movies or moving windows
quickly) either way.
Sounds good. How do I disable that?
5:37 p.m.
On Mon, 2008-03-10 at 19:53 +0000, James Stone wrote:
On Mon, Mar 10, 2008 at 12:56:17PM -0500, Lee Revell
wrote:
this is not how video display works. they are a lot like audio
interfaces actually. periodically, they interrupt the host CPU to say
"i'm about to start redrawing the screen from the framebuffer you last
told me about". that's about it really. they never redraw the screen at
any other time.
when your GUI toolkit decides to redraw a widget, it doesn't interact
with the h/w. all that happens is that eventually the new image of the
screen gets into the framebuffer, and on the next "VSYNC" cycle, the
video card will push it out to the actual display.
what is an issue is that the drivers and/or h/w associated with the
video card sometimes do not play fair with the PCI bus - they claim
owernship over it for too long while doing a redraw, and this *does*
lead to xruns at low latencies.
--p
On Sun, Mar 9, 2008 at 3:15 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
Yes. but IRQ tuning is not much use with the video on the same
interrupt as the sound card. Basically whenever a widget moves,
sound dropout occurs. On Sat, Mar 08, 2008 at 07:03:30PM -0500, Lee
Revell wrote:
OK. And you're sure the IRQ priorities were set correctly, realtime
kernel used, JACK in realtime mode, etc?
On Sat, Mar 8, 2008 at 2:58 AM, James Stone
<jamesmstone(a)gmail.com> wrote:
> Hi,
>
> I am wanting to use the eeepc for a mobile sound generation unit,
> but unfortunately the gfx card and sound card share the same
> interrupt.
This is not necessarily a showstopper. At least in theory. Do you
have any empirical evidence that it's a problem for you?
xruns..
9:30 p.m.
On Mon, Mar 10, 2008 at 4:36 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Mon, 2008-03-10 at 19:53 +0000, James Stone
wrote:
Paul, you're absolutely right. I encountered this exact issue years
ago with the open source Via Unichrome driver, and fortunately was
able to get it fixed by the developers. Typically the (userspace X11)
video driver tries to write to the card's command FIFO without first
checking whether it is full. If the FIFO is full, this will
completely stall the PCI bus until the FIFO drains. Nothing at all to
do with interrupts.
This is done by vendors to get better benchmark scores. You can also
prove that this is your issue by running a simple userspace latency
tester that does not touch the audio hardware; it will also report
large delays when moving windows around.
If this is your problem, your only hope is to use the open source
driver for your video hardware, and if that driver has the same
problem, to report it to the maintainers.
I'd still like to see if disabling the VSYNC interrupt changes things,
if only to disprove the common perception that the problem is caused
by interrupt sharing.
Lee
Yes. but IRQ tuning is not much use with the
video on the same
interrupt as the sound card. Basically whenever a widget moves,
sound dropout occurs.
this is not how video display works. they are a lot like audio
interfaces actually. periodically, they interrupt the host CPU to say
"i'm about to start redrawing the screen from the framebuffer you last
told me about". that's about it really. they never redraw the screen at
any other time.
when your GUI toolkit decides to redraw a widget, it doesn't interact
with the h/w. all that happens is that eventually the new image of the
screen gets into the framebuffer, and on the next "VSYNC" cycle, the
video card will push it out to the actual display.
what is an issue is that the drivers and/or h/w associated with the
video card sometimes do not play fair with the PCI bus - they claim
owernship over it for too long while doing a redraw, and this *does*
lead to xruns at low latencies.
11 Mar
11 Mar
7:37 p.m.
On Mon, Mar 10, 2008 at 08:30:50PM -0400, Lee Revell wrote:
On Mon, Mar 10, 2008 at 4:36 PM, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
I don't think this is the problem. I asked (to the best of my
knowledge) about this on the xorg list and got this reply:
On Mon, 2008-03-10 at 19:53 +0000, James Stone
wrote:
Paul, you're absolutely right. I encountered this exact issue years
ago with the open source Via Unichrome driver, and fortunately was
able to get it fixed by the developers. Typically the (userspace X11)
video driver tries to write to the card's command FIFO without first
checking whether it is full. If the FIFO is full, this will
completely stall the PCI bus until the FIFO drains. Nothing at all to
do with interrupts.
This is done by vendors to get better benchmark scores. You can also
prove that this is your issue by running a simple userspace latency
tester that does not touch the audio hardware; it will also report
large delays when moving windows around.
If this is your problem, your only hope is to use the open source
driver for your video hardware, and if that driver has the same
problem, to report it to the maintainers.
I'd still like to see if disabling the VSYNC interrupt changes things,
if only to disprove the common perception that the problem is caused
by interrupt sharing.
Yes. but IRQ tuning is not much use with the
video on the same
interrupt as the sound card. Basically whenever a widget moves,
sound dropout occurs.
this is not how video display works. they are a lot like audio
interfaces actually. periodically, they interrupt the host CPU to say
"i'm about to start redrawing the screen from the framebuffer you last
told me about". that's about it really. they never redraw the screen at
any other time.
when your GUI toolkit decides to redraw a widget, it doesn't interact
with the h/w. all that happens is that eventually the new image of the
screen gets into the framebuffer, and on the next "VSYNC" cycle, the
video card will push it out to the actual display.
what is an issue is that the drivers and/or h/w associated with the
video card sometimes do not play fair with the PCI bus - they claim
owernship over it for too long while doing a redraw, and this *does*
lead to xruns at low latencies.
"Typically the (userspace X11) video driver tries
to write to
the
card's command FIFO without first
checking whether it is full. If the FIFO is full, this will
completely stall the PCI bus until the FIFO drains. Nothing at
all to
do with interrupts."
Not at all. We don't have a fifo like that, and I don't know any
xorg drivers for fifo-having hardware that have that bug either.
We may be keeping the PCI bus busy with our spinning on ring tail
reads when we're waiting for hardware idle or otherwise trying to
get ring space, but we do one of those and then a gettimeofday
for timeout handling anyway, so you shouldn't be all that busy I
don't think.
That FIFO issue is completely separate from any vertical sync
issue. We do no syncing to vblank for plain 2d rendering anyway.
James
10 Mar
10 Mar
12:19 p.m.
2008/3/8, James Stone <jamesmstone(a)gmail.com>om>:
Hi,
I am wanting to use the eeepc for a mobile sound generation unit,
but unfortunately the gfx card and sound card share the same
interrupt. Does anyone have a recommendation for a good usb
soundcard that works well with Linux/Jack, and is not too
expensive?
I just got myself an Edirol UA25 and I'm very happy with it. It works
out of the box with alsa and jack and has two integrated mic-preamps.
It's supposed to be a 96 kHz samplerate card but under linux I can
only get it to do 44.1 kHz. It's USB-powerd and you can get on Ebay
for about 200 USD.
alex
--
http://polite.se
12:54 p.m.
Alex Polite wrote:
I just got myself an Edirol UA25 and I'm very
happy with it.
It's supposed to be a 96 kHz samplerate card but under linux I can
only get it to do 44.1 kHz.
Set the "Advanced" mode switch. If this doesn't work after
re-plugging the device, send me the output of "lsusb -v" for this
device.
HTH
Clemens
15 Mar
15 Mar
2:18 p.m.
Clemens Ladisch wrote:
Alex Polite wrote:
I've got the Edirol UA20 and I am happy with it as an audio device (only
44.1 however), or as a midi device, but not both, sadly. If I run it in
"Advanced" mode, jack won't start up, but it shows up as a midi device.
If I run it with "Advanced" driver off, I can use it as a midi device,
but jack won't start up.
I've attached the lsusb -v for the device in advanced off and advanced
on modes. I'm not an expert, but in advanced off mode the lsusb has
several lines that indicate an audio streaming device, where in advanced
on it doesn't.
Regards,
Bill
Bus 002 Device 004: ID 0582:0025 Roland Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
idVendor 0x0582 Roland Corp.
idProduct 0x0025
bcdDevice 1.01
iManufacturer 1 Roland
iProduct 2 EDIROL UA-20
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 322
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 170mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 0
iInterface 0
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 0
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 9
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x0120 1x 288 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 0
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0120 1x 288 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Class specific interface descriptor for class 255 is unsupported
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Device Status: 0x0001
Self Powered
Bus 002 Device 005: ID 0582:0026 Roland Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0582 Roland Corp.
idProduct 0x0026
bcdDevice 1.01
iManufacturer 1 Roland
iProduct 2 EDIROL UA-20
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 174
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 170mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 52
bInCollection 2
baInterfaceNr( 0) 1
baInterfaceNr( 1) 2
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0304 Desktop Speaker
bAssocTerminal 0
bSourceID 1
iTerminal 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0601 Analog Connector
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 7
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bDelay 0 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 44100
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 9
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x00c0 1x 192 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 2 Decoded PCM samples
wLockDelay 512 Decoded PCM samples
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 7
bDelay 0 frames
wFormatTag 1 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 44100
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c0 1x 192 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioControl Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bLockDelayUnits 0 Undefined
wLockDelay 0 Undefined
Device Status: 0x0001
Self Powered
I just got myself an Edirol UA25 and I'm very
happy with it.
It's supposed to be a 96 kHz samplerate card but under linux I can
only get it to do 44.1 kHz.
Set the "Advanced" mode switch. If this doesn't work after
re-plugging the device, send me the output of "lsusb -v" for this
device.
HTH
Clemens
2:27 p.m.
Have you tried the sample rate switch on the UA25? I've got one and I've
noticed that the jack takes the sample rate of whatever this switch is
set to.
-sharp
Bill Allen wrote:
Clemens Ladisch wrote:
Alex Polite wrote:
I've got the Edirol UA20 and I am happy with it as an audio device (only
44.1 however), or as a midi device, but not both, sadly. If I run it in
"Advanced" mode, jack won't start up, but it shows up as a midi device.
If I run it with "Advanced" driver off, I can use it as a midi device,
but jack won't start up.
I've attached the lsusb -v for the device in advanced off and advanced
on modes. I'm not an expert, but in advanced off mode the lsusb has
several lines that indicate an audio streaming device, where in advanced
on it doesn't.
Regards,
Bill
------------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user I just got myself an Edirol UA25 and I'm very
happy with it.
It's supposed to be a 96 kHz samplerate card but under linux I can
only get it to do 44.1 kHz.
Set the "Advanced" mode switch. If this doesn't work after
re-plugging the device, send me the output of "lsusb -v" for this
device.
HTH
Clemens
3:06 p.m.
On Sat, Mar 15, 2008 at 01:28:03PM -0400, Sharp Hall wrote:
Have you tried the sample rate switch on the UA25?
I've got one and I've
noticed that the jack takes the sample rate of whatever this switch is
set to.
You need to switch the device off/on or disconnect/reconnect,
then wait a few seconds if you change the sample rate or mode.
I've an UA2, it works perfectly on all rates, including the
'advanced modes'.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
16 Mar
16 Mar
3:15 p.m.
Bill Allen wrote:
I've got the Edirol UA20 and I am happy with it
as an audio device
(only 44.1 however), or as a midi device, but not both, sadly. If I
run it in "Advanced" mode, jack won't start up, but it shows up as a
midi device. If I run it with "Advanced" driver off, I can use it as a
midi device, but jack won't start up.
I've attached the lsusb -v for the device in advanced off and advanced
on modes. I'm not an expert, but in advanced off mode the lsusb has
several lines that indicate an audio streaming device, where in
advanced on it doesn't.
Regards,
Bill
After doing some googling, I see that this has been discussed on this
list before. It seems that Clemens put a fix in for it. I would assume
that any recent alsa has gotten that fix (usbquirks.h). I've tried this
on two very recent distros (Ubuntu rt and dyne:bolic) and it exhibits
the same problem. Maybe I've got a defective device. Is there anything
that I can check to verify that my distros have the fix in them?
Regards,
Bill
6:01 p.m.
On Sun, 16 Mar 2008 14:15:43 -0400
Bill Allen <lau(a)ballen.fastmail.fm> wrote:
Bill Allen wrote:
I can't tell you how to verify anything, but the interface works
perfectly well with ubuntu (studio) gutsy and hardy as well. I also
tested it with musix, dyne:bolic and pure:dyne. The dynes require that
you type 'modprobe snd-usb-audio' afair.
I had some kind of problem with dyne:bolic but can't remember what it
was.
I really don't know what the problem could be.
I usually run this card at advanced and 48kHz, sound and midi works
fine.
I think my current standard parameters for jack are something like that:
/usr/bin/jackd -R -P70 -p128 -dalsa -dhw:1 -r48000 -p1024 -n3 -Xseq
This line is on gutsy with jack 0.109, I'd try it without -Xseq on
plain gutsy.
Best,
Philipp
I've got the Edirol UA20 and I am happy with
it as an audio device
(only 44.1 however), or as a midi device, but not both, sadly. If I
run it in "Advanced" mode, jack won't start up, but it shows up as
a midi device. If I run it with "Advanced" driver off, I can use it
as a midi device, but jack won't start up.
I've attached the lsusb -v for the device in advanced off and
advanced on modes. I'm not an expert, but in advanced off mode the
lsusb has several lines that indicate an audio streaming device,
where in advanced on it doesn't.
Regards,
Bill
After doing some googling, I see that this has been discussed on this
list before. It seems that Clemens put a fix in for it. I would
assume that any recent alsa has gotten that fix (usbquirks.h). I've
tried this on two very recent distros (Ubuntu rt and dyne:bolic) and
it exhibits the same problem. Maybe I've got a defective device. Is
there anything that I can check to verify that my distros have the
fix in them?
Regards,
Bill
17 Mar
17 Mar
5:15 a.m.
Bill Allen wrote:
I've got the Edirol UA20 and I am happy with it as
an audio device (only
44.1 however), or as a midi device, but not both, sadly. If I run it in
"Advanced" mode, jack won't start up,
Does jack output any error message?
Does "aplay something.wav" work?
Regards,
Clemens
7:50 p.m.
Clemens Ladisch wrote:
Bill Allen wrote:
In Non-advanced mode plays fine:
bill:~$ aplay -Dhw:1,0 Hells_intro.wav
Playing WAVE 'Hells_intro.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
In advanced mode:
bill:~$ aplay -Dhw:1,0 Hells_intro.wav
Playing WAVE 'Hells_intro.wav' : Signed 16 bit Little Endian, Rate 44100
Hz, Stereo
aplay: set_params:900: Sample format non available
In advanced mode jackd says:
bill:~$ jackd -R -P70 -p128 -dalsa -dhw:1 -r48000 -p1024 -n3
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:1|hw:1|1024|3|48000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 48000Hz, period = 1024 frames, buffer = 3 periods
ALSA: final selected sample format for capture: 24bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian
ALSA: use 3 periods for playback
ALSA: could not start playback (Broken pipe)
DRIVER NT: could not start driver
cannot start driver
jackd watchdog: timeout - killing jackd
Aborted (core dumped)
Best regards,
Bill
I've got the Edirol UA20 and I am happy with
it as an audio device (only
44.1 however), or as a midi device, but not both, sadly. If I run it in
"Advanced" mode, jack won't start up,
Does jack output any error message?
Does "aplay something.wav" work?
18 Mar
18 Mar
5:43 a.m.
Bill Allen wrote:
$ aplay -Dhw:1,0 Hells_intro.wav
Playing WAVE 'Hells_intro.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
aplay: set_params:900: Sample format non available
Using the "hw" device prevents ALSA from doing any automatic sample
format conversions.
In advanced mode jackd says:
...
ALSA: could not start playback (Broken pipe)
There should be an error message in the system log.
I'd guess that this goes away if you update to a newer kernel, or if you
connect the device directly to the computer instead of through a hub.
HTH
Clemens
10:38 p.m.
Clemens Ladisch wrote:
Bill Allen wrote:
Yes, true, when I use plughw, I don't get the error, but it doesn't play
in advanced mode still:
bill@amddesktop:~$ aplay -Dplughw:2,0 audiodump.wav
Playing WAVE 'audiodump.wav' : Unsigned 8 bit, Rate 11024 Hz, Mono
Aborted by signal Interrupt...
$ aplay -Dhw:1,0 Hells_intro.wav
Playing WAVE 'Hells_intro.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
aplay: set_params:900: Sample format non available
Using the "hw" device prevents ALSA from doing any automatic sample
format conversions.
I'm going into the usb slot on the computer and
bill@amddesktop:~$ uname -a
Linux amddesktop 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 03:54:33 UTC
2008 x86
I don't think I can get a much more recent kernel. Thanks for your help,
but I'm starting to be convinced that my device is just not working
right. I'll spring for a newer one when I can.
Best regards,
Bill
In advanced mode jackd says:
...
ALSA: could not start playback (Broken pipe)
There should be an error message in the system log.
I'd guess that this goes away if you update to a newer kernel, or if you
connect the device directly to the computer instead of through a hub.
HTH
Clemens
19 Mar
19 Mar
5:01 a.m.
Bill Allen wrote:
Clemens Ladisch wrote:
The "could not start playback (Broken pipe)" message indicates that the
USB host controller driver was not able to allocate enough bandwidth on
the bus, for some reason. This has nothing to do with the hardware.
Please show the error message in the system log.
There have been some changes in the EHCI driver related to audio
playback between 2.6.22 and 2.6.24; you might want to give it a try.
Regards,
Clemens
Bill Allen wrote:
I'm going into the usb slot on the computer and
bill@amddesktop:~$ uname -a
Linux amddesktop 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 03:54:33 UTC
2008 x86
I don't think I can get a much more recent kernel. Thanks for your help,
but I'm starting to be convinced that my device is just not working
right. ALSA: could not start playback (Broken pipe)
There should be an error message in the system log.
I'd guess that this goes away if you update to a newer kernel, or if you
connect the device directly to the computer instead of through a hub.
7:37 p.m.
Clemens Ladisch wrote:
Bill Allen wrote:
The "could not start playback (Broken pipe)" message indicates that the
USB host controller driver was not able to allocate enough bandwidth on
the bus, for some reason. This has nothing to do with the hardware.
Please show the error message in the system log.
Sorry I'd forgotten about that. Here's what I get:
Mar 19 18:33:23 localhost kernel: [ 447.882290] cannot submit datapipe
for urb 0, error -90: internal error
There have been some changes in the EHCI driver
related to audio
playback between 2.6.22 and 2.6.24; you might want to give it a try.
I will.
Thanks and regards,
Bill
20 Mar
20 Mar
5:09 a.m.
Bill Allen wrote:
cannot submit datapipe for urb 0, error -90: internal
error
This is something completely different; the driver doesn't use a correct
packet size. Another kernel won't help.
I'd guess the maxpacksize entries are missing from the quirk.
Please try the patch below.
Regards,
Clemens
--- linux/sound/usb/usbquirks.h Wed Mar 19 08:21:32 2008 +0100
+++ linux/sound/usb/usbquirks.h Thu Mar 20 08:49:03 2008 +0100
@@ -771,6 +771,7 @@
.attributes = 0,
.endpoint = 0x01,
.ep_attr = 0x01,
+ .maxpacksize = 0x120,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
@@ -788,6 +789,7 @@
.attributes = 0,
.endpoint = 0x82,
.ep_attr = 0x01,
+ .maxpacksize = 0x120,
.rates = SNDRV_PCM_RATE_CONTINUOUS,
.rate_min = 44100,
.rate_max = 44100,
5865
days inactive
5905
days old
linux-audio-user@lists.linuxaudio.org
33 comments
17 participants
participants (17)
-
Alex Polite -
Arnold Krille -
Bill Allen -
Clemens Ladisch -
Dominic Sacré -
Florian Weimer -
Fons Adriaensen -
Frank Barknecht -
Hartmut Noack -
hollunder＠gmx.at -
James Stone -
Lee Revell -
Paul Davis -
Paul Winkler -
Pieter Palmers -
Sharp Hall -
Thomas Skellund