Fwd: Re: USB Quattro Linux support

Fwd: Re: USB Quattro Linux support

[Patrick Shirkey]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

I'm trying to get some specs from midiman for the usb quattro. They have asked this question. Can anyone fill me in so I can relay the info?

*** There is an attachment in this mail. ***

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

[-- Attachment #2: Type: message/rfc822, Size: 3997 bytes --]

From: tmryan <tmryan@earthlink.net>
To: pshirkey@boosthardware.com
Cc: mike Partridge <mike@midiman.co.uk>, Eric Anderson <eric@midiman.net>, Alex Tinsley <alex@midiman.net>
Subject: Re: USB Quattro Linux support
Date: Sat, 13 Apr 2002 09:41:46 -0700
Message-ID: <3CB85FC9.4556@earthlink.net>

Is there "class driver" support under Linux?

Patrick Shirkey wrote:
> 
> Just checking to see if anything happened with this query. People on the alsa-devel list are getting itchy for usb support these days and you could draw *a lot* of support from the community if the specs are freely available for us to use.
> 
> I know that the midisport is now supported. Can I use that driver to run the midi port on my Quattro?
> 
> --
> Patrick Shirkey - Boost Hardware Ltd
> For the discerning hardware connoisseur
> Http://www.boosthardware.com
> Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/
> 
> --- tmryan <tmryan@earthlink.net> wrote:
> >This is probably Eric's baby.  Eric?
> >
> >mike Partridge wrote:
> >>
> >> Alex,
> >>
> >> Do you know if we have passed information on to ALSA project so they can
> >> write Linux drivers for the DuO?
> >>
> >> Rgds
> >>
> >> Mike
> >>
> >> > -----Original Message-----
> >> > From: Patrick Shirkey [mailto:kotau@firstlinux.net]
> >> > Sent: 29 March 2002 11:54
> >> > To: Mike@midiman.co.uk
> >> > Subject: usb quattro linux support
> >> >
> >> > What is the expected arrival date of linux drivers for this soundcard?
> >> It
> >> > would be extremely helpful if the ALSA team were able to use the specs
> >> to
> >> > write the drivers.
> >> >
> >> > Best regards.
> >> >
> >> > --
> >> > Patrick Shirkey - Boost Hardware Ltd
> >> > For the discerning hardware connoisseur
> >> > Http://www.boosthardware.com
> >> > Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/
> >> >
> >> > _____________________________________________________________
> >> > Want a new web-based email account ? ---> http://www.firstlinux.net
> >> >
> >> > _____________________________________________________________
> >> > Run a small business? Then you need professional email like
> >> > you@yourbiz.com from Everyone.net  http://www.everyone.net?tag
> >
> >--
> >Best Wishes,
> >
> >Tim Ryan - President
> >M Audio / Midiman
> >
> >45 East Saint Joseph Street
> >Arcadia, CA 91006-2861
> >voc: 626-445-2842
> >fax: 626-445-7564
> >
> >website: www.m-audio.com
> >              or www.midiman.net
> >email: tmryan@earthlink.net
> 
> _____________________________________________________________
> Want a new web-based email account ? ---> http://www.firstlinux.net
> 
> _____________________________________________________________
> Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

-- 
Best Wishes, 

Tim Ryan - President
M Audio / Midiman

45 East Saint Joseph Street
Arcadia, CA 91006-2861
voc: 626-445-2842
fax: 626-445-7564

website: www.m-audio.com
              or www.midiman.net
email: tmryan@earthlink.net

Re: Fwd: Re: USB Quattro Linux support

[Paul Davis]

>This is a multi-part message in MIME format...

AKA: This is a message in which the content is about 2% of the message
body :)

>I'm trying to get some specs from midiman for the usb quattro. They have asked
> this question. Can anyone fill me in so I can relay the info?

>Is there "class driver" support under Linux?

I suspect he means something like "audio class", "printer class",
etc. The answer is yes, sort of. What we have right now is a single
USB audio driver for OSS that attempts to implement the audio class
and also contains the inevitable long list of per-device hacks needed
to work around the fact that almost no manufacturer fully complies
with the class specification.

However, its for OSS, which is a problem, and we don't yet have a USB
framework for ALSA worked out, which is even more of a problem. Its
still unclear at this point whether the ALSA framework will be:

      application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver

OR

      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver

the first one is easier to write, the second one is more flexible.

--p

Re: Fwd: Re: USB Quattro Linux support

[James Courtier-Dutton]

Paul Davis wrote:

>>This is a multi-part message in MIME format...
>>    
>>
>
>AKA: This is a message in which the content is about 2% of the message
>body :)
>
>  
>
>>I'm trying to get some specs from midiman for the usb quattro. They have asked
>>this question. Can anyone fill me in so I can relay the info?
>>    
>>
>
>  
>
>>Is there "class driver" support under Linux?
>>    
>>
>
>I suspect he means something like "audio class", "printer class",
>etc. The answer is yes, sort of. What we have right now is a single
>USB audio driver for OSS that attempts to implement the audio class
>and also contains the inevitable long list of per-device hacks needed
>to work around the fact that almost no manufacturer fully complies
>with the class specification.
>
>However, its for OSS, which is a problem, and we don't yet have a USB
>framework for ALSA worked out, which is even more of a problem. Its
>still unclear at this point whether the ALSA framework will be:
>
>      application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver
>
>OR
>
>      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver
>
>the first one is easier to write, the second one is more flexible.
>
>--p
>  
>
Is the biggest problem the need to get alsa to accept Plugable hardware. 
E.g. USB.
Does the current alsa architecture allow for hot plug and remove of 
sound hardware ?

Cheers
James



>  
>

Re: Fwd: Re: USB Quattro Linux support

[Paul Davis]

>>framework for ALSA worked out, which is even more of a problem. Its
>>still unclear at this point whether the ALSA framework will be:
>>
>>      application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver
>>
>>OR
>>
>>      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver
>>
>>the first one is easier to write, the second one is more flexible.
>>
>>--p
>>  
>>
>Is the biggest problem the need to get alsa to accept Plugable hardware. 
>E.g. USB.
>Does the current alsa architecture allow for hot plug and remove of 
>sound hardware ?

thats not an issue with ALSA. pluggable hardware is not part of
ALSA. it would be part of the kernel's handling of USB. at the moment,
ALSA doesn't support any interfaces that allow hot plugging, but i
can't think of anything in the codebase that would cause a problem. i
load and unload ALSA modules very often when i'm doing driver
development, which is isomorphous to handling hot-plugged devices.

whether or not the kernel's support for USB can deal with it, i have
no idea. i would be suprised if the answer was no.

the problem i alluded to is just one of making an architectural
decision. do you consider USB Audio devices to be best supported by a
kernel driver with a USB focus, or an ALSA focus? alsa-lib can handle
either, but in the former case (USB focus), more code has to be
written in user space, and the existing USB audio driver for OSS has
to be moved out of OSS and made more generic.

--p

Re: Fwd: Re: USB Quattro Linux support

[Patrick Shirkey]

--- Paul Davis <pbd@op.net> wrote:
>>>framework for ALSA worked out, which is even more of a problem. Its
>>>still unclear at this point whether the ALSA framework will be:
>>>
>>>      application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver
>>>
>>>OR
>>>
>>>      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver
>>>
>>>the first one is easier to write, the second one is more flexible.
>>>


I think a good example of how ALSA should work with USB devices is the gphoto approach. From what I know of their framework it is along the same lines as the first option.

>
>the problem i alluded to is just one of making an architectural
>decision. do you consider USB Audio devices to be best supported by a
>kernel driver with a USB focus, or an ALSA focus? alsa-lib can handle
>either, but in the former case (USB focus), more code has to be
>written in user space, and the existing USB audio driver for OSS has
>to be moved out of OSS and made more generic.
>

I'm pretty sure that we would have the means currently to see the device through the usb port. (I'll need to test that out) The problem I see is how does ALSA access the kernels USB modules and once that is sorted out we need the specs for the devices. 

So how do we go about writing a "low-level-ALSA-USB-class-driver"?




--
Patrick Shirkey - Boost Hardware Ltd
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/




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

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: Fwd: Re: USB Quattro Linux support

[James Tappin]

On Monday 15 Apr 2002 13:16, Patrick Shirkey wrote:
> --- Paul Davis <pbd@op.net> wrote:
> >>>framework for ALSA worked out, which is even more of a problem. Its
> >>>still unclear at this point whether the ALSA framework will be:
> >>>
> >>>     
> >>> application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver
> >>>
> >>>OR
> >>>
> >>>      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver
> >>>
> >>>the first one is easier to write, the second one is more flexible.
>
> I think a good example of how ALSA should work with USB devices is the
> gphoto approach. From what I know of their framework it is along the same
> lines as the first option.

