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

[Tilghman Lesher]

> On Dec. 6, 2011, 1:58 p.m., mjordan wrote:
> > /trunk/res/res_musiconhold.c, line 1998
> > <https://reviewboard.asterisk.org/r/1578/diff/1/?file=21688#file21688line1998>
> >
> >     I don't think you can bump the dependency level here to be the same as the channel drivers.  The channel drivers depend on MOH - having the MOH module load at the same time as the channel driver could introduce problems, as the order in which modules are loaded that have the same priority isn't specified.
> >     
> >     The problem isn't that MOH is at the wrong dependency level, but that the timing modules, which MOH depends on, apparently should be completely loaded before loading MOH.
> 
> Tilghman Lesher wrote:
>     We could very easily add another level here, such as AST_MODPRI_TIMER, for all of the timing modules.
> 
> elguero wrote:
>     I was actually thinking the same thing and had already made the changes locally... which do we prefer, AST_MODPRI_TIMER or AST_MODPRI_TIMING_DEPEND?

_TIMING is probably best.  The implication of _TIMING_DEPEND is that the module is a dependency that must be loaded first, before timers.  We could also go with _CHANNEL_DEPEND2, which indicates a second dependency level, just as with _REALTIME.


- Tilghman


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1578/#review4943
-----------------------------------------------------------


On Nov. 14, 2011, 11:02 a.m., elguero wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1578/
> -----------------------------------------------------------
> 
> (Updated Nov. 14, 2011, 11:02 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> 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.
>     https://issues.asterisk.org/jira/browse/ASTERISK-17474
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_musiconhold.c 344329 
> 
> Diff: https://reviewboard.asterisk.org/r/1578/diff
> 
> 
> Testing
> -------
> 
> 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 2.5.0.2
> 
> 
> Thanks,
> 
> elguero
> 
>

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