[asterisk-dev] MP3Player 16kHz

[Jörn Krebs]

2011/5/11 Malcolm C. Davenport <malcolmd at digium.com>

> ----- Original Message -----
> > Hi guys,
> >
> > anyone of you ever worked on development changing the MP3 Player Rate
> > from 8000 to 16000?
> >
> > I have no clue of C programming, but I just went into the app_mp3.c
> > code,
> > changed all values of AST_FORMAT_LINEAR to AST_FORMAT_LINEAR16 and all
> > 8000 entries to 16000,
> > compiled it, tested it, and it worked like a charm,
> >
> > BUT: I have no clue of C code, or how development works, so I am
> > asking you, can please some developer do me a favour and change that
> > in the asterisk 1.8 branch, to have it in the main branch?
> >
> > I think Asterisk now handles the sln16 format perfectly, so if someone
> > calls with e.g. g.711 asterisk will convert that stream into the
> > apropriate format.
> >
> > And now it's time to change the default of using a rate of 8000 for
> > everything and use 16000 instead.
> >
> > O.K. Again now: Can please a real developer have a look at the code
> > and do the change.
> > It is very very easy fix, and it would mean a lot....
> >
> > Thanks, Joern.
>
> Howdy,
>
> Making that change means that anyone who uses app_mp3 who isn't using a
> 16kHz phone will be using additional CPU resources, for the resampling, for
> every call that is somehow tied to app_mp3.  I don't think we can make such
> a change without a large number of people agreeing that it's a good idea.
>  Most people are still using 8kHz phone devices.  So what say everyone?  Are
> most of your calls these days 16kHz calls?  Or, do you not mind burning some
> extra CPU for your 8kHz devices that might use app_mp3 in order that you
> 16kHz devices using app_mp3 sound more pleasant?
>
> The alternative, of course, is to convert the mp3 files into signed linear
> files at 16kHz, since Asterisk has a file format for sln16.
>
>
> Cheers

Hi Malcom,

you are right, 95% of the callers could not use this feature.
So in 95% of the cases this mod would use a bit more CPU power: sln16
-> sln conversion.
Although ... as most of the users use the G.711 codec (I assume), the
question is, if the conversion path from sln16 -> G.711,GSM, G.729 or
Speex even saves CPU. ... I don't know at all?

... But what about if we make that switchable?
Implement a new switch called s for sixteen kHz functionality in the
MP3Player funtion/app?

I don't know how to implement this switch within C, but as far as I
can see, we can easily define a variable with a defautl value of 8000
and turn that into 16000 in case the switch is set, and then use an if
clause for these two lines where it defines the AST_FORMAT_SLINEAR, so
this should be an easy change. ... If everybody is O.K. with that?

I would do the change myself, but I have no clue of C coding, so what
I would do is try and guess, and - I don't know what process to follow
to bring in such a change and through the review board, so I am asking
one of the developers to spend these 10 minutes to do that change for
me? I have a proof of concept at my home PC, so it actually works
(Change all 8000 numbers to 16000 in the code, and replace all
AST_FORMAT_SLINEAR to AST_FORMAT_SLINEAR_16 -> Tested with all
availabe codecs on my system: G.722, Speex WB, Speex, G.711, G.726,
G.729, GSM), so the only thing the developer has to do is implement
that switch and make the value 8000 a variable and set an if clause
around these two AST_FORMAT lines.

Please can anybody do this for me?

Thanks, Joern.