Summary:	ASTERISK-05050: [patch] Zaptel idles channels with a value that isn't appropriate for alaw
Reporter:	Steve Davies . (stevedavies)	Labels:
Date Opened:	2005-09-11 05:17:36	Date Closed:	2008-06-07 11:04:22
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) zaptel-dontidlewith0xff.patch ( 1) zaptel-dontidlewith0xff.try3.patch
Description:	Hi, I've just been doing some experiments on my test box with looped E1 PRI  spans - playing with app_test with a view to adding more tests. In the process I "Monitor"ed to disk the audio heard on both ends of my bridged call. When I loaded the audio into Audacity to take a look, I was suprised to see that a channel that isn't being transmitted on seems to be seen at the receiving end as non-zero samples.  So every time the sending box starts and stops sending audio then there is a jump of the "zero level" to true-0 and then back to the resting value. The "resting value" is 832, which I note is AST_ALAW(255) By contrast, AST_ULAW(255) is 0. od -x </dev/zap/1 shows that channels not otherwise in use receive nonstop 0xff.  (IE - channels not otherwise written to are transmitted as 0xff). So for channels that are being used for alaw, the "rest value" shouldn't be 0xff but rather 0xd5, being AST_LIN2A(0). I've attached what turned out to be rather a simple patch to fix this issue. Steve
Comments:	By: Mark Spencer (markster) 2005-09-11 13:06:22 As indicated in the comment precisely above the code which clears the b-channels, we should send FF when the channels are idle, otherwise certain switches assume they are not idle. By: Steve Davies . (stevedavies) 2005-09-11 14:44:07 Mark: It is an issue because, at least, the level changes introduce audible clicks.   In ulaw-land AST_MULAW(0) IS 0xFF anyway, so the patch makes no difference for you guys. I can't find any reference that says idle channels here in alaw must be 0xff, but if that is the case I can develop the patch further to still send 0xff on really non-in-use channels, but to send ALAW(0) = 0xd5 on channels that are active in Asterisk but not being transmitted on. What do you want to do? Steve By: Matt Riddell (zx81) 2005-09-11 20:15:02 If that really was the case you could interpolate over a few frames to get from the FF to the D5 and then on to the first data. By: Steve Davies . (stevedavies) 2005-09-12 00:17:29 Why bother to interpolate?  With the code as it is, it already just jumps from the one to the other, every time Asterisk starts and stops transmitting. Steve By: Matt Riddell (zx81) 2005-09-12 01:13:24 That's why. If it jumps from one value to another it will click.  If it happens over a few samples, it wont. By: Steve Davies . (stevedavies) 2005-09-12 14:02:54 After a prompt on the asterisk-dev list, found some references which say alaw channels should idle with 0x55.  That's ALAW(-8), whilst 0xD5 is ALAW(+8).  There is no alaw value for exactly 0. If I adjust the patch to generate the right value - 0x55 for Alaw, 0xFF for ulaw, will it be applied? Steve By: Steve Davies . (stevedavies) 2005-09-17 05:39:31 OK - a new patch, hopefully more obviously correct. Here's the motivation: Currently, zaptel idles B channels on a PRI with 0xFF.  This is ULAW(0) and also the expected value to be found on an idle B-channel in u-law-land.  (Some peers apprently care). But its not the right value in in a-law-lands. In a-law-lands, the corresponding idle-value that is supposed to be used is 0x55.  This is ALAW(-8) which is as close as ALAW gets to a 0-value. This patch makes sure that alaw channels idle with the correct 0x55 value. As a side-benefit, it also gets rid of sudden jumps and clicks that will occur whenever Asterisk starts and stops transmitting on an alaw channel.  These currently occur because 0xff in alaw is a linear value of 832 - significantly different from 0. By: Steve Davies . (stevedavies) 2005-09-17 05:45:22 Oh b*llocks.  There's a stupid cut-n-paste mistake in that .try2 patch. Someone please delete it and in the meantime, please apply only .try3 Steve By: Matt Riddell (zx81) 2005-09-22 12:01:56 Looks nice and makes sense not needing to interpolate if the values are close (and who'd design a protocol where that would have a problem anyway). :) Heads up that this seems to be fixing some faxing problems for the Euro Land people. By: Kevin P. Fleming (kpfleming) 2005-09-25 17:39:00 Committed to CVS HEAD, but with changes to only use this when the channel is in audio mode and to use the existing table-lookup macro for determining the silence value. By: Digium Subversion (svnbot) 2008-06-07 11:04:22 Repository: dahdi Revision: 773 U   trunk/zaptel.c ------------------------------------------------------------------------ r773 | kpfleming | 2008-06-07 11:04:22 -0500 (Sat, 07 Jun 2008) | 2 lines ensure that idle audio channels transmit silence (issue ASTERISK-5050, slightly different fix) ------------------------------------------------------------------------ http://svn.digium.com/view/dahdi?view=rev&revision=773