[Asterisk-Dev] res_monitor improvement

[Tamas]

Is it possible to use muxmon in similar way as the monitor application?
What I mean is the possibility to define file format, and possible start
an external application at the end of call (like lame if user requires mp3).

Muxmon looks to be a very good choice, however as I can see, it doesn't
support features of monitor. Maybe we should improve it?

Regards,
    Tamas

Brian West wrote:

> If you use monmux the audio before writing it out to disk you'll cut 
> your disk I/O in half.  Then you can also lower that by choosing gsm 
> or something other than raw or wav.
>
> /b
>
> On Aug 14, 2005, at 8:06 PM, Matt Florell wrote:
>
>> I my experience on several test systems using SCSI RAIDs, SATA or IDE
>> drives you cannot reliably handle over 100 recordings at once without
>> loosing audio data even if for a split second. Those audio drops
>> usually show up as a channel_walk_locked warnings in asterisk and you
>> can hear them in the audio file as a noticable missing section of
>> audio. Our systems always use a separate physical drive(s) for
>> /var/spool/asterisk/monitor so other apps IO shouldn't affect the disk
>> response.
>>
>> Different systems have different failing points as far as the number
>> of skips per day, but I have never been able to do 100 concurrent
>> recordings without some loss of audio. Now keep in mind I'm talking
>> about only loosing 0.001% or less of the audio attempted to be
>> recorded for a day, but when you do things like 3rd party long
>> distance switching verification and other types of audio recording
>> where you need 100% of the audio to be there, it become a problem. In
>> these types of application if you lose a half second of audio in the
>> wrong place on a single recording you could potentially loose a lot of
>> business.
>>
>> We have found changing the channel_walk loop from 10 to 20 or 30 can
>> greatly reduce the number of skips, But it would be good to test a
>> system that allowed for a larger recording write buffer to be
>> accumulated if the disk is unable to accept the data at that
>> millisecond for a specific recording..
>>
>> MATT---
>>
>> On 8/14/05, Brian West <brian.west at mac.com> wrote:
>>
>>> You're over thinking this.  Even on a busy system it won't  matter. 
>>> You're
>>> only going to get 600 calls on a box before it starts to break (If 
>>> that
>>> many)... disk I/O should be more than enough to take that many calls.
>>>
>>> /b
>>>
>>>
>>> On Aug 14, 2005, at 7:24 PM, Boris Bakchiev wrote:
>>>
>>>
>>> It is when it comes to writing.
>>>
>>> No buffering at all as far as I can see.
>>>
>>> All data gets dumped to hdd right away.
>>>
>>> I guess linux caching should take care of it, but on a busy system 
>>> I can
>>>
>>> afford to dedicate 1GB ramdisk (or 1GB tmfs) for temporary storage of
>>>
>>> files.
>>>
>>>
>>> _______________________________________________
>>> Asterisk-Dev mailing list
>>> Asterisk-Dev at lists.digium.com
>>> http://lists.digium.com/mailman/listinfo/asterisk-dev
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>>