[jitsi-dev] [PATCH] Jitsi-Android - fix issue with AudioTackRenderer


#1

Hi all,

While looking into SIP stability issues on Android I've discovered that the
incoming call notification sound loops infinitely on AudioTrackRenderer.

It happend on AudioSystemClipImpl:runOnceInPlayThread:203, because
AudioTrackRenderer keept on returning INPUT_BUFFER_NOT_CONSUMED.

In AudioTrackRenderer:678 there is a check for written bytes count and
buffer length values. In situation when there were 2 bytes left and 0 were
written to the output it kept on returning the input not consumed. I've
changed the condition so that it will return OUTPUT_BUFFER_NOT_FILLED in
case when 0 bytes were written and the length is greater than zero.

AudioTrackRendererPatch.txt (1.03 KB)

···

--
Regards,
Pawel


#2

I may need further information about the problem because
OUTPUT_BUFFER_NOT_FILLED does not make sense in a Renderer - there is no
output Buffer, a Renderer takes an input Buffer and plays it on a
(hardware) device.


#3

The line AudioTrackRenderer:604 is executed and there is 0 returned(checked
it on debugger). The data length in buffer is equal to 2. It looks like
these 2 bytes are not accepted by the AudioTrack. This causes
AudioSystemClipImpl to loop infinitely on AudioSystemClipImpl:203 as the
buffer is never consumed.

It can be reproduced by calling Jitsi for Android. It will freeze there on
incoming call sound(raw/incomingcall.wav).

···

2013/3/12 Lyubomir Marinov <lyubomir.marinov@jitsi.org>

I may need further information about the problem because

OUTPUT_BUFFER_NOT_FILLED does not make sense in a Renderer - there is no
output Buffer, a Renderer takes an input Buffer and plays it on a
(hardware) device.

--
Regards,
Pawel


#4

Pawel, your patch has been committed into SVN r10593 with the
following modifications:

- OUTPUT_BUFFER_NOT_FILLED is not returned because it has no meaning
(i.e. FMJ will not look for it) in the context of a Renderer
implementation (as explained earlier). Effectively, it was equivalent
to returning BUFFER_PROCESSED_OK.

- The check length > 0 is not included in the if condition because the
execution at that point has that covered already.

- A logger.warn() is executed when written == 0 to log that audio data
will be dropped. Please keep an eye about this warning during
development because I'm not comfortable with giving up on the first
failure to write and Google's documentation does not mention anything
on the subject.


#5

Thanks !

···

2013/3/12 Lyubomir Marinov <lyubomir.marinov@jitsi.org>

- A logger.warn() is executed when written == 0 to log that audio data
will be dropped. Please keep an eye about this warning during
development because I'm not comfortable with giving up on the first
failure to write and Google's documentation does not mention anything
on the subject.

Sure. Btw. this behavior seems to be more like a bug as returning 0 may
mean that the device buffer is full at the moment, but later it should
accept the rest of it. In fact it never does. I've found few posts on the
internet about this issue, but with no clear response.

--
Regards,
Pawel