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:36Date Closed:2008-06-07 11:04:22
Versions:Frequency of
Environment:Attachments:( 0) zaptel-dontidlewith0xff.patch
( 1) zaptel-dontidlewith0xff.try3.patch

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.

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


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?


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.


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?


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


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)