Am 20.09.2013 15:17, schrieb jg:
Sometimes I see something similar on my systems when several (3 or more)
MOH streams are fed by mpg123. Suddenly some or all streams are
stuttering, but the CPU load doesn't seem to go up significantly.
My CPU load is permanent at 200-250%. I have 7 active mpg123 streams.
On another box running Asterisk 10.8.0, 4x 2.4 GHz, I have 49 active
streams, but they get fed via mplayer instead of mpg123. There the load
is close to zero, but I have to say that I have only 1-2 concurrent
callers there. Strange!
Have you looked at what is happening with the receive queue of mpg123
(pgrep mpg123 and netstat -t -p)?
netstat -t -p shows me each of the 7 IP addresses and Recv-Q has some
bytes listed (55000 - 113000) for each IP. According to man netstat
Recv-Q means "The count of bytes not copied by the user program
connected to this socket". Note the "not". Now, is that good or bad?
I have written a small daemon for myself that watches the receiving tcp
streams and if nothing seems to be happening, simply touches
musiconhold.conf and issues an "asterisk -rx \"moh reload\"". Not nice,
but it works, eventually. When I listen to the same music streams I find
that they are not as stable as one would wish, at least at a time scale
of several hours.
What I do is simply call killall mpg123 every 10 minutes via cron.
Asterisk MOH will restart the process immediately and there will be less
than a second of silence for the listener. Not that elegant but it helps
with hanging audio streams...
When using several moh file classes, I have never hat audio problems.
Me neither.
Thanks!
Markus
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
