App_jack and JACK_HOOK introducing Noise on a call looped through jackd

I have set up a simple application to route the audio on a call through JACKD.

I am using Asterisk 13.23.1, Centos 7 and JackD 1.9.9.5-6 ( the default centos 7 version). All the components are running on the same Centos VM on a VMware host.
The WM has 4Gb of ram allocated and is doing nothing else.

I have used the example client (inprocess.c) wihich comes with the JACKD kit. This simply copies the input buffer to the output buffer. As i understand it, it is a simple loopback of the audio within JACKD. There is no processing being done on it other than a copy from one buffer to another.

My dialplan is as follows:

[jack-test]
exten => s,1,Answer
exten => s,n,NoOp("In jack test ....")
exten => s,n,Set(JACK_HOOK(manipulate,s(default),i(inprocess:input)o(inprocess:output))=on)
exten => s,n,Wait(2)
exten => s,n,Background(wm/prompt107)
exten => s,n,Dial(SIP/pbx-out/XXXX)
;exten => s,n,Set(JACK_HOOK()=off)
exten => s,n,Hangup

The jack_hook is on the asterisk inbound call channel.

The audio does come through (from caller to callee) and is audible but there is a lot of noise on it. Audio going the other way i.e. from callee to the caller is perfect.

If I comment out the jack hook, the audio on calls through the above dialplan is perfect.

My jack command is as follows

sudo -u asterisk jackd -d dummy -r 8000

and this is the output

jackdmp 1.9.9.5
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2012 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 20
No jack_get_descriptor entry-point for inprocess

I do not have a realtime kernel configured but I am starting the jackd process in realtime mode. I don’t think the notice that there is no jack_get_descriptor entry-point for inprocess is an issue.

I get the following when I load the inprocess application

sudo -u asterisk jack_load inprocess
inprocess is running.
client name = inprocess

I get the following warnings coming up on the asterisk console throughout the call.

[Feb 27 16:22:28] WARNING[14889]: app_jack.c:295 handle_input: Tried to write 2048 bytes to the ringbuffer, but only wrote 1920
[Feb 27 16:22:28] WARNING[14889]: app_jack.c:295 handle_input: Tried to write 2048 bytes to the ringbuffer, but only wrote 1920
[Feb 27 16:22:29] WARNING[14889]: app_jack.c:295 handle_input: Tried to write 2048 bytes to the ringbuffer, but only wrote 1984

I am using the default jackd settings in terms of buffer sizes and I set the sample rate to 8000 as this is the sample rate for the call (G.711 ALAW).

I’d be grateful if anyone could offer any ideas or suggestions as to what I could try to see where this noise is coming from or why it is being introduced.

Also if anyone has any idea why app_jack might not able to write the full buffer - I could investigate that further.

Thanks for any help in advance.
John.

I got this sorted.

It appears that when the audiohook was set up it assumes the audio format is SLIN and in the call this gets changed later on to ULAW.

However, the audiohook never changes.

I rearranged the dialplan slightly, delaying the creation of the jack_hook until after this message appeared in the asterisk log

[Mar  1 10:42:55] DEBUG[14202][C-00000000]: channel.c:5790 set_format: Channel SIP/testpbx-00000000 setting write format path: slin -> ulaw
[Mar  1 10:42:55] DEBUG[14202][C-00000000]: res_rtp_asterisk.c:4177 ast_rtp_write: Ooh, format changed from none to ulaw

New dialplan as follows - play a prompt before setting up the jack hook.

[jack-test]
exten => s,1,Answer
exten => s,n,NoOp("In jack test ....")
exten => s,n,Background(wm/prompt107)
exten => s,n,Set(JACK_HOOK(manipulate,s(default),i(inprocess:input)o(inprocess:output))=on)
exten => s,n,Wait(2)
exten => s,n,Dial(SIP/pbx-out/XXXX)
;exten => s,n,Set(JACK_HOOK()=off)
exten => s,n,Hangup

Now the audio is perfect in both directions !

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.