asterisk users - Dec 2009 - Asterisk throws error using the alsa module

Hello,


I can't get the sound over alsa to work with Asterisk.
My current version is 1.4.21.2~dfsg-3 running on debian stable.


All settings are the default ones with exception of:


/etc/asterisk/modules.conf:

load => chan_alsa.so
noload => chan_oss.so

/etc/asterisk/alsa.conf:

input_device=default
output_device=default


asterisk is started up and doesn't complain about alsa in the logfiles.

anyway, if i connect via asterisk -r and type 'dial s' i get:


puppy*CLI> core set verbose 20
Verbosity was 0 and is now 20
puppy*CLI> console dial s
    -- Executing [s at local:1] Wait("ALSA/default", "1") in
new stack
    -- Executing [s at local:2] Answer("ALSA/default", "")
in new stack
 << Console call has been answered >>
    -- Executing [s at local:3] Set("ALSA/default",
"TIMEOUT(digit)=5") in
new stack
    -- Digit timeout set to 5
    -- Executing [s at local:4] Set("ALSA/default",
"TIMEOUT(response)=10")
in new stack
    -- Response timeout set to 10
    -- Executing [s at local:5] BackGround("ALSA/default",
"demo-congrats")
in new stack
    -- <ALSA/default> Playing 'demo-congrats' (language
'en')
[Dec  8 18:24:48] ERROR[10571]: chan_alsa.c:693 alsa_read: Read error:
Resource temporarily unavailable



I couldn't find any hints using google... does anyone has an idea?


Thanks,
vitaminx


-- 
mail: vitaminx at callistix.net
www : http://www.callistix.net
irc : #callistix @ chat.freenode.net:8001

On Tue, Dec 08, 2009 at 06:25:46PM +0100, vitaminx
wrote:
> 
> Hello,
> 
> 
> I can't get the sound over alsa to work with Asterisk.
> My current version is 1.4.21.2~dfsg-3 running on debian stable.
> 
> 
> All settings are the default ones with exception of:
> 
> 
> /etc/asterisk/modules.conf:
> 
> load => chan_alsa.so
> noload => chan_oss.so
> 
> /etc/asterisk/alsa.conf:
> 
> input_device=default
> output_device=default
> 
> 
> asterisk is started up and doesn't complain about alsa in the logfiles.
> 
> anyway, if i connect via asterisk -r and type 'dial s' i get:
> 
> 
> puppy*CLI> core set verbose 20
> Verbosity was 0 and is now 20
> puppy*CLI> console dial s
>     -- Executing [s at local:1] Wait("ALSA/default",
"1") in new stack
>     -- Executing [s at local:2] Answer("ALSA/default",
"") in new stack
>  << Console call has been answered >>
>     -- Executing [s at local:3] Set("ALSA/default",
"TIMEOUT(digit)=5") in
> new stack
>     -- Digit timeout set to 5
>     -- Executing [s at local:4] Set("ALSA/default",
"TIMEOUT(response)=10")
> in new stack
>     -- Response timeout set to 10
>     -- Executing [s at local:5] BackGround("ALSA/default",
"demo-congrats")
> in new stack
>     -- <ALSA/default> Playing 'demo-congrats' (language
'en')
> [Dec  8 18:24:48] ERROR[10571]: chan_alsa.c:693 alsa_read: Read error:
> Resource temporarily unavailable
The sound device is being used by something else?

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir

> [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.