I think a more exact description of the gphoto approach is:
application<->gphoto-lib<->usb-lib<->low-level-generic-USB driver.

Only the low-level kernel USB drivers and the usbdevfs filesystem are in 
kernel space, beyond that the hardware driving is done via the user-space 
libusb. I'm not sure whether this would have low-enough latency for audio 
use, after all, digital cameras aren't timing-critical for the sort of things 
that gphoto aims to do.


-- 
+------------------------+-------------------------------+---------+
| James Tappin           | School of Physics & Astronomy |  O__    |
| sjt@star.sr.bham.ac.uk | University of Birmingham      | --  \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722                  |         |
+--------------------------------------------------------+---------+

Re: Fwd: Re: USB Quattro Linux support

[Patrick Shirkey]

--- James Tappin <sjt@star.sr.bham.ac.uk> wrote:
>On Monday 15 Apr 2002 13:16, Patrick Shirkey wrote:
>> --- Paul Davis <pbd@op.net> wrote:
>> >>>framework for ALSA worked out, which is even more of a problem. Its
>> >>>still unclear at this point whether the ALSA framework will be:
>> >>>
>> >>>     
>> >>> application<->alsa-lib<->alsa-driver<->low-level-ALSA-USB-class-driver
>> >>>
>> >>>OR
>> >>>
>> >>>      application<->alsa-lib<->low-level-non-ALSA-USB-class-driver
>> >>>
>> >>>the first one is easier to write, the second one is more flexible.
>>
>> I think a good example of how ALSA should work with USB devices is the
>> gphoto approach. From what I know of their framework it is along the same
>> lines as the first option.
>
>I think a more exact description of the gphoto approach is:
>application<->gphoto-lib<->usb-lib<->low-level-generic-USB driver.
>
>Only the low-level kernel USB drivers and the usbdevfs filesystem are in 
>kernel space, beyond that the hardware driving is done via the user-space 
>libusb. I'm not sure whether this would have low-enough latency for audio 
>use, after all, digital cameras aren't timing-critical for the sort of things 
>that gphoto aims to do.
>
>

I think that there is support in gphoto for capturing video streams but I haven't used it so I don't know if that is correct. Anyway if I am correct then latency issues would have been solved already.

I will query with someone from their list and report back unless someone else knows for certain.

--
Patrick Shirkey - Boost Hardware Ltd
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/



>-- 
>+------------------------+-------------------------------+---------+
>| James Tappin           | School of Physics & Astronomy |  O__    |
>| sjt@star.sr.bham.ac.uk | University of Birmingham      | --  \/` |
>| Ph: 0121-414-6462. Fax: 0121-414-3722                  |         |
>+--------------------------------------------------------+---------+
>
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: Fwd: Re: USB Quattro Linux support

[Paul Davis]

>>I think a more exact description of the gphoto approach is:
>>application<->gphoto-lib<->usb-lib<->low-level-generic-USB driver.
>>
>>Only the low-level kernel USB drivers and the usbdevfs filesystem are in 
>>kernel space, beyond that the hardware driving is done via the user-space 
>>libusb. I'm not sure whether this would have low-enough latency for audio 
>>use, after all, digital cameras aren't timing-critical for the sort of things
>>that gphoto aims to do.

If usb-lib is written properly and low-level-generic-USB-driver is
written correctly, there are no latency issues. Latency issues don't
arise from the number of layers of code unless one of the layers of
code is astonishingly badly written. They arise from designs that
buffer data along the way or delay execution of a thread. The system
outlined above doesn't inherently have any such problems.

>I think that there is support in gphoto for capturing video streams but I have
>n't used it so I don't know if that is correct. Anyway if I am correct then la
>tency issues would have been solved already.

Not at all. arecord(1) can capture audio, but it can't capture 26
channels of audio at 64 frames/interrupt. Handling latency is partly
an application issue, partly a kernel issue, and partly a requirement
that libraries in the way don't get in the way. It has very little to
do with whether you can do certain generic tasks or not.

--p

Re: Fwd: Re: USB Quattro Linux support

[Patrick Shirkey]

--- Paul Davis <pbd@op.net> wrote:
>
>
>Not at all. arecord(1) can capture audio, but it can't capture 26
>channels of audio at 64 frames/interrupt. Handling latency is partly
>an application issue, partly a kernel issue, and partly a requirement
>that libraries in the way don't get in the way. It has very little to
>do with whether you can do certain generic tasks or not.
>

Sure. But usb audio devices are limited to a pretty low channel count.

eg. this usb quattro can only capture 1 channel at 96000,24 bit even though it has up to 4 channels. It would seem to be a limitaion of usb as a transfer protocol. 

My point is that the latency requirements for USB devices are not quite as intense as PCI devices. So it shouldn't cause as many headaches to write the code compared to the RME dsp for example.

FWIW:

After Steve's tip (LAU) to turn on usb audio in the kernel (didn't know it existed) and modprobe audio,  I can get this info from 

cat /proc/bus/usb/devices

I haven't been able to send anything to the card yet because it doesn't create any devices in /dev/dspX.

At least we know that Maudio have followed the rules of the usb audio reference this far.

Does anyone have ideas on what I could do next?

--------
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB UHCI-alt Root Hub
S:  SerialNumber=1020
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0763 ProdID=2001 Rev= 1.01
S:  Manufacturer=M Audio
S:  Product=USB AudioSport Quattro (tm)
C:* #Ifs=10 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 1 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=03(O) Atr=09(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 2 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=85(I) Atr=0d(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 3 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
I:  If#= 4 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 4 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=03(O) Atr=09(Isoc) MxPS= 576 Ivl=  1ms
I:  If#= 4 Alt= 3 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=03(O) Atr=09(Isoc) MxPS= 288 Ivl=  1ms
I:  If#= 4 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=03(O) Atr=09(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 5 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=85(I) Atr=0d(Isoc) MxPS= 576 Ivl=  1ms
I:  If#= 5 Alt= 3 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=85(I) Atr=0d(Isoc) MxPS= 288 Ivl=  1ms
I:  If#= 5 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=85(I) Atr=0d(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 6 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
I:  If#= 7 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 7 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=04(O) Atr=09(Isoc) MxPS= 576 Ivl=  1ms
I:  If#= 7 Alt= 3 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=04(O) Atr=09(Isoc) MxPS= 288 Ivl=  1ms
I:  If#= 7 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=04(O) Atr=09(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 8 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=audio
I:  If#= 8 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=86(I) Atr=0d(Isoc) MxPS= 576 Ivl=  1ms
I:  If#= 8 Alt= 3 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=86(I) Atr=0d(Isoc) MxPS= 288 Ivl=  1ms
I:  If#= 8 Alt= 4 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=audio
E:  Ad=86(I) Atr=0d(Isoc) MxPS= 192 Ivl=  1ms
I:  If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  32 Ivl=  1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  32 Ivl=  0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  32 Ivl=  0ms

--------


--
Patrick Shirkey - Boost Hardware Ltd
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/Linux_Audio_Users_Guide/


_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Run a small business? Then you need professional email like you@yourbiz.com from Everyone.net  http://www.everyone.net?tag

Re: Fwd: Re: USB Quattro Linux support

[Roger E Critchlow Jr]

Patrick Shirkey writes:
 > --- Paul Davis <pbd@op.net> wrote:
 > >Not at all. arecord(1) can capture audio, but it can't capture 26
 > >channels of audio at 64 frames/interrupt. Handling latency is partly
 > >an application issue, partly a kernel issue, and partly a requirement
 > >that libraries in the way don't get in the way. It has very little to
 > >do with whether you can do certain generic tasks or not.
 > >
 > 
 > Sure. But usb audio devices are limited to a pretty low channel count.
 > 
 > eg. this usb quattro can only capture 1 channel at 96000,24 bit
 > even though it has up to 4 channels. It would seem to be a limitaion
 > of usb as a transfer protocol.  
 > 

USB-1.1 devices are limited, but USB-2.0 controllers are already on
the market and will be replacing USB-1.1 on new motherboards as the
year progresses.  There's a 40 fold increase in raw bandwidth in
USB-2.0, from 12Mbit/s to 480Mbit/s, so one could imagine plugging
several CD-quality USB-1.1 audio devices into a USB-2.0 hub, or
getting multiple channels of DVD quality from a USB-2.0 audio
interface.

So, sooner or later, your driver,too, will get its chance to be a
latency bottleneck.

-- rec --