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
next parent 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.