I didn’t see it in the ASL3 user manual, but is the “archivedir=” directive in rpt.conf identical as it was in prior versions?
Carl/K6CRS
but is the “archivedir=” directive in rpt.conf identical as it was in prior versions?
It will be in the next update. Probably put it on the asl-menu at some point, too. Thanks for hanging in there.
1 Like
I appreciate that.
I did get it to work (after poring over the wiki closer), I needed to make sure my permissions were the way they were supposed to be.
Things are much nicer with ASL3…
Carl/K6CRS
I have problems with the recordings, they are distorted. ASL3 on Dell Wyse 3040
PS: Recordings, made when someone connected to the node via DVSwitch, is fine.
And as I can see in file properties, recordings made from DVSWitch has permision rw-r–r–
but recordings made from radio is rw-------
I don’t know what to make of the recordings. It sounds like it’s being sampled at the wrong sample rate.
What did you use (exactly) to convert this recording?
As far as the permissions, just adjust the permissioning on the destination directory with something like
chown -R asterisk:asterisk /the/destination/directory/path
and then chmod the files
chmod u+rw /the/destination/path/*.WAV
This is original WAV file, made by adding archivedir = var/log/asterisk/tmp/1800/
to rpt.conf
examine the file with ffmpeg -i That will tell
you what it is.
Mine ended up being GSM files in a WAV wrapper, which I didn’t want.
That’s why I created a script file that normalizes the files to a more reasonable level with ffmpeg-normalize and then re-encodes them with sox as an OPUS file with a 8kHz sample rate and a 16kHz bitrate.
You could do the same with MP3, but I prefer the flexibility of open source.
Can you share the scrip, please?
Look at this guys link from 2019. This will get you started:
Understand that this was done during ASL2 so you still have to apply the techniques changed in ASL3 to make it work (permissioning, etc).
Carl/K6CRS
i have watched this video and done the steps using debian 12 on ASL3, however, on my node RX wavs (when it is getting a signal over RF) they are all 261 bytes and have no audio. signals from within the node, announcements or from a link are problem free and sound great.
any ideas of where to start looking?
I only run a hub at this moment, and all the links for me are provided by a mux node one-hop away, so I don’t experience the symptoms you have.
Provided everything else is recording properly, it might rise to alerting the devs to take a closer look at where they are pulling audio for the “archivedir=“ configuration.
Audio may be one path in Asterisk for an IAX connection, and a completely separate path for analog audio ingested natively at the node.
It’s all conjecture until someone looks at the code and sees what the difference is in audio handling.
Hello all…I have recently upgraded a node to ASL 3 and am trying to get archiving working as well. I seem to have the same problem as above. The initial recording “wav file” sounds fine if it’s the node’s audio from the system (announcements/IDs) but any audio from someone talking on the node is garbled like the above sample from Andriy_Grin. I also have the script setup to use ffmpeg to convert it to MP3…after conversion I get an MP3 with the same garbled sounding audio. So it seems there’s something wrong with the way it’s initially being encoded.
Has there been any update to this? Is there something misconfigured or is it just in the ASL code at this point and someone needs to make changes to the actual ASL code? I’m not experienced enough to contribute on that side unfortunately, but I surely would love to have archiving working on ASL. Starting to really like the “upgrade” but this is something I feel I must have in the long run. Any information on if it’s being worked on or configuration changes I can do on my end would be greatly appreciated. Thanks all!
Dusty,
Can you take a look at app_rpt GitHub Issue #382. If this looks to be the same problem then it’s known … but not yet resolved. But, if you think the problems you have observed are different enough then I’d ask that you create a “new” issue.
Note: the development team is small, we’re all volunteers, and we’re trying our best to address the reported issues.
Yep that pretty well describes the same thing I’m seeing as well. Duly noted. Thanks for the response WA3WCO I appreciate it!! Totally understand about the small team, I can definitely respect that, no worries from this end…wish there was something more I could do to assist.
Fixed in apt_rpt 3.3.0.
A huge thank you to the developers!
1 Like