Dave.

From your code, I'm a bit unclear as to which part actually takes too long.

Is it this line?

my $response = $ua->get("http://127.0.0.1:8000/speech_to_text/?file_pa
+th=$tmpname.wav");
[download]

... or is there anything else?

I'm not sure how AGI programs work. Maybe you can only send one action per invocation, so you have then to find out when recording the file ended?

print "RECORD FILE $tmpname wav \"$intkey\" \"$abs_timeout\" $beep \"$silence\"\n"; this is the line which is taking time to create file

I would think this takes time to create because it is writing the file while recording. If you record 60 seconds, the file will take 60 seconds to create.

Do you expect something different?

That just looks like a print statement to me. I don't see anything that should "take time". STDOUT is buffered. Buffering can cause a delay in writing to the screen and make it look like something took a long time when in fact it didn't. Add this line: $|=1; at the top of your Perl code. That will turn off buffering.

How is the code you posted related to the act of saving to a tempfile? Or are we supposed to just imagine that part?

Ok, you ask for a temp file to be created in a particular directory and for that temp file to be deleted automatically when $fh goes out of scope.

What does @result = checkresponse(); do?
Where are you using the temp filehandle, $fh?

I don't know how big this .wav file is? Downloading the entire file and then processing the entire downloaded file is one thing. Overlapping the start of processing while the download is still going on is a very different matter. I don't see anything here that reflects that level of complexity.

Update: Out of curiosity, why would you specify your own temp dir? Why not use the system provided one? If your program "dies", a useless file may be left in that directory that standard "clean up" utilities will not detect.

It's hard to tell what you are trying to do, chances are that you haven't the slightest idea either, but I'm going to take a shot in the dark:

is the problem that you cannot reliably tell when has Asterisk finished with the recording?

In that case I'd recommend moving any kind of postprocessing out of the dialplan, AGI handlers etc. Instead, do it in a completely separate process, and use inotify with a IN_CLOSE_WRITE event mask to to monitor for files. In my experience once Asterisk closes a recording it doesn't reopen it, so it's safe to do any postprocessing steps (transcoding, speech-to-text, uploading etc.) on it.