Mixmonitor for recordings

[Op3r]

I was wondering if we could use MixMonitor so that we dont need wait for the files to merge and thus saving as some processor and stuff.

just an Idea

[mflorell]

it's hard on the CPU, and as with everything that is hard on the CPU we do not want to do it when pushing a system. Especially if there are many recordings happening at once.

[kchung]

In addition to this, perhaps we can modify our mixing script to use 'nice' to further be nice to the CPU at the expense of slower processing.

[mflorell]

I was just thinking about that, since it only works on Linux kernels starting with 2.6 there would have to be a check on the kernelversion before automatically using nice.

If you just want to add it to the script now, just add "nice -n 17" before the soxmix comand in the AST_CRON recording mixing scripts.

[kchung]

horray for 'smart people think alike'!

You can also do it for scripts that call 'lame' too.

Since others have been running vicidial on freebsd, does anyone know if freebsd has similar function?

[kchung]

This has been added to mantis: http://www.eflo.net/VICIDIALmantis/view.php?id=57

[hotdog0627]

is it advisable to use nice?

is it ok to use MixMonitor and Nice and will not greatly affect vicidial and recording stability?

[mflorell]

I have not tried this, and do not know the proper way to do something like that since with MixMonitor the mixing is triggered within Asterisk.

[explidous]

We have succesfully used nice in mixmonitor scripts and it works nicely with lame as well...
Best results are however with using schedutil to assign processes to dedicated processors. This way you can assign Asterisk its own processor(s) which will not be affected by anything else when properly set up.

[gardo]

@explidous

have you tried implementing mixmonitor in the recording scripts of vicidial? recording all calls in the default wav format causes bottlenecks in the harddisk. i'd rather go for higher cpu load than the harddisk bottleneck since a more powerful cpu can compensate.

[gardo]

matt,

where in astguiclient/vicidial is the part where recordings are called if recordings are set in the campaigns? what script?

[mflorell]

recordings are called in the www/agc/vdc_db_query.php script, and it places a call to the 8309 extension where the recordings actually happen.

One more important thing to mention, if you are doing ONLY vicidial recording, you do not need to mix recordings at all. You can use the AST_CRON_mix_recordings_VDonly_DATE.pl script(in SVN) to move just the -in leg of the recording over to an FTP archive server and log the new path to the database.

[gardo]

The primary goal I'm trying to achieve is to change the default recording from .wav to .gsm or something smaller. This way we avoid disk IO bottlenecks in exchange for higher cpuload w/c a more powerful cpu can compensate. Imagine you have 30 agents on 1 vicidial server, all calls are being recorded w/o mixing (just the -in and -out), it still generates a lot of disk IO since it's in .wav format. Compare this to 30 agents recording on .gsm and it lessens disk IO a lot since .gsm is almost 1/10 the size of .wavs.

[gardo]

Since it places a call to 8309 extension which has this entry in extension.conf:

exten => 8309,1,Answer
exten => 8309,2,Monitor(wav,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup

Changing that to this:

exten => 8309,1,Answer
exten => 8309,2,Monitor(gsm,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup

or (for MixMonitor)

exten => 8309,1,Answer
exten => 8309,2,MixMonitor(${CALLERIDNAME}.gsm)
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup

Would this change the default recording format from .wav to .gsm?

[mflorell]

That should work, or you could just use 8310.