[asterisk-dev] Asterisk observations and suggestions

[Matt Fredrickson]

Welcome to the Asterisk community!  It's great to see new people
discover it and start to use it for the first time.

Just as an FYI, this mailing list is mostly for code specific and
development related questions and discussion.  For questions regarding
use and implementation of Asterisk, please use the asterisk-users
mailing list.

All that being said, I'll try to answer a few of your questions below.

On Thu, Apr 28, 2016 at 2:52 AM, lope <lopeonline at gmail.com> wrote:
> Hi,
>
> About me
> I'm new to Asterisk. I've compiled 13.6 and I've been using that. I've
> managed to get a bunch of different functionality working and I'm quite
> pleased with it so far. Thanks to everyone who has contributed to it!
>
> Here are some things I noticed, comments/problems/suggestions, which may be
> useful?
>
> file convert ... g726-32 problems:
> `file convert foo.bar foo.g726-32` is extremely fussy about what files it
> will convert.
> It seemed to work fine converting the example file: `file convert
> tt-weasels.ulaw tt-weasels.g726-32`
>
> But when it came to converting an actual piece of music (for moh) I had
> problems converting from these filetypes: wav wav16 mp3 ogg ilbc ulaw alaw
> g722
> I started with a normal mp3 file (44khz 160kbps mpeg1 layer 3 stereo), then
> converted it to wav as follows:
> sox foo.mp3 -e signed-integer -c 1 -r 8000 out.wav
> sox foo.mp3 -e signed-integer -c 1 -r 16000 out16.wav && rm out16.wav
> out.wav16
> From these 2 files, I was able to convert to every other format (that I've
> tested with Asterisk), except g726-32
> These are the errors I got trying `file convert foo.bar foo.g726-32` where
> bar is one of (wav wav16 mp3 ogg ilbc ulaw alaw g722)
> format_g726.c:143 g726_write: Invalid data length 39, should be multiple of
> 40
> format_g726.c:143 g726_write: Invalid data length 39, should be multiple of
> 20
> format_g726.c:143 g726_write: Invalid data length 45, should be multiple of
> 40
> format_g726.c:143 g726_write: Invalid data length 128, should be multiple of
> 40
>
> In some cases I was able to convert mp3 to g726-32 but it was very fussy
> with how the mp3 was encoded.
> For example, when an mp3 was encoded like this, it was accepted:
> lame --noreplaygain -b 560 foo.wav foo.mp3
> This mp3 was rejected:
> lame --noreplaygain -b 560 -q 0 foo.wav foo.mp3
> But even once the mp3 that it would accept was converted "successfully" with
> file convert, the music was all messed up.
>
> The only source format that was *successfully* converted by `file convert`
> to g726-32 was gsm.
> However asterisk has no problem encoding a slin file to g726-32 during a
> call.

Asterisk is extremely picky about file formats.  For many on disk
formats it actually doesn't support all modes or sample rates allowed
by the encapsulation involved.

> Feature request: Filetypes for speex and speex16
> The speex and speex16 codecs do not have any associated file formats and
> thus cannot be read from disk and must be converted during the call. `core
> show file formats` speex/spx/speex16/spx16 is missing.
> I have loaded the speex codec module and `core show codecs` shows I have
> speex, speex 16khz and speex 32khz loaded.
> I don't know much about the Asterisk code but I would imagine adding a
> filetype association for speex would be trivial to implement?

Bugs and (in this case) feature requests should be redirected to
issues.asterisk.org.  Adding some type of filetype for speex probably
would be not be difficult, but I'm not familiar with its bitstream
format and if there are existing file types available.  Usually using
an existing format is better than rolling your own.  See format_wav.c
as an example of an implemented on disk format.

> I might be on the wrong track, but I just thought that my MOH, which is
> about 5 mins long, should be pre-encoded so that I don't waste CPU encoding
> it into the caller's format on every call?

That's always better from a CPU perspective, although you may discover
that it's not such a big deal to transcode on the fly.  Most modern
CPUs can do quite a few number of concurrent transcodes without great
difficulty.

Thanks again for taking the time to leave feedback, and welcome to the
Asterisk community :-)

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA