Sound In General

The following is an attempt to provide an overview of current Linux sound architecture. I am writing in the hope that others may avoid the problems I have had (and still have) in sorting out the alphabet soup encountered when searching for advice. The best way I have found is to have overall picture into which to place the various descriptions of devices, modules, services, and applications that others talk about when giving advice. :-)

It is by no means complete, or even correct; it is more of a sketch. Furthermore, it is too specific to the various drivers and services that I have installed. I'll try to mention alternatives as I am aware of them, but the fact is I have done very little with sound; I never got caught up in the whole mp3 craze, and I usually crash Konqueror when I try to download from heavily java-ised commercial sites. But I did want to run RealPlayer, and have done so.

I would like others to help me fill in the sketch, so go ahead and tear this post to shreds in any way you please.

And if there are any alternatives to Real Player, please let me know.

Early on, I had the problem of launching Real Player, only to have an incomplete window. That is intrinsic to Real Player in the case where you have no working low level sound interface in /dev. It gave me the opportunity to learn about KDE's Ctrl-Alt-Escape key combination, which kills windows. Try it, you'll like it.

So I got ALSA working (included in the sketch). The problem I had with ALSA is that it relies on apmd (the Advanced Power Management Daemon) which, in turn, is not SMP (Symmetric Multi Processing) safe, so is disabled by the kernel at boot time, as I have an SMP machine. ALSA appeared to work, but it was funky. I think it was linked against a service that was present, but dead. I am not sure. The solution came when I found SMP specific modules for ALSA. I am not sure what that changed, as the documentation hasn't changed. The SMP drivers are now included with the Suse 8.0 distribution.

So, now I could get Real Player up, only to get the message "Cannot open the audio device. Another application may be using it." Googling around, I found the problem was apparently with ARTS, the analog real time synthesizer. artsd (the daemon) is started by KDE, although it is not dependent on it in any way. At one time Suse apparently started it twice during init, but now they don't start it until a lot later. The major service provided by ARTS is the ability to accept and mix input from an arbitrary number of programs, provided they are ARTS aware, but it does many other things. It's quite baroque.

Real Player is not ARTS aware.

