On Fri, 2003-05-16 at 16:09, Matthias Saou wrote: > Florin Andrei wrote : > > > > I just noticed this morning that they've got updated ALSA packages for > > the most recent Red Hat kernel updates. I'll probably try them out this > > evening, once i download and install the kernel updates. > > "They"? :-) Hey, isn't it a custom, in the French language, to politely address to someone with "vous"? ;-) (the plural for "you") Just kidding. :-) Must have been a brain typo, since my native language has the same "feature" as the French plural "vous". > > If the /etc/init.d script contained in alsa-utils does not work for you > > (there are a few decisions that were made when creating that script > > that, to me at least, seem a bit awkward), then you may try out my > > version of it: > > > > http://florin.myip.org/stuff/alsactl > > Hmmm, in what way is my script awkward? I think it's pretty much useless > anyway if you've put the right entries in modules.conf since the sound > modules seem to be unloaded upon shutdown and reboot, so the state can be > automatically saved then (see my ALSA page). My impression (which may be wrong) is that it's better to force the loading of modules at boot time in a more strict fashion. That's what my version of the script does. With the original script, loading the modules sometimes fails. I am aware that proper statements in modules.conf might fix that, however i wanted a more "bulletproof" solution. With my script, the sound modules are always loaded at boot time, regardless, and you know precisely when that thing happens (by defining when is the alsactl script run by the rc hierarchy). I probably adopted the same strategy as the Red Hat booting scripts which, for example, will always load the USB modules at boot time, even when there's no active device connected to the USB controller. Better have all that stuff ready to go than wait when you're trying to use it for the first time (and possibly fail, in some rare cases). I think i've also seen issues with chkconfig, but i can't say that for sure, since i don't have a copy of the original script anymore. Yes i'm lazy. Otherwise the Freshrpms packages are of an excellent quality. It's just this tiny script that nags me. > > The main ALSA native utility that you'll probably end up using is > > alsamixer, which runs in a regular xterm. Some controls in alsamixer > > have funky and non-intuitive names, hopefully you'll figure out what > > goes where. > > One could also go for the nice gtk2 gnome-alsamixer :-) Good suggestion, thanks. I'll check that out. > > Some media apps on Freshrpms come with ALSA as a requirement, and they > > use ALSA by default, although usually there is a switch to fall back to > > OSS emulation, just in case. gxine/xine is one such example. > > Well, all apps that can have a native ALSA output are compiled with it, as > it only adds a dependency on alsa-lib, which is quite small. Agree. > > Strictly from the perspective of the sound subsystem, ALSA is perhaps a > > technically better solution than the default OSS drivers. However, if > > you're not comfortable with using 3rd party kernel modules on your > > system, then maybe that's not the right solution for you. > > Absolutely. For most users, ALSA isn't worth the effort with the current > 2.4 kernels. Hopefully this will change with the 2.6 series... but when, > who knows!? If you're talking about Red Hat users, i almost disagree. The reason being the very existence of freshrpms.net. :-) You made it easy for many RH users to use ALSA with Linux-2.4. If you just want to listen to napsterized MP3s and that's it, then _maybe_ ALSA is not worth it, for now. But for anything beyond that, ALSA quickly becomes the obvious better choice. Going many steps further on, I could talk about JACK and MIDI sequencers and higher-end-ish audio stuff like that, and how all that is made possible only because of ALSA, but perhaps i should stop here. Oh, yes, and there's the issue of those soundcards, very often semi-pro or pro or just high-quality, which are supported only by ALSA. ;-) > > That being said, remember that, strictly speaking, it's still in beta. > > Hey, no. It's not even in "rc" anymore, it's written "stable" on the > website ;-) <sigh> I wish i could fully agree. Yes... and no. It's clearly better than the 0.5 series. Yet it's still only 0.9, and for good reasons, methinks. It still has microscopic glitches every now and then. Some important cards are still not 100% supported: how'bout MIDI input on Audigy2 Platinum? is that fixed yet? how'bout CD digital input on SBLive? (not CD analog input, because that one works perfectly). But hey, the ALSA developers can only do so much, and there are all those numerous cards to worry about. It's probably a very good field for an open source developer who wants to try out his/her skills at driver tweaking. But i agree it works perfectly for the vast majority of purposes, whether amateur or pro; no wonder why it's going to be the default sound driver in Linux-2.6. Perhaps i should have defined better what "strictly speaking" means. -- Florin Andrei "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato
