[asterisk-dev] [Code Review] fix using external MP3 player with res_timing_dahdi being used as timer causing MOH stream to stop

elguero reviewboard at asterisk.org
Wed Dec 7 13:10:39 CST 2011

This is an automatically generated e-mail. To reply, visit:

(Updated Dec. 7, 2011, 1:10 p.m.)

Review request for Asterisk Developers.


- move the unlock on the class back to immediately following the removal of the member object from the list instead of holding the lock during the entire destruction


The attached patch does the following:

- Changes the load priority so that this module is loaded after the timing interfaces are.

At times, res_musichold.so would work with an external mp3 player.  Through debugging, I noticed that res_timing_pthread was being used at first.  If I only loaded res_timing_dahdi, then the external mp3 stream would start and then pause causing nothing to be heard on the channel. So, if res_timing_pthread was present at start, upon reload, since res_timing_dahdi takes priority as a timer, the timing changed to this timing interface and would just sit there, hence the need for the following change.

- Adds the POLLPRI event for ast_poll, otherwise ast_poll just sits there waiting when the timer being used is res_timing_dahdi.so

- Attempt to cleanup a few items

This addresses bug ASTERISK-17474.

Diffs (updated)

  /trunk/include/asterisk/module.h 346950 
  /trunk/res/res_musiconhold.c 346950 
  /trunk/res/res_timing_dahdi.c 346950 
  /trunk/res/res_timing_pthread.c 346950 
  /trunk/res/res_timing_timerfd.c 346950 

Diff: https://reviewboard.asterisk.org/r/1578/diff


Local box running CentOS 5.7 and dahdi-trunk.

On JIRA, tested by:
Thomas Arimont - 1.8.7
Luke H - 1.8.8-rc3, CentOS 5.5 (32bit), DAHDI



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111207/afa55a13/attachment-0001.htm>

More information about the asterisk-dev mailing list