[asterisk-users] Asterisk throws error using the alsa module

[Dave Platt]

> [Dec  8 18:24:48] ERROR[10571]: chan_alsa.c:693 alsa_read: Read error:
Resource temporarily unavailable

I agree, this looks like some form of conflict for the sound device.

The first thing I'd suggest doing, is trying to reproduce the
error with a command-line tool, with asterisk out of the loop
entirely.  You'd use a command such as

  aplay -D default /path/to/demo-congrats.wav

See if it plays back properly.

A "resource temporarily unavailable" error from ALSA would tend
to suggest one of two sorts of conflicts:

[1] A low-level (e.g. IRQ) conflict for the sound device itself.
    This could occur as a result of motherboard misconfiguration...
    for example, if the sound card/chip was configured to use
    IRQ 2 or 3, and there was also a serial port in use which
    made use of this interrupt.  Check (e.g.) /proc/interrupts
    to see if you can find such a conflict.

[2] A higher-level conflict for use of the sound card, e.g.
    between two different (and incompatible) ALSA accesses,
    or between a "native" ALSA access and a user of ALSA's
    OSS driver- or library-level API emulation.

One not-uncommon culprit is having an X Window desktop up and
running.  Some of the newer desktop packages have their own
sound-management architecture (e.g. ESD, the Enlightenment
Sound Daemon, or the JACK audio toolkit, or PulseAudio).
These management systems often open the underlying sound
device (in a non-shared mode) and then provide their own APIs
for arbitrating access, mixing multiple outputs together, etc.,
and a separate "native" ALSA access from Asterisk will often
be unable to share access to the card.

When doing "native" ALSA access, it's often possible to share
access to the sound card (playing back two or more sounds
simultaneously).  Some sound cards have this capability in
hardware.  Many do not... and for those that do not, you can
resolve the conflict by telling all of the playback apps
to use the "dmix" plugin.  This is a software mixer... it
opens the underlying sound-card PCM output in an exclusive-
access mode, and then accepts connections from any number
of ALSA clients and mixes the audio together before sending it
to the sound card.

The trick about "dmix" is that *all* of the clients have to agree
to use it.  If the first client to open the sound card doesn't
use dmix (but opens the default hardware device directly), then
any further clients (dmix or otherwise) will be locked out.
Similarly, if "dmix" is in use. any attempt by an ALSA client
to access the hardware directly will probably be rejected
(unless the hardware itself can do the mixing for it).

On older versions of ALSA, it's necessary to specify the
"dmix" device manually e.g.

   aplay -D dmix /foo/bar/baz.wav

On some more recent versions of ALSA, using the "default"
device will give you the hardware device directly *if*
the hardware can handling mixing... and will give you the
"dmix" device otherwise.

Any sound client which is manually configured to access
the hardware directly (via e.g. "hw:") or the direct
rate-and-format-conversion plugin (e.g. "plughw") will not
be going through the "dmix" plugin.