Googled advice included "use soundwrapper". Never heard of it. (I think it was a utility for use with Gnome's sound server at one point, but now Gnome uses ARTS, I think.)

It was also suggested that one could just wait, as KDE control center allows configuration of ARTS "autosuspend" after a configurable time. It doesn't work for me, as ARTS always has something connected. Artscontrol/artsstatus shows a "cannot autosuspend" message.

One can unload the aRts soundserver. That works, but I was beginning to like the capabilities, so I kept looking.

The answer was to run "artsdsp realplay". It's described as a bit of a hack in "The aRts Handbook", the excellent manual that broke the problem open, found at

http://www.arts-project.org/doc/handbook/

Here's the introduction:

It would have been easier if I had had a clue to the architecture; there are hints it the sound howto, but they are scattered about. I'll try to gather them together and summarize.

Hardware, quite various, and they all need drivers, so;

Drivers are written into the kernel source but can be compiled as modules; people mostly use modules these days. Modules can come from several other sources; the most popular seems to be ALSA, but if ALSA doesn't support your card you can try OSS. There is considerable overlap in their capabilities, and there are other sources for drivers that may support other cards. They provide interfaces in /dev, or for devfs (a different style of interface) in /dev/sound. (Explanation, please?)

How do I find out what these are?

/dev/dsp is a big one. It apparently takes and does D/A conversion on "raw" data. But raw data is in a specific format, is it not? cat /dev/urandom > /dev/dsp produces white noise, as does artscat /dev/urandom. I have a /dev/dsp which is a link to /dev/dsp0. There is also a /dev/dsp[1-3].

/dev/audio is another. Supposedly you can cat something.au > /dev/audio (but not if you're running aRts (Device or resource busy)), so it can somehow recognise a format? I've also got /dev/audio[0-3] Apparently it is a two way device, e.g., if you put raw data on line input, you'll get *.au data out of /dev/audio.

Or does /dev/dsp take wave data while /dev/audio takes *.au data?

/dev/midi; similar situation. (Right now, I have to find out why the midi device list in the KDE control panel disappeared with the last Suse update. Possibly related is that "number of probed devices per mixer" in the same control panel changed from 5 to 1, but I won't find out until the next time I start the X server; may be a couple days.)

There are a whole host of others:

etc.

Does each file format have a different interface?

I want to learn about MIDI, too. I think the aRts manual may give me a start. And the kernel sources could explain a lot, but it looks like a lot of work….

In any case, it looks like applications use these interfaces, but aRts grabs them all and provides a separate API not based on the /dev filesystem, right?

Where does a mixer fit in the heirarchy? It looks like Kmix sits between the interface and aRts and the /dev interface; perhaps Synth controls /dev/midi, Pcm controls /dev/dsp, and CD controls /dev/audio? Then there is IGain and OGain. My SB AWE 64 has a built-in amp, but not all sound cards do, right? So the mixer is tailored to the particular card it is working with?

But aRts needs a mixer too, right? (Since it can work with so many sources.) I see a hint of that in the KDE control center system notification volume control.

Hmm, enough for now. I'll keep reading as I get the time. The idea is to come up with a users overview, so it doesn't need to spend a lot of time on low level stuff, but the user should be able to know it is there. Kmix, for example, doesn't affect inputs to aRts, so (s)he should know what it *does* affect. Likewise, sound hardware is extremely varied, so it apparently affects Kmix. Do I have that right? (Or maybe I should use a different mixer.)

Somewhere in the middle of this, I learned about lsof and fuser, too.

Thank you in advance for your response.

Tom Hardy

please note that the alsa drivers themselves are not dependent upon apmd, although they support apm. support and dependence are different things :)

now you did, it's aka artsdsp.

the alsa devices are located at /dev/snd usually. and in fact, it's a symlink to /proc/asoun/dev, which is created dynamically like devfs but as a procfs.

devfs creates the device files dynamically, and /dev/sound directory is usually chosen for the sound devices, but the directory depends on the devfs' configuration.

note that sometimes devfs will cause problem regarding permissions. most likely it's due to uncomplete devfs configuration. imho, on normal pc machines, the life would be easier without devfs. (it's not true for high-end machines, though)

basically /dev/dsp is used together with proper ioctls, in order to set up the device, e.g. sample format, sample rate, channels, etc. you can cat some files to this device file, but it's not the way to be expected.

anyway, /dev/dsp is the pcm device file for OSS. ALSA emulates OSS, so it works on ALSA, too. the alsa device files are /dev/snd/pcmC*D*.

you cannot cat raw data to alsa's pcm device files. you'll get i/o error if you do that, because the device is not initialized properly via alsa-lib.

/dev/audio is provided just for compatibility. it supports as default mono 8khz mu-law format, which is quite bad for listening to a music.

the device used via /dev/audio is identical with one via /dev/dsp. so, if you use both at the same time, this could result in "device busy".

btw, some audio chips support the multiplex access. for example, you can play up to 32 stereo voices on the sound blaster live simultaneously even without artsd (or esound, whatever), because the multiple playback is supported on hardware. also, ess maestro2, maestro3/allegro, ymfpci, trident, and cs46xx (the experimental support on alsa) give the same kind of function. on such a hardware, you don't need to run artsd for mixing.

the OSS mixer device. you can control a hardware mixer via ioctls.

the OSS sequencer device files. used on some midi sequencer applications. the former is for the low-level format, and the latter is for high-level format, which is more midi-alike.

kmix is the controller for the soundcard, and yes, which mixer elements are valid depends on the hardware. (in the case of alsa, the situation becomes more complicated, because ALSA _emulates_ OSS.)

regarding mixer elements:

artscontrol?

about kmix it's not much. in most cases, you can access to the elements above. (Synth doens't appear always, though). Master, PCM, CD, Line, Mic, I-Gain are usually there.

Takashi

So, here's what I have (with some representative applications):

[1] Kcontrol's midi module listed some output devices until I updated to Suse 8.0, but I didn't know what to do with them. Artscontrol's MIDI manager *does* list them, but no input devices: MIDI 0-0 (64:0) Emu8000 Port 0 (65:0) Emu8000 Port 1 (65:1) Emu8000 Port 2 (65:2) Emu8000 Port 3 (65:3) OPL3 Port (66:0)

[2] "Eats more CPU time than a small CPU-time-eating animal." (From the timidity man page.)

[3] But the aRts handbook says Kmix is aRts-aware. I think I have something fundamentally wrong about what aRts does, i.e., aRts passes through a lot more to the OSS interface than I know. As Kmix works side by side with alsamixer without any problems, I would say aRts doesn't simply grab a /dev/mixer interface.

Enough for now. I have a large quantity of bewildering documents to look at.

Online: www.arts-project.org (especially the handbook) www.alsa-project.org www.boosthardware.com/LAU/guide Google, and newsgroups (here, thank you!)

Local: Sound-HOWTO Sound-Playing-HOWTO Various KDE app manuals, as available

Tom Hardy