ALSA drivers for USB audio devices

ALSA drivers for USB audio devices

[Jeffrey W. Baker]

Recently on this very list, Paul Barton-Davis proposed that one could
build a driver for a USB audio device entirely in user space.  I think
this is an interesting idea, as I own an Edirol UA-5 USB audio device. 
Naturally I would like to use it with ALSA to acheive the best
performance and lowest latency.

I hope someone on this list can describe how such a driver would work. 
I am not aware of any user-space drivers for ALSA.  If there is one,
that would be a nice example.  Would the driver take the form of a
userspace daemon?  How would the ALSA library communicate with the
daemon?  Or, would the driver instead take the form of a shared library
which ALSA libraries would load?

In the daemon case, I have trouble imagining that a userspace
implementation would acheive low latency.  The client application, say a
mixing board program, would have to write some data to the ALSA PCM
handle, then wait for the daemon to get scheduled.  The latency would be
all over the place.

In the case of a library that ALSA loads, that scheduling problem would
not exist.

In any case, it seems almost MORE straightforward to write an kernel
driver like the other supported output devices use.  A 24-bit/96KHz
stereo audio stream requires driving the USB bus at nearly full
throttle.  I doubt a userspace implementation could deal with it.

Thoughts?

-jwb

PS: even at 16-bit/48KHz the USB audio device driver in Linux 2.4.18
taxes the CPU significantly.


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA drivers for USB audio devices

[Paul Davis]

>Recently on this very list, Paul Barton-Davis proposed that one could
                             ^^^^^^^^^^^^^^^^^
			     Paul        Davis (op.net/~pbd/name.html)

>build a driver for a USB audio device entirely in user space.  I think
>this is an interesting idea, as I own an Edirol UA-5 USB audio device. 

Pray that it follows the "tandards" The existing OSS-based driver is
full of special case code for just about every device so far
supported.

>Naturally I would like to use it with ALSA to acheive the best
>performance and lowest latency.
>
>I hope someone on this list can describe how such a driver would work. 
>I am not aware of any user-space drivers for ALSA.  If there is one,
>that would be a nice example.  Would the driver take the form of a
>userspace daemon?  How would the ALSA library communicate with the
>daemon?  Or, would the driver instead take the form of a shared library
>which ALSA libraries would load?

there are two approaches:

      1) a new low-level ALSA driver that handles interactions
             with a USB audio device, and presents the ALSA "midlevel"
	     code with the normal *internal* ALSA API

      2) a shared library that would be loaded by alsa-lib, based
             on a description in an asoundrc file. this library 
	     would use an existing USB driver that allowed raw
	     "USB packet" I/O - it would format the USB packets
	     in user space based on requests from alsa-lib,
	     and then deliver them to the kernel USB driver.

>In any case, it seems almost MORE straightforward to write an kernel
>driver like the other supported output devices use.  A 24-bit/96KHz
>stereo audio stream requires driving the USB bus at nearly full
>throttle.  I doubt a userspace implementation could deal with it.

the userspace implementation is only a translation layer between the
ALSA PCM API and the USB audio packet standard. it would be an
existing USB kernel driver that would take care of streaming the data
to and from the h/w. i don't think the user space code would have any
problems with this. the kernel driver might, but if so, its a crock
anyway, and needs reimplementing. i don't know either way.

i suspect that it would be faster to write the low-level module, but
more interesting and potentially more flexible to write the user space
library. 

--p

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA drivers for USB audio devices

[Dan Hollis]

On Tue, 19 Mar 2002, Paul Davis wrote:
> >Recently on this very list, Paul Barton-Davis proposed that one could
>                              ^^^^^^^^^^^^^^^^^
> 			     Paul        Davis (op.net/~pbd/name.html)
                                                ^^^^^^

$ telnet op.net 80
Trying 207.29.195.4...
telnet: connect to address 207.29.195.4: Connection refused
$ telnet www.op.net 80
Trying 207.29.195.25...
Connected to www.op.net.
Escape character is '^]'.

-Dan
-- 
[-] Omae no subete no kichi wa ore no mono da. [-]


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: ALSA drivers for USB audio devices

[Jeffrey W. Baker]

On Tue, 2002-03-19 at 14:39, Paul Davis wrote:
> >Recently on this very list, Paul Barton-Davis proposed that one could
>                              ^^^^^^^^^^^^^^^^^
> 			     Paul        Davis (op.net/~pbd/name.html)

My mistake.  Sorry.

> >build a driver for a USB audio device entirely in user space.  I think
> >this is an interesting idea, as I own an Edirol UA-5 USB audio device. 
> 
> Pray that it follows the "tandards" The existing OSS-based driver is
> full of special case code for just about every device so far
> supported.

It supposedly uses some Steinberg driver that supports a number of USB
devices, not all from Roland.  That gives me hope.  However, the ASIO
driver doesn't support 24/96 operation, so this may be a
device-by-device extension.  Duplex operation is limited to 24/48 anyway
because of USB bandwidth.  I won't care as long as it works on my
hardware :)

> there are two approaches:
> 
>       1) a new low-level ALSA driver that handles interactions
>              with a USB audio device, and presents the ALSA "midlevel"
> 	     code with the normal *internal* ALSA API
> 
>       2) a shared library that would be loaded by alsa-lib, based
>              on a description in an asoundrc file. this library 
> 	     would use an existing USB driver that allowed raw
> 	     "USB packet" I/O - it would format the USB packets
> 	     in user space based on requests from alsa-lib,
> 	     and then deliver them to the kernel USB driver.

The latter sounds more workable -- building packets is userspace is not
hard at all, and profiling for performance is more practical.

> the userspace implementation is only a translation layer between the
> ALSA PCM API and the USB audio packet standard. it would be an
> existing USB kernel driver that would take care of streaming the data
> to and from the h/w. i don't think the user space code would have any
> problems with this. the kernel driver might, but if so, its a crock
> anyway, and needs reimplementing. i don't know either way.
> 
> i suspect that it would be faster to write the low-level module, but
> more interesting and potentially more flexible to write the user space
> library. 

Probably less duplication of code as well.

-jwb


_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel