Summary:ASTERISK-01810: [patch] Alaw support im app_meetme
Reporter:petersv (petersv)Labels:
Date Opened:2004-06-12 14:50:35Date Closed:2004-09-25 02:42:36
Versions:Frequency of
Environment:Attachments:( 0) mu2a2mu.txt
Description:We changed app_meetme to use alaw to communicate with the zaptel conference instead of ulaw. Everything seems to work fine. Since all our interface use alaw this seemded resonable.

In time I would like to add a switch to the conference description in meetme.conf to select alaw instead of ulaw. Is this the prefered way to do it? Is it desireable at all?
Comments:By: Brian West (bkw918) 2004-06-12 15:56:29

What is the advantage of this?  Their is a direct ulaw <=> alaw transcoder in asterisk ...


By: Olle Johansson (oej) 2004-06-12 15:56:48

Please add switch so we can keep backwards compatibility for the ulaw part of the world.

By: petersv (petersv) 2004-06-12 16:03:50

Bkw: well, it seemed unnecessary to have an extra conversion step when the real conferencing bakcend supports alaw which is all that we use in Sweden. It can't really gain quality. I have not looked at the alaw-ulaw conversion an how litte information is lost there.

Oej: yes, a switch of some kind should be used. It it still seems like a good idea I will add that after the hollidays.

By: Brian West (bkw918) 2004-06-12 16:05:16

their really is no conversion involved.. its just one or two bits that get munged.  It doesn't require that much CPU to make it happen in those cases.


By: Olle Johansson (oej) 2004-06-12 16:06:39

If it's that easy, it seems like this patch is not needed.

By: Brian West (bkw918) 2004-06-12 16:48:27


Look at that... you will see how simple it is and this patch isn't needed.

By: petersv (petersv) 2004-06-12 18:13:10

Yes it is fast (I knew that) but it is not lossless. Those questions are orthogonal. There should be a value-aliasing effect introduced by the two extra conversions (one a->u and one u->a) unless the two logarithmical functions are selected just right.

Then again maybe they are. Anyone with a deeper knowledge of the logarithmic functions and how the qunatization is done?

By: Brian West (bkw918) 2004-06-12 21:01:48

accually it is lossless...

By: Mark Spencer (markster) 2004-06-13 02:01:33

It's not intuitively lossless.  It would be easy enough to confirm if it is.  Simply look at the tables that are created -- if you can convert 0-255 from alaw to ulaw and back to alaw and get 0-255 back, then it's lossless.  If you get any double/missed entries, then it isn't.

By: petersv (petersv) 2004-06-13 03:46:45

They both use one 8-bit quantity for each time sample. If thhere is to be a conversion between the two and back that is lossless then they need to be simple permutations of eachother. There are 256 possible values in alaw and the same i ulaw and each sample value is independant on other samples in time. I.e. for each alaw coded sample there must be a 1:1 correspondance with the ulaw samples.

By placing debug statements in codec_a_mu.c i foud that there are 55 samples that are aliased and thus do not convert back identically. I have attached the output.

By: Olle Johansson (oej) 2004-06-13 14:50:11

If it's not lossless, this patch is good for Alaw-networks. Please add a switch so it's configurable.

By: petersv (petersv) 2004-06-13 14:59:45

Looking at the data I got when I dumped the conversion tables for a-ulaw there seems to be something fishy going on. If I remember correctly the bit pattern of the encoded data is such that the next lower/higher value representable is a normal binary increment/decrement.

The data dumped has a few rather large irregualrities which makes me suspect that one of the transfer functions (alaw->lin, lin->alaw, ulaw->lin, lin->ulaw) breakes down for some values.

Am I correct, or are the law encoding functions not monotone in the output bit pattern when read out as a binary number? Too long ago...

By: petersv (petersv) 2004-06-13 15:10:42

My memory is crap. Alaw does something funky with the bits, I was just remembering ulaw. I don't know how large the error induced by the ulaw->alaw->ulaw coding really are.

By: petersv (petersv) 2004-06-13 15:33:35

The table above was for a->u->a. The errors are very small, once the xor:ing that is done by the alaw encoding is reversed. For u->a->u the errors are a maximum of 2 units which is imperceptible, I think.

There is some aliasing loss, but that should be drowned out by normal background noise. Since this is a conference there is no problem. I think this bug can be closed.

Do not try to run a data modem over a law conversion though, that would cost you bandwidth.

By: Mark Spencer (markster) 2004-06-13 16:01:43

You know, we could make this entirely irrelevant just by going to linear :)  Of course all this only applies to non-zap channels.

By: petersv (petersv) 2004-06-13 16:32:36

Linear would make sense since that is used by the conference system internally anyway. Right now everyting is converted to to ulaw first and then to linear which is a bit unnecessary.

That is a much larger change though since it touches interfaces.

By: Mark Spencer (markster) 2004-06-13 22:08:52

Fixed in CVS via the linear method.