Randy wrote:
Exactly what do you mean "will not compile"?
Compile: /kʌmpaɪl/
1. to put together
2. to make by gathering things from various sources
3. to use a compiler to process source code and produce
executable code
Wiktionary

I mean compile (3), as in what you hope to accomplish with the
GCCompiler when you type "make" in a top level source directory.
I mean "will not" as in "produce executable code", in this case
a loadable module. The all-but-vanilla lfs GCC-4.0.2 will not do
this. Debian GCC>=-4.0.2.1 will do it but I preferred to use
3.4.3 and follow the lfs instructions because when it comes to
compiling compilers I'm a novice.
As far as the snd-usb-audio module, I compiled it a s a module
once by mistake and had to put it in the hotplug blacklist file because if that module loaded it prevented my USB Plantronics DSP headset from working. Seems I read in the kernel help about this module that it is now obsolete also.
You're confusing the alsa module snd-usb-audio with the oss module 
usb-audio (which is deprecated). Almost all usb sound devices (with the
exception of a couple of Tascam mixers) use snd-usb-audio. Including your
(I'm sure) wonderful headset. If you're using alsa then you're using
snd-usb-audio, or else the alsa-oss wrappers are sorting out the mess for
you. Here's one way to do it right:

http://homex.subnet.at/~max/ubuntu/#hoary-plantronics

Or maybe, just maybe, the module didn't compile cleanly and was unusable.
lsmod?
> 1. It's easier and safer to patch a single package than to patch the linux kernel.

This is probably true, however, I've never had to patch the Linux kernel to fix a sound related issue.

Hopefully you'll never have to. However if you needed to use snd-virmidi and you needed a rock-solid kernel and you needed a
preemptible kernel, in short, if making sounds was what you did,
then you would have the choices that I outlined.
 
alsa development continues to stampede ahead of kernel versions.

Now, this is really skeptical. My current test build is using
Linux-2.6.14.3 which contains the ALSA Driver version 1.0.10rc1. This is a Release Candidate for the current latest and greatest ALSA stable version (1.0.10). Hardly "stampeding ahead" of the kernel version.
This was poor wording on my part. What I meant is that the current
stable set of alsa packages are intended to work with kernel versions
> 2.6.14. While the current stable kernel version is indeed 2.6.14.3,
to implement it requires incremental patching (correct me if I'm wrong
here) so to all intents and purposes the 2.6.12 series is the current
stable kernel version, headers being as readily available as, say, the
alsa packages. You're using 2.6.14.3 for your test build. I'm assuming
that that means you have a stable build, and if you were using
soft-synths extensively, and perhaps using a USB midi controller to, ah,
control them, and to control your DAW, and stability was of the essence
in terms of not losing your work because of apps crashing, or having
RTC weirdness screw up the timing, then you would need the snd-virmidi
patch.
And in terms of lfs, 2.6.12.5 is the current (official) development
kernel version.

Whatever. Forgive the sarcasm, but up to a point I know what I'm
talking about re using the alsa-drivers. Making sound using linux is
what I spend as much of my time as possible doing, and is the reason
I decided to build lfs. So thanks, from the bottom of my heart, for
editing the blfs book. I appreciate your work, and felt that the least I
could do in return was provide some useful information.

Sincerely,
Jonathan.


Find your next car at Yahoo! Canada Autos
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to