Summary:ASTERISK-03926: chan_alsa can't unload
Reporter:cxseven (cxseven)Labels:
Date Opened:2005-04-13 01:20:11Date Closed:2008-01-15 15:31:47.000-0600
Versions:Frequency of
Environment:Attachments:( 0) alsa_unload_patch.diff
( 1) chan_alsa.diff
Description:My card's ALSA only lets one process open it for writing.

Preferably chan_alsa would only open the device when it needed to read/write to it, but as a workaround I thought I might be able to load/unload the module when needed even though ring detection and call queueing could get kludgy this way.

At any rate this kludge doesn't work either because unloading the chan_alsa module and then reloading it results in a HANG.


I wish I knew what all those ast_ functions were. Also, what category does this belong in?
Comments:By: Matthew Fredrickson (mattf) 2005-04-13 10:01:26

Are you talking about at load time, Asterisk hangs if you start it and it's already opened by another process?

By: cxseven (cxseven) 2005-04-13 10:56:14

Asterisk hangs when I load chan_alsa.so, unload, & reload chan_alsa.so because Asterisk itself is apparently still holding open /dev/snd/* files. Looking at chan_alsa.c and with my two day's experience it looks like unload_module should be closing the pcm fds. Maybe they linger on in another thread?

Demo of the problem:
/usr/sbin/asterisk -vvvvvc
Asterisk Ready.
*CLI> load chan_alsa.so
Loaded /usr/lib/asterisk/modules/chan_alsa.so => (ALSA Console Channel Driver)
 == Parsing '/etc/asterisk/alsa.conf': Found
 == Registered channel type 'Console' (ALSA Console Channel Driver)
*CLI> unload chan_alsa.so
 == Unregistered channel type 'Console'
*CLI> load chan_alsa.so
Loaded /usr/lib/asterisk/modules/chan_alsa.so => (ALSA Console Channel Driver)
 == Parsing '/etc/asterisk/alsa.conf': Found
stop now

[Asterisk hanging with no response until Ctrl+c]

Asterisk will also hang if I'm currently holding open /dev/snd/pcm* files with madplay. Maybe my card is a bit limited in the number of writers it supports, but it's probably exhibiting a real asterisk bug that wants to be fixed :/

By: Matthew Fredrickson (mattf) 2005-04-13 11:09:07

Try the patch I attached and tell me if it fixes it.

By: cxseven (cxseven) 2005-04-13 11:20:45

Thinking that it was odd that the alsa fds were disposed using regular close() instead of a pcm_ close, I tried changing unload_module slightly. This minor but aggravating bug is now fixed! Now if only chan_alsa/oss could refrain from opening the device until they need it.

I'm attaching my diff - OOPS it looks like you made the same exact change in the meanwhile! Thanks!

PS I believe this bug was further highlighted by my card's refusal to honor the ALSA O_NON_BLOCK flag. It honors it for OSS, though.

edited on: 04-13-05 11:23

By: Matthew Fredrickson (mattf) 2005-04-13 11:32:15

Ok, I'm going to apply that fix and close this out.

By: Matthew Fredrickson (mattf) 2005-04-13 11:34:22

Oh, you might want to read over the coding guidelines.  C++ style comments are a no no. :-)

By: Matthew Fredrickson (mattf) 2005-04-13 11:34:33


By: Russell Bryant (russell) 2005-04-15 03:08:42

fixed in 1.0 as well

By: Digium Subversion (svnbot) 2008-01-15 15:31:35.000-0600

Repository: asterisk
Revision: 5464

U   trunk/channels/chan_alsa.c

r5464 | mattf | 2008-01-15 15:31:35 -0600 (Tue, 15 Jan 2008) | 2 lines

Fixed chan_alsa.c unload bug (bug ASTERISK-3926)



By: Digium Subversion (svnbot) 2008-01-15 15:31:47.000-0600

Repository: asterisk
Revision: 5477

U   branches/v1-0/CHANGES
U   branches/v1-0/channels/chan_alsa.c

r5477 | russell | 2008-01-15 15:31:47 -0600 (Tue, 15 Jan 2008) | 2 lines

fix unloading problems (bug ASTERISK-3926)