Re: [linux-audio-user] USB sound

Re: [linux-audio-user] USB sound

[Patrick Shirkey]

I have moved this to alsa-devel as it seems more relevant to discuss there.

Speaker to Vegetables wrote:
> Not to be overly pedantic or anything, but putting stuff in the kernel 
> that doesn't have to be there would be the unprofessional thing.

But it will be a driver module right?

> Stuff 
> that goes in the kernel is harder to install and usually harder to use. 

huh?

> More importantly, bugs in code that goes in the OS kernel can easily 
> crash the whole computer, while userland code seldom crashes anything 
> beyond its own little process. 

I don't think it will be included in the kernel until it is sufficiently 
tested and then if there is a bug it will be found much quicker.

>The golden reason for putting anything 
> in a kernel-level driver is when that's the only way to get it to 
> perform well enough.
> 

Good point but then if then we shouldn't have included ALSA if that is 
true. The ALSA code base is large and having the usb midi module as a 
userland app seems to me to go against the precendant set by the rest of 
the modules.




> On Friday 28 June 2002 02:25 pm, Patrick Shirkey wrote:
> 
>>Takashi Iwai wrote:
>>
>>>i could write it soon if there were enough requests and reasons to
>>>do that.  (actually i had a half-finished code.)
>>>imo, however, if a user-land solution really works well, it doesn't
>>>make sense to write a new kernel driver.
>>
>>Ease of use/installation and professionalism. IMO people will be
>>happier if you include it internally. The only reason I can see for
>>it not to be is if an external api has better latency performance.
> 
> 



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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

Re: Re: [linux-audio-user] USB sound

[Takashi Iwai]

At Sun, 30 Jun 2002 03:18:52 +0900,
Patrick Shirkey wrote:
> 
> I have moved this to alsa-devel as it seems more relevant to discuss there.
> 
> Speaker to Vegetables wrote:
> > Not to be overly pedantic or anything, but putting stuff in the kernel 
> > that doesn't have to be there would be the unprofessional thing.
> 
> But it will be a driver module right?
> 
> > Stuff 
> > that goes in the kernel is harder to install and usually harder to use. 
> 
> huh?
> 
> > More importantly, bugs in code that goes in the OS kernel can easily 
> > crash the whole computer, while userland code seldom crashes anything 
> > beyond its own little process. 
> 
> I don't think it will be included in the kernel until it is sufficiently 
> tested and then if there is a bug it will be found much quicker.
> 
> >The golden reason for putting anything 
> > in a kernel-level driver is when that's the only way to get it to 
> > perform well enough.
> > 
> 
> Good point but then if then we shouldn't have included ALSA if that is 
> true. The ALSA code base is large and having the usb midi module as a 
> userland app seems to me to go against the precendant set by the rest of 
> the modules.

it depends on how the interrupt is handled, and how much data is sent
to or received from the device.

usually a hardware asserts interrupts and the driver handles them to
process the data.
in the case of usb midi, there is already a usb devfs layer.
this replaces the interrupts and other hardware-related things with
the standard poll and ioctls.
and obviously the amount of data for midi is far less than audio.

another reason pushing me against the implementation of kernel driver
is that usb midi specification is not followed by all vendors.
apparently, the spec is half-finished.  there is little devices which
can be handeld properly by the existing usb-midi kernel driver without
any workaround.

unfortunately i myself don't have a midi usb device yet, so i cannot
say 100% surely on how much latency this solution works.
but i think that the scheduled thread should work with enough small
latency comparable with a kernel module.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: [linux-audio-user] USB sound

[Clemens Ladisch]

Takashi Iwai wrote:
> 
> Patrick Shirkey wrote:
> >
> > Speaker to Vegetables wrote:
> > > Stuff
> > > that goes in the kernel is harder to install and usually harder to use.

In this case, a kernel driver would be easier to use because it would be
integrated in the ALSA framework. The daemon currently must be downloaded
and compiled seperately. OTOH, the daemon could be added to the alsa-tools
package easily.

> > >The golden reason for putting anything
> > > in a kernel-level driver is when that's the only way to get it to
> > > perform well enough.
> >
> > Good point but then if then we shouldn't have included ALSA if that is
> > true. The ALSA code base is large and having the usb midi module as a
> > userland app seems to me to go against the precendant set by the rest of
> > the modules.

Yes. Most users expect all drivers to be kernel modules. Not being able
to do lsmod/modprobe/rmmod makes diagnosing problems harder.

> another reason pushing me against the implementation of kernel driver
> is that usb midi specification is not followed by all vendors.
> apparently, the spec is half-finished.  there is little devices which
> can be handeld properly by the existing usb-midi kernel driver without
> any workaround.

All devices understand the USB MIDI protocol AFAIK. The problem with most
devices is that the USB descriptors are broken or missing, so some
information must be supplied for them.

> unfortunately i myself don't have a midi usb device yet, so i cannot
> say 100% surely on how much latency this solution works.
> but i think that the scheduled thread should work with enough small
> latency comparable with a kernel module.

USB host controllers (at least UHCI) don't issue an interrupt before the
end of the 1ms frame. The additional latency of either driver or daemon
should be negligible.

On the other hand, there may be issues with task scheduling -- the
daemon uses SCHED_FIFO with priority 99, but so does Timidity.

On the gripping hand, I've now written a kernel driver (see my other
post to alsa-devel). With both available, I predict that nobody will
want to risk the (theoretically) higher latency of the daemon.
Requiescat in pacem. :-)


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf