AlsaComplaint

From the ALSA wiki

I am sitting in front of "arecord". My task shall be to record from my USB webcam.

My preparations have been to compile "snd-usb-audio" and check in "/proc/asound/" that the code is active.

I issue "arecord". It renders a whole lot of weird characters to stdout until I press C-c. I issue "arecord --help". I pin down my requirements to "--list-devices" and "--list-pcm" to get what is described as a list of all soundcards and digital devices" and "a list of PCMs". I (initially) have not the slightest clue what the latter is supposed to mean (I know that "PCM" is a TLA for "pulse code modulation" but not much more). I have a solid guess of what the former is to mean, so I type "arecord --list-devices". I get what is captioned a "list of CAPTURE hardware devices". After a first examination I find that I actually get a tree (I think we all know that, generally, a tree is not a list, instead, a list is a degenerate tree ;-) ). The nodes of depth 1 are labeled with "card" and a number. They are associated with a record denoting "subdevices" that appear to be numbered "m/n", where n is a natural number starting from 1 and m is from the range from 1 to n. Please note that all of that is already guesswork on my behalf! The real confusion starts when I examine the list of subdevices. Here is an example:


card 2: Camera [Camera], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

So a "card" holds "devices" which hold "subdevices" m/n where the subdevice record is numbered with an iterator k=m-1 for a given subdevice m/n. While I admire the amount of information in a few lines I also can not but find this also to be an extraordinary amount of confusion in the same few lines. Suppose I want to use this information to actually select a device for recording. Being not the type to memorize commandline option interfaces after first read, I again type "arecord --help". I note the option

-D, --device=NAME       select PCM by name

According to this, a "PCM" is implied to be a "device" (the option is called "--device" while the description says it is to "select a PCM by name"). On the other hand I from the information the "--help" gives me will not be able to address "subdevices" (the option is called "--device"). Also, I have to select a "PCM" in accordance to the option description (it says "select PCM by name").

It appears that even more confusion is held here in a single line!

Since I know now that it is about these "PCMs" I want to have a list of these. So I type "acrecord --list-pcm". Oh. Looks somehow like POVRay! I pipe the output into "less". It does not help. I need a syntax description. Keeping my initial problem in mind (to record a sound) I consitute my intended task as follows: how to derive from the "list of CAPTURE hardware devices" and the "list of PCMs" an identifier suitable for passing as the "--device-name=NAME" option argument "NAME".

How do I do that? I type in "man alsa" with no results. That is a bad sign. I type in "apropos alsa". None of the manpages rendered appear to relate to my problem. Luckily, I have an internet connection. So I go to the website "http://alsa-project.org". I find (do not ask me how, I have been doing that for years and do not know how myself)

http://alsa-project.org/alsa-doc/doc-php/asoundrc.php?company=Generic&card=Generic&chip=Generic&module=Generic#naming

which is apparently what I am looking for. It appears that, in order to have access to what is labeled by "--list-devices" as the "Camera" I have to specifiy a "PCM" of "hw:2,0" (compare this to the ouput I pasted above, I would say that that is the "first device on the third soundcard/device (also, first out of one subdevices)", given that numbering starts with 0). Judging by the example in the website document that explicit subdevice addressing is not required, I issue "arecord --device=hw:2,0" :

Recording WAVE '(null)' : Unsigned 8 bit, Rate 8000 Hz, Mono arecord: set_params:901: Sample format non available

Oh. I begin to get a little annoyed! However, this time, "--help" proves helpful on a standalone basis. I am pointed to the "--format=FORMAT" option and am presented with a list of possible format identifiers. Again, guesswork on my behalf brings some possible interpretations): Operating on waveforms (that ossiclate in the positive as well as the negative domain), being on a PC (which is Little-Endian) and knowing that 32bits is overkill (at least for my purposes) I settle for "S16_LE" (wich I assume to be "signed 16-bit little-endian"). So I issue "arecord --device=hw:2,0 --format=S16_LE".

But something happens. Weird things appear on stdout, I assume them to be capture data, so I type C-c and type "arecord --device=hw:2,0 --format=S16_LE test.wav" instead.

And it works. Phew! From these experiences I come to the following conclusions:

Terminology: "Device", versus "Soundcard/Device" versus "Subdevice" versus "PCM":

An explanation, not as a scientifical textbook but in the least as an intuitive (!) PCM identifier syntax in the in-system documentation should be given. The web document I referred to above provides an approach I find reasonable.
Please generally check the exhaustiveness of information and coherency in in-system-documentation (especially manpages and program help-messages)
For an example of "exhaustiveness", I find the notion of "subdevices" unsatisfyingly explained given that they take so much prominency in the "arecord --list-devices" output. Another example is thte complete absence of documentation for the notion of "sample formats". For an example of "coherency" I refer to my example of an absent explaination of "PCM" identifier format syntax.
Please check terminology against the external documentation (i.e. the website). I found the use of "device" in the help-message of "arecord" versus "Soundcard/device" in the web documentation a little confusing.

A glossary maybe could help. If then one wonders what a subdevice is, he or she can go to the glossary and look up "S".

If these propositions are already met in part or even fully, I apologize. I attempted this report to describe the everyday problem of finding such documentation.

- T. 03/20/2006

I too, have had serious difficulties with ALSA. My via82xxx sound system never worked properly despite spending 100+ hours reading documentation, including the PDFs for the chips themselves. The different versions of the chip required different parameters during module loading, and I may have had a version nobody had previously encountered. Some apps worked and others did not. My requirements are that OSS emulation works for my legacy closed source apps, which I *PAID* for. I do not blame ALSA developers for the quality of their software, because of the limited hardware info that manufacturers provide openly. What I *do* mind is that it is not immediately clear which hardware works 100%, 100% of the time. I have based my last two motherboard choices partly on information found in the ALSA documentation, and in BOTH cases, I've had to disable on-board sound and add instead an ancient legacy 2-channel PCI card.

ALSA's goals of being "advanced" in order to get the most out of each individual chip's capabilities seems to be in direct conflict with making it usable by the majority. I think that the *full* OSS API should be a mandatory part of every ALSA driver, even if it means doing things like emulating mixing and volume in the driver itself. Don't consider it "emulation". The advanced capabilities would still be there, but you would have a lot less frustrated people if the basic functionality always just WORKED for simple applications. It is ridiculous that things need to be tweaked on a per-application basis in /proc or in .dot-files for OSS apps. ALSA is by far my biggest irritation when using Linux. I really, really, really, hate it. Thanks to the developers though, for all their hard work, but please give more thought to the end users, 99% of which just want basic sound.

- P. Curran 6/2005

OSS API has one big fault - it talks directly to kernel, and when you are in kernel, you can not do anything with it. If there is library then there were be less problems. My opinion - remove OSS API, kernel oss drivers and alsa oss emulation from official kernel source as soon as possible.

- P. Zubaj 6/2005

In reply to P. Zubaj above, sound without options is *exactly* what the majority of sound users want and need. I do not want to "do anything with it", I just want the sound data that the application generates to come out of the speakers. OSS worked without problems. Improving OSS backwards compatibility will improve ALSA. Removing it would cause many commercial programs for Linux to be unusable. I totally understand the need for advanced sound capabilities, but ALSA is hurting desktop adoption because even seasoned Linux experts have great difficulty getting basic sound to work.

- P. Curran 6/2005 (using linux since the 1.0.x days)

AFAIK there are two kinds of OSS drivers: 1) opensource - these are in official kernel source 2) oss drivers from 4front

AFAIK opensource kernel drivers can exactly do what alsa drivers can do (some drivers are better in alsa some in opensource oss). These oss drivers if hardware can not support hw mixing will not do software mixing - you have to use soundserver.

Kernel people don't like do thiks like software mixing (or any multimedia processing) in kernel (and I don't like it too - I prefer stability), but OSS api can not be used in user space - this is big fault of original OSS API design). Then there is no other way as to remove OSS from kernel sooner or later, if you want to do more.

Don't get me wrong. Alsa is not perfect, but is not worse than original oss in kernel drivers, but has power to improve (which is not case with OSS API design). This needs only some work on userspace alsa

Many of problems on alsa are problems with mixer settings and many of these mixer problems are caused by wrongly writen mixer apps.

Big percentage are problems releated with OSS API design. And some are user problems (mostly caused by lack of documentation)

If you compare alsa to oss then compare it to opensource oss drivers not to 4front closed source drivers (they have diffrent implementation decisions and alsa can't go this way) - this is for oss emulation - if alsa apps do not work, then this is alsa bug.

- P. Zubaj 6/2005

This potential ALSA user has also found himself utterly frustrated in trying to get the simplest of configurations to work. Are there *no* native english-speakers involved at all? The docs are really absymal.

[edit] 2005-05-12

Jamie Zawinski Switches to Mac OS X

"After a disappointing experience with sound, Jamie Zawinski has finally given up on desktop Linux and switched to Mac OS X. The future of apps like xscreensaver and Gronk is now ``highly ambiguous. He has already ditched a free/open platform before, but he seems a lot angrier this time. Indeed, twisted by the Dark Side of the Source, young Zawinski has become."

http://jwz.livejournal.com/494040.html

This is a very irate ex-ALSA user complaining to the alsa-user list. Judge for yourself the merits of the complaint versus a very good response from Dennis van der Meer. First the complaint then the response from Dennis.

You motherfuckers won't help me, ALSA has shitty documentation, and there is NO godamned documentation on half of it. I hate ALSA and I don;t even use Linux any more because of this - you motherfuckers want to stick this shitty sound system in all distros and kill off OSS - wich has everything (even 5.1 audio) working by default. Thats right, you want easy 5.1 that requires NO configuring, use OSS. You think people would use windows if they had to hack 20 fuckkin lines of modules.conf? Fuck no. And you need to fix your suppport page, I have emailed you all 10 or 12 times and none of the addresses are any good.

Hi,

Even though I probably shouldn't go into this I will bite. I admit that the alsa documentation is not very good. Although I consider myself rather good at Linux (I use Slackware and compile a lot from source) I had a lot of trouble getting Alsa to work properly on my system. In fact it took me several months to get my card working as I wanted it to work. So that was from absolutely no driver support for my Terratec Aureon Space 7.1 to full support. I am actually amazed by the fact that the drivers were so quickly written once the specs were available.

I don't give up very soon and that is probably what got everything working in the end. If you want something fixed then please ask for it nicely. I have done so numerous times and although I didn't always get a quick response it was ultimately this that got me my working sound card. I know it's not always easy hearing all the usual stuff like "RTFM" and "if you want something fixed then code it yourself" and for normal users (read: Windows users) they only want something that's called "setup.exe" and only require next, next, next, finish and maybe a reboot and it all works. Unfortunately it doesn't work like that with Linux. But it's getting there. Alsa will be included in future kernels (2.6.0 and above) and will improve even more from that point on. Hopefully it will become the standard soon so we won't have to worry about OSS, Alsa or any other sound system out there and just use Alsa. And as for the documentation, I'm willing to put my experiences on paper to help people who have the same soundcard to have an easy setup method. Even though I have gone through months of troubles doesn't mean that everyone else has to. And I'm sure that other people can do the same.

Bottom line: If something is not working, then if you cannot fix it yourself, please report what you have done so far to get it working and what it is you are trying to do. Include error reports and logs and if there are bugs they will get fixed. If there are configuration problems then I'm sure that someone will be able to help but shouting that everything is crap is not the way to solve things. - DennisVanDerMeer

The original poster continued with another message to help clarify his position in a more civilised tone.

First, for all those who feel I am a moron, I HAVE used the link at the bottom of the screen - the unsubscribe link. I am not stupid. There is an error with the server and my address for some reason that will not take me off the damn list.

Second, yes, I am quite pissed. Yes, I am more than capable at RTFM, I have been a Linux system admin for 5 1/2 years now. I genrally use Slackware/and Solaris and therefore have no need for ALSA. But I have come to like SuSE lately (even though most my personal systems have now been replaced with G5's) regardless of the dissapointung fact that using OSS on SuSE is a challenge.

My point is: I would like one person to show me a link to some easily locatable documantation that will show me right now how to enable 5.1 audio on a SB Live 5.1 - rather than just get an annoying buzzing sound from the center. Can you even find one? My point exactly. The fact that the Linux community has decided to replace a perfectly good working sound system (that is desktop and n00bi freindly) for one that is sparsely documented and has many prevailing bugs at the moment is what I find to be a demonstration of "pure moron" - so take a look at the big picture before jumping on me.

Excuse me cutting in here:

I have a 5.1 live! too. The reason you have the fuzz coming out of the center speaker is because your spdif is switched on. If you mute/turn off the spdif you will get 6 channel analog output as expected. However I would recomend you buy yourself a digital decoder. Dolby Digital is very cool!!!

Does anyone know how to set iec958 as the default output for everything. Obviously everything tries to use the default device, and while some configs I can change to use the spdif, others I cant...... No sound in savage ;-(

back to original poster...........

For now, I am happy with just My G5 - Apple has a revolutionary concept - you control the surround sound settings with a bunch of simple and easy to use buttons and sliders, thats cutting edge stuff for some of the Linux hackers (as brilliant as they are) . Of coarse, most Linux hackers think it is evil to use GUI...... once again, were taking a step BACKWARDS here.

Sorry for the confuson, Dean

Yet another response to Deans complaints from DaveNeuer...

My point is: I would like one person to show me a link to some easily locatable documantation that will show me right now how to enable 5.1 audio on a SB Live 5.1 - rather than just get an annoying buzzing sound from the center. Can you even find one?

I'm a former Linux sysadmin, as well as a kernel programmer, and I have to admit that I find ALSA one of the most confusing aspects of the kernel/userland system on Linux. I think that everyone on the list can probably agree that the documentation is "suboptimal" to say the least.

However, it's a free system. AFAICT, there are exactly two people (Takashi & Jaroslav) PAID to do all of the kernel stuff, all of the userland stuff etc. Everything else is based on volunteer effort, and as is always the case in OSS, most volunteers probably want to focus on getting their card/app working. That's why the wiki is such a valuable resource; it gives people an *easy* way to quickly add whatever knowledge/advice they've gained so that everyone can take advantage of it.

Yes, it's a pain to search the wiki rather than have one official "Everything You Could Ever Need to Know About ALSA" document. But until someone steps up and creates such a document -- and I am thinking about doing something along those lines once I understand ALSA a little better -- it's the best we've got.

For now, I am happy with just My G5 - Apple has a revolutionary concept - you control the surround sound settings with a bunch of simple and easy to use buttons and sliders.

Apple has about 5 hardware configurations they have to support, and that probably entails only 2 sound chipsets. Linux/ALSA supports scores of souncards on multiple hardware PLATFORMS. There is no comparison of the level of effort required to do what Apple does w/ the incredible amount of effort put in by the ALSA team.

Also, notice how much more expensive your G5's are than a standard PC setup? You PAY for that ease of configuration/use. What did you pay for ALSA? Nothing.

Certainly, ALSA could use a nice GUI tool which would handle common configuration of a few common cards/chipsets. But ALSA is complex partly because it is so flexible. ALSA supports simple stereo cards for MP3 playing, and expensive oodles-of-channel cards at cutting-edge low latencies for professional-level sound recording. I would not trade it for a 12-foot-pile of G5's.

I don't mean to minimize anyone's frustration (believe me; I've been frustrated w/ ALSA for months myself -- look at some of my past posts if you doubt it).

But rather than bitch at two hard-working guys and an army of volunteers whose compensation for their ALSA work is certainly not commensurate w/ the volume and quality of the work which has been produced, try

a) helping; b) providing constructive criticism or reasonable suggestions; c) PAYING someone to develop the features you need, or d) choosing to use something else, quietly, and LEAVE US ALONE.

Oh, and a "thank you" would probably be appreciated, too.

Dave's 2 cents

In a message: [[[Agnula]]-Users] Hello group!

I just subscribing to this group. My name is Michael and I'am a Musican/Multimedia artist with strong computer skills. Please excuse my bad english. I'am not a Linux freak. DeMuDi is too much for me, because of the missing hardware detection. Maybe the Agnula dev-crew can take a look at Knoppix, a Debian-based liveCD Linux with a very good hardware detection at http://www.knoppix.de But I will install ReMuDi, I just download the current "shrike" ISOs and install it on my daily-use multimedia workstation.

I use WXP for productivity and creative design, with Cubase SX, Flash, Vegas Video and the typical creative-designer tools. I need a good workflow, a stable machine, a easy to use os.

I just tries Suse Linux 8.2, allmost all of my hardware, my multichannel audio-interface, my tv/video and my dual-head monitoring system was supported right. But I wasn't very satisfied, I can't get to work with "the jack" so I wasn't able to work with ardour or muse. Also the xine-player wasn't ok, not really able to play DVDs without problems....

So I'am hoping, the ReMuDi will be a better experience. My skills in linux: I know where to search for an answer, I know some bash-commands and I know how to compile a program. But when I get crazy because of missing libs, I mostly give up. It is to complicated for a simple artist-mind, because i want to make and produce music and I have no patience to find out what version of a missing lib is right or shall i install all, but then the dependencies get lost or something. After a few days I deleting this linux from my hd and work on Windows.

But people like me, creative artists and multimedia producer seemed to be the target users for a project like Agnula. And this is the reason why I joined in this group: I want to exchance and parcipate in the devlopment of a free multimediaOS, give my experience and my expetations.

-- MetaLab 20031031

MarkConstable posted this as a reminder that ALSA and linux audio have some ways to go before it's comfortable for ex-windows users, and, the first response by DennisVanDerMeer is a good way to defuse any hysteria and to explain that some patience is needed. The 2nd message by MetaLab is a good example of typical expectations of linux audio.

In case you are assaulted like this again don't forget to mention that while OSS may be simpler for the average user it is by no means the pinnacle of audio driver design. ALSA may be difficult but it is also designed to allow serious professionals to do their work. There is no way that professional audio on the Linux platform will be taken seriously if it only caters to people who want to play games and hear their email go ping at the same time. Now that ALSA has been adopted into the Kernel and OSS has been marked as deprecated we are seeing a lot more developers get onboard making it a more robust and stable environment.

-Patrick Shirkey

I'm a Linux n00bie so I still need a lot spelled out for me. I just want a nice little document to tell me how to get my external (musical) keyboard hooked up to my PC and play through my PCM via a softSynth through MIDI. problem is I can't get ALSA to do much of anything. It's compiled and installed, but now what? I don't mind having to edit a few conf files but where do i start?

-Kyle Reed

Kyle, use the shell utility called aconnect to connect your external keyboard to what ever i/o ports ALSA is managing for you. I'm not sure what softsynth you have on board so have a look at the TiMidity page too.

The correct information flow for flames: "You ***** *** ***** my card does not work as it should" >> support@cardmfg.com cc:support@distro.com "Idiot *** **** *** **** this ALSA thing is to hard to use" >> support@distro.com Note, the people reading the mail is probably not the people in charge. -John Nilsson

I'm a sysadmin, I use redhat 9.0, and I just got the new 2.6.0 linux kernel. I'm trying ALSA for the first time. Here's what I want to see:

Which options to enable in the kernel (the new kernel xconfig menu system is hard to navigate)
If I'm using modules (which I am), which 'modprobe' commands to run. (I'll fix modules.conf/modprobe.conf later)
Which files (in /dev and /proc) need to exist, and how to create them if they're missing.
A simple command to test things ("mpg123 somemusic.mp3")

I found 'aadebug' on the front page of this Wiki, and it helps; it says that /proc/asound and /dev/snd are missing. That's nice, now how do I create those files?

And alsa-tools and alsa-utils look like they could be merged. (What's the difference between tool and a utility?)

Does anyone have an rpm for all this? -P Fudd

Yo Mr Fudd, here's a an example of my .config... (grep SND /usr/src/linux/.config)


CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y

And seeing I have a SBlive card I also selected this option in the PCI card section...


CONFIG_SND_EMU10K1=y

Note: you can directly edit the .config file with any plain text editor and this can be simpler sometimes when most of the .config is to you liking but you need to alter just a few options.

For modprobing, just installing the actual sound card driver will also install most of the dependant sub-modules so, in my case, a modprobe -a emu10k1 would be all I need if I did not compile these modules into the kernel. I do, however, still need to manually install the two OSS modules above.

The /proc items are automatically created and the /dev ones would be if you (your distro, that is) were using devfs, if no devfs then there is a script included somewhere in the ALSA distribution called snddevices that will set up the required /dev devices. You could cd to the top of your ALSA source tree and type find -name snddevices to locate the script.

Your ALSA test is Ok except I think mpg123 is a non-ALSA program so it would really be testing the OSS (the previous linux sound system) emulation so a simpler test would be to use aplay some.wav if you happen to have a wav file handy.

If the aadebug script shows the /proc and /dev items existing then you are almost there and sound should be ready to test.

Don't forget to run alsamixer and unmute (m) the master and PCM volumes and use the up arrow to put them both up somewhere over 50%. I find both set to the low 50% range suits my headphones plugged directly into the back of my old SBlive.

Excellent summary!

There's one small gotcha that I've found in the past: editing .config and then typing 'make bzImage' used to skip an important step (updating config.h).

Now, after editing .config, I run:

 yes  | make config > /dev/null

and then I can get on with the rest of the steps. It just presses 'enter' for all questions. Then config.h gets updated. This was necessary for me to automate the building of my kernel repeatedly. I'm reluctant to try swapping .config files between kernel versions though.

Note: This step may be unnecessary for 2.6.0 kernels. Fortunately, it won't hurt anything either way.

-P Fudd

Ah, there is a make oldconfig option to directly take care of your workaround above. It's a little better in that it only expects a y/n response for items in the new kernel that did not exist in the old config but otherwise keeps the settings as they were. So it's Ok to copy the current .config to somewhere safe, like /boot/config-2.*.*, and then copy it back into a new freshly unwound kernel source code tree... and then do the make oldconfig trick. This applies to the 2.6 kernels too, and I've carried a 2.4 .config across to a 2.6 kernel tree and it also seemed to work Ok. There are some bashable script hints in AlsaBuild (very old now).

Ok, got it to work, thanks!

There's a couple of notes:

 aplay is in alsa-utils
 alsamixer is in alsa-utils

They both require libasound

 libasound is in alsa-lib

And the devices in /dev are created by snddevices

 snddevices is in alsa-driver

As a side note, alsamixer is *full* of scroll bars. Hunting down the PCM one took a little while. And everything starts off muted, probably a good thing, no noisy surprises when you start. Oh, and this is an emu10k1 as well.

Aplay didn't like my first wav file, which was the start.wav file from windows98; it just produced a click. The first test that worked was 'mpg123 somesong.mp3'.

I finally figured out what to put into my /etc/modprobe.conf (linux 2.6) file to get sound to load automatically when devices are accessed it. Actually, that's not quite true; I messed around until it worked, and haven't touched it since. The greatest tool is a patch to the modprobe source that logs all requests for modules. The modprobe for 2.4 had it, in that if you create a directory called /var/log/ksymoops, you get a log of all modules installed, plus a bunch of other stuff useful for debugging kernel problems. Initially I had written a shell script to replace modprobe, log arguments and then call the real modprobe. I kicked myself when I discovered the built-in logging afterwards.

And the /etc/modprobe.conf stuff is:


alias char-major-14 soundcore
alias sound-service-0-3 snd_pcm_oss
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && { /usr/sbin/alsactl restore > /dev/null 2>&1 || :;}
remove snd-emu10k1 { /usr/sbin/alsactl store > /dev/null 2>&1 :;}; /sbin/modprobe -r --ignore-remove snd-emu10k1
# /dev/aloadC0:
alias char-major-116-0 snd-emu10k1
# /dev/dsp:
alias sound-slot-0 snd-emu10k1
# /dev/mixer0:
alias char-major-14-0 snd-emu10k1
# /dev/dsp0:
alias char-major-14-3 snd-emu10k1
# /dev/mixer1:
alias char-major-14-16 off
install sound-service-0-0 /sbin/modprobe --ignore-install sound-service-0-0 && { /bin/aumix-minimal -d /dev/mixer -f /etc/aumixrc -L >/dev/null 2>&1 || :; }
remove sound-service-0-0 { /bin/aumix-minimal -d /dev/mixer -f /etc/aumixrc -S >/dev/null 2>&1 || :; } ; /sbin/modprobe -r --ignore-remove sound-service-0-0

I'm sure there's a nicer way to do it, but I have to leave it for now, and do some work.

-P Fudd

I understand the rage at the top of this page, at least OSS worked. I have been fighting alsa for over a week with out any results or any help. There is absolutely no explanation of what the permissions are supposed to be for this nightmare.

This is a fairly new installation of Slackware9.1 with a 2.4.22 kernel. I have about five years experience on redhat6.0, 6.2, & 7.1.


root@wmr_srv01:/home/wmr $ aplay -D default  /usr/lib/mozilla-1.4/res/samples/test.wav
Playing WAVE '/usr/lib/mozilla-1.4/res/samples/test.wav' : Unsigned 8 bit, Rate 22050 Hz, Mono
root@wmr_srv01:/home/wmr $

This crap works from root, yet it will not work from a non root account


wmr@wmr_srv01:~ $  aplay -D default  /usr/lib/mozilla-1.4/res/samples/test.wav
ALSA lib pcm_hw.c:1055:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Permission denied
aplay: main:484: audio open error: Permission denied

Your alsa has just about the worst documentation of any linux package I have ever read. It remind me of microsoft's non-help files.

From what I have seen so far, you have four or five years to get out of alpha. It seems to me that this was thrown together in chaos by chaos. This reminds me of the sub-standard products sold for microsoft OS's.

alsa-project.org does not seem to have an email address, Does that mean they do not give a damn.

I try to answer this calmly. Go to alsa-project.org and click on "Mailing Lists". Subscribe and ask your questions there. Alternatively check the FAQ014.

Then read a book or tutorial on file permissions.

The standard way is to chmod 660 everything in /dev/snd. Also chown them to root:audio [the group audio must exist]. Then add your user account to the group audio. relogin and you should be set. Do the same with the OSS emu device files in like /dev/dsp, /dev/dsp0, /dev/mixer, etc. See the OSSEmulation for a list of device files.

damn, rtfm! ;)

I HAVE READ YOUR DAMN SORRY EXCUSE FOR F-ING MANUALS. THE ALSA DEFAULT INSTALLATION SETUP ALL OF THE SOUND DEVICES TO SYS GROUP. AN AUDIO GROUP WAS NOT SETUP. I UNDERSTAND FILE PERMISSIONS, YET I DO NOT UNDERSTAND LOUSY INSTALLATIONS OF POORLY DESIGNED SOFTWARE. BTW the users are in the sys group.

Thanks for the abuse!

No prob you're welcome. i'll add more smileys next time.. maybe you can use less caps then ;) <--- smiley Alsa itself is designed very well. It is extremely powerful and easy to use once understood. Documentation is still lacking as you have pointed out. Installation would be much easier if enough well written docs were available. Since you are a know-it-all, maybe you want to contribute instead of bitching around. :) I mean, it's free!

This wiki could use a good ALSA Setup Guide instead of just pointing to the gentoo one. :)

btw: this should also work with the sys group.. there must be something else wrong on your system. you need to relogin to make addition of your user to a group effective..

Just wasted 4 hours of my life to find out that not only was everything turned down in alsa mixer, but it was also MUTED! Come on guys... At the very least set everything to mid-level by default or give aplay some better output to say... "HEY DUMBASS, YOUR SOUND IS MUTED"

.arj! Ok, I've got all the file permissions set for alsa 1.0.4 -- hell, my users is a member of Audio and the permissions are 777. But I still get permission denied. WTF? It doesn't even tell me which device file it's trying to open when I try to run aplay. It works fine as root, but as a non-root user, it's always permission denied.

The only reason I'm going to spend more than a day of my life trying to figure this shit out is because it's /deprecaited/ in linux 2.6.

This WIKI is a nice thing. Less fortunated users who are no able to "surf" back when a problem appears, or even who would like to distill all the information collected here-in, are quite left alone or forced to do the task in very small blocks as there is no means to (quickly) gather the complete information for offline analysis or processing. (Taking time to parse and reparse all the information without having a ISP coming with a big invoice...)

For this the Alsa-Project should provide a "alsa-doc" package with (even messed-up) Howto, Wiki or what-ever information documents. And it's certain that a good developper is nearly never a good writer to document his own work (knows it too good for being able to explain it efficiently to non-informed users, as he will ommit things evident for him!)

Just spent six out of seven evenings this past week trying to get Alsa running on a Thinkpad 600e. Got the CD to play OK, but never did get XMMS, Rhythmbox or anything else to work. Best I got was static (similar to having an off-tuned AM radio sitting to close to a noisy RF digital source.) No combination of mixer settings, modprobe.conf settings (using FC3) got anywhere.

It is not that I'm a Linux newbie. Been through plenty to keep my server running, configure wireless, build Raids and other projects. Some were slower than others, but all successful. I realize that Thinkpads have a reputation with a CS4610 chip using the 4236 driver, but some 20 hours of work should have got me there, especially with a generous dose of cruising this web site, the Fedoraforum and Googling. Would have been glad to help write documentation but I don't think people are looking for another roadmap for failure.... <G>

Notebooks soundcards are sometimes very hard to configure, because they use custom soundcard wiring, needs quirks, ...

AlsaComplaint

From the ALSA wiki

[edit] 2005-05-12

Views

Personal tools

Navigation

Search

Toolbox