All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Shirkey <pshirkey@boosthardware.com>
To: linux-audio-user@music.columbia.edu, alsa-devel@lists.sourceforge.net
Subject: Re: [linux-audio-user] USB sound
Date: Sun, 30 Jun 2002 03:18:52 +0900	[thread overview]
Message-ID: <3D1DFA0C.30504@boosthardware.com> (raw)
In-Reply-To: 200206290818.04426.speaker-to-vegetables@pobox.com

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

       reply	other threads:[~2002-06-29 18:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <B93F5FB3.BCB%Alexander_Carot@gmx.net>
     [not found] ` <s5h8z4zog7t.wl@alsa2.suse.de>
     [not found]   ` <3D1CAA0D.5070608@boosthardware.com>
     [not found]     ` <200206290818.04426.speaker-to-vegetables@pobox.com>
2002-06-29 18:18       ` Patrick Shirkey [this message]
2002-07-01 10:24         ` Re: [linux-audio-user] USB sound Takashi Iwai
2002-07-01 17:07           ` Clemens Ladisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D1DFA0C.30504@boosthardware.com \
    --to=pshirkey@boosthardware.com \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=linux-audio-user@music.columbia.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.