Summary:	ASTERISK-01810: [patch] Alaw support im app_meetme
Reporter:	petersv (petersv)	Labels:
Date Opened:	2004-06-12 14:50:35	Date Closed:	2004-09-25 02:42:36
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
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 ... bkw 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. bkw 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 codec_a_mu.c 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.