EAGI audio while running another application via EXEC

I am testing EAGI for real-time voice analysis and have noticed that when I run for example “EXEC AMD” or “EXEC Background” application from the EAGI script, no audio flows on fd 3 while the app is running and starts to flow again when the app finishes.

Is this a known limitation or it is an error in my usage? I couldn’t find any detailed information on EAGI in the documentation, so don’t know what should be supported and what not. If it a known limitation, what other actions cause the audio to stop flowing? Currently I am using Asterisk 16.2.1 on debian.

I have read many threads here about EAGI, but most are several years old and many of them suggested to not try any real-time audio processing, but it’s 2021 now and I guess things have changed since then.

What are the other options for real-time audio? I have found External media channel since version 16.6, do you think it is better than EAGI? There is also no mention about its limitations in the documentation.

Here is simple EAGI script for the demonstration:

#!/bin/bash
log=/tmp/eagi.log
# Read all variables sent by Asterisk to array
declare -a array
while read -e ARG && [ "$ARG" ] ; do
        array=(` echo $ARG | sed -e 's/://'`)
        export ${array[0]}=${array[1]}
        echo $ARG | sed -e 's/://' >>$log
done

/usr/bin/dd if=/dev/fd/3 of=/tmp/eagi.tmp.out &>>$log &

### or just sleep 10 ###
sleep 1
echo "EXEC AMD"
read line # blocks until silence is detected by AMD
echo $line >>$log
sleep 1
### ###

kill -USR1 %1; sleep 0.1; kill %1
ls -lh /tmp/eagi.tmp.out >>$log

echo "EXEC HANGUP "
read line
echo $line >>$log

exit

What it does is it starts capturing the audio data from fd 3 via dd started as background process. When I have just sleep 10 instead of the echo EXEC AMD , after the 10 seconds, dd has recorded the full audio file.

However with “AMD”, dd stops receiving data on fd 3 as soon as the “AMD” is executed (confirmed also via strace ) and continues after “AMD” finishes. So while “AMD” is running, no audio is recorded. In the above example, the recorded file has just 1 second of audio at the start, then nothing while AMD is running and then 1 second of audio after AMD stops - the recorded file has only 2 seconds.

The AGI application services input and output on the channel and from the AGI script. It can only do that whilst it has control. If you EXEC another application, that application has control, and will have no knowledge of the stream from the AGI. It will assume it has exclusive control of the channel.

In other words, you are observing expected behaviour.

Any chance you could use ‘mixmonitor()’ to copy audio to your output file instead of ‘eagi()/dd’?

You could use the ‘r’ option if you are only interested in the receive audio feed.

The output file could be to a named pipe if your intent is to process the audio in somewhat real time.

We are using EXEC MONITOR into file right now. But this way we can process the audio only after the person stops talking. I can test with a named pipe, hopefully there won’t be any strange buffering/caching delaying the reading of audio data.

The “dd” was just for testing, original application is EAGI PHP script spawning python script (as our STT has only python SDK) which reads the fd 3 in separate process and returns the result back to PHP.

@david551 Right now we are starting recording by “EXEC MONITOR” and then running “EXEC AMD” and both applications run at the same. Is Monitor somehow different in this, so that it can record even while other app is running?

Monitor is explicitly written so it CAN passively record a call while it is doing other things. The same for MixMonitor. That is why they exist.

@sedwards I am trying to use named pipes, but asterisk always removes the file (created by mkfifo) and then creates it as a regular file. I tried both Monitor and MixMonitor (also with the “a” option to append to file and not overwrite it).
Any ideas on how to make it open the existing named pipe?

Nope. Sorry. My suggestion was just a guess.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.