#146 no outgoing audio on device

[Anonymous]

Originally created by: jamesl...@gmail.com
Originally owned by: r3gis...@gmail.com

What steps will reproduce the problem?
1.install csip
2.place a call
3.no outgoing audio/garbled and broken audio

What is the expected output? What do you see instead?
Ability to place a call, instead no audio going out

What version of the product are you using? On what operating system?
latest download, on android 2.1

Please provide any additional information below.
Any call either echo test, or to a working phone, the audio comes in clear to the handheld in question, but cannot send audio out
it has a      Marvell PXA320  CPU, if that makes any difference.
sorry im very new to all of this

[Anonymous]

Originally posted by: robert.b...@gmail.com

You should probably specify exactly which phone it is, confirm that it is the latest from the website and not the market (0.00-12-14). Completely uninstall the old version and then install and configure the new version so you don't have an old config file causing problems. You should also specify what SIP server you're using. If at all possible, make a call and then hit the info button (the "i" during a call) to see which codec is being used. And try installing 'alogcat' from the Market and generate a logcat file to help debug. I think that should be everything, it'll go a long way to help these guys help fix your issue.

[Anonymous]

Originally posted by: jamesl...@gmail.com

The phone Im using is not on the Market, its an obscure model, but Ill attach a log hopefully it will help,  Thanks in advance for any help

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok thanks for your logs, that more clear right now.

There is something that we can test on this device (all the more so as it seems to use the alsa backend just like on the galaxy S on which the same fix is needed)

Besides regarding the log there is a crash in the alsa layer. If this is a device still in developement maybe worth to report the same log to the developer of the android port since there is a possible issue with the audio layer (as what I did could be done by other apps and the crash is only in the audio layer stack).

My guess is that this version will be a little bit better but you'll maybe have echo issue (if based on the same alsa implementation than the one of galaxy somebody has reported me than (as for sony X10) the micro is mixed with the output line and so your callee will ear a big echo (while will sounds fine for you).

Let me know also if you have choppy sound. You can try to set frequency to 16kHz (it seems to improve things on galaxy S)

[Anonymous]

Originally posted by: jamesl...@gmail.com

Thanks for your response, I uninstalled the older version,and installed 12-17, but now the earpiece isnt working, just speakerphone all the time, and the same audio issue. Ive attached another log. 

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

Hi, I'm on the android porting team for the device that James is using (http://sdgsystems.com/index.php?option=com_content&view=article&id=85&Itemid=63).  Is there something that I can check on my end for audio control?  As it stands, the default audio record application works with the device.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Great Ben, you'll probably be able to help me a lot. (And I hope that I can help also with my point of view on the existing implementations).

First of all you can try this one : https://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-18.apk
I reverted things for speaker and audio mode but keep the optimizations of the sip stack.

As you probably noticed, the audio API is not really clear in the SDK (all the more so as you try to support 1.5 and 1.6 devices). Even if some methods were available since 1.5, (setSpeakerphoneOn for example) it was not functional. They firstly try something with routing methods and finally declare that the toogle functions are the good way to change the routing.

In fact there is two different kind of implementation as I have observed :

The first one adopted by HTC devices and the Samsung Galaxy S has as effect that the IN_CALL stream mode must *not* be used. And routing things (such as routing to earpiece) can be done using AudioManager.setSpeakerphoneOn(). If you use routing mode IN_CALL on these devices the micro will record things really quietly or nothing in worse cases.
So in this case, I only use setSpeakerphoneOn and I don't change the audio mode. (that was the case in 0.00-12-17 posted here)

Others (adopted by all other device) is to still support audio mode IN_CALL and routing mode. I think that this is the correct way since there is no reason for which audio mode IN_CALL would made the AudioRecord louder.
In this case the I set mode to IN_CALL and I change the routing of IN_CALL mode to earpiece/speaker using the old api (the new API is also used as an extra check and should behave the same way)

There is another point that should be checked also : that the micro source is not mixed with the output (with the app it's easy to detect, if the remote contact ear a big echo that's the case - if it is the case it can be reproduce with all sip application, Fring for example... they use to have exactly the same issue than me on the same devices).

For choppy sound, there is still issues on the sip stack I use, but they appear under certain condition such as high cpu usage (for example if you use the iLBC codec, there is chance it become choppy). You should try to disable this codec to ensure it is not used (Settings > Media > Codec > Long clic on iLBC). Maybe other codecs should be disabled too. (The codec that use the less cpu is PCMA / PCMU)

So to sum up everything : if micro doesn't record anything with the 0.00-12-18, the reason for that can be :
- The network (nat/firewall....)
- The fact that when in IN_CALL mode the micro doesn't route anything to created RecordTracks
- CPU is too much in use because of the use of a codec that consume too much cpu.

Owner: r3gis.3R
Status: Accepted

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

sorry, didn't get a notification that you had responded. 

So, I tested the version you sent and OUTGOING audio WAS recorded (it appeared), but came through as extremely corrupted or not at all.  It also looks like the only codec currently working is G722.  I'll need to check that and verify, though.  It might just be an issue with our server.  I'll also take a look at the routing although I someone else on our team implemented that so I can't guarantee that I'll be able to tell you much.  I'm including a log for the latest -18 with debug cranked all the way up.

James, have you gotten the pcma or pcmu to work at all?

[Anonymous]

Originally posted by: r3gis...@gmail.com

Thanks for your tests.

About the codec, it is chosen by the asterisk server. (CSipSimple well announce that it support PCMU PCMA and GSM too) Probably the server prefer G722. You can try to disable the codec too. If nothing happens when you try to call or receive a call it probably means that the server doesn't support nor PCMU, PCMA and GSM (it can be checked using the logs)).

About the corrupted sound, what you can try is reduce the log level : as level 5 (and more) produce logs while in audio stream, it blocks the treatment of the packet while logging. Setting the log level to 4 is the good setting to get Debug level (5 is verbose and it affect performance while in call).
G722 consume more CPU than PCMU/PCMA. So maybe will be also better when you get it working with PCMU or PCMA but if not, what should be interesting also is to set audio frequency to 16kHz (there is an option in the media settings of csipsimple) : G722 work with 16kHz streams so avoiding 8kHz resampling before sending it to the audio layer is interesting and can save CPU.

Last point, if your CPU support armv7 instructions, I can send you a version built for armv7 procs (can be optimized in term of CPU).

[Anonymous]

Originally posted by: jamesl...@gmail.com

In my testing last night, using the GSM codec, with the frequency set to 32khz it seemed to work the best, being as in an echo test the outgoing audio was still robotic, but only chopped every third word as opposed to most of them. 
Is there any way I could get a copy of the version built for armv7?

[Anonymous]

Originally posted by: r3gis...@gmail.com

I attached a version with both armv4 and armv7 bundled (android system should choose the armv7 but worth to check with the logs it is the case).

This version also double the buffer size for the recorderTrack (it was previously exactly the value get from the getMinBufferSize method). Let me know if it is better and with which frequency.

[Anonymous]

Originally posted by: jamesl...@gmail.com

Ive downloaded the 12-19 with the g722 settings, and still the same performance,
attached is the log.

Thanks again

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

For the record, the bip6000 runs on a marvell pxa 320 processor (armv5te) so the armv7 instructions won't work.

[Anonymous]

Originally posted by: r3gis...@gmail.com

There is something that afraid me (and was present in the first logs you provided :

01-05 03:23:56.215 I/DEBUG   (  821): Build fingerprint: 'sdg/bb_bip6000/bip6000/:2.1-update2/ERE27/eng.bfriedberg.20100630.120500:eng/test-keys'
01-05 03:23:56.215 I/DEBUG   (  821): pid: 1601, tid: 1604  >>> /system/bin/mediaserver <<<
01-05 03:23:56.215 I/DEBUG   (  821): signal 11 (SIGSEGV), fault addr 00000098
01-05 03:23:56.245 I/DEBUG   (  821):          #00  pc 00043e54  /system/lib/libasound.so
01-05 03:23:56.245 I/DEBUG   (  821):          #01  lr ab708090  /system/lib/libaudio.so
01-05 03:23:56.245 I/DEBUG   (  821): stack: [...]

@Ben : you should probably try to see where things are crashing (using arm-eabi-addr2line in a first time). The stack trace involves only the media lib. There is maybe something to ensure to avoid this kind of crash or maybe I'm not using properly the official android API?

There is also things I didn't notice the first time :
01-05 03:25:30.285 W/AudioHardwareInterface( 1715): getInputBufferSize bad sampling rate: 16000
01-05 03:25:30.285 W/AudioHardwareInterface( 1715): getInputBufferSize bad sampling rate: 44100
01-05 03:25:30.285 W/AudioHardwareInterface( 1715): getInputBufferSize bad sampling rate: 48000
01-05 03:25:30.285 W/AudioHardwareInterface( 1715): getInputBufferSize bad sampling rate: 32000
01-05 03:25:30.285 W/AudioHardwareInterface( 1715): getInputBufferSize bad sampling rate: 16000

These log doesn't appear on Ben's logs is that the same rom version?

[Anonymous]

Originally posted by: r3gis...@gmail.com

@Ben : Ok, so the attached version (0.00-12-19.apk) will automatically load the armv4 compatible version.
I suspect that your current android version differs from the one of James? You have a more recent one, isn't it?

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

hmm, I think we may only be supporting 8000 for now... James, can you verify that you tried the different sampling rates throughout your testing.  my logs are probably only for 8000...

I'll see if I can track down that symbol in libasound.

[Anonymous]

Originally posted by: jamesl...@gmail.com

Yes Ive gone through all the way up to 441

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

for the record, the stack trace is pointing to snd_pcm_frames_to_bytes:

ssize_t snd_pcm_frames_to_bytes(snd_pcm_t *pcm, snd_pcm_sframes_t frames)
{
        assert(pcm);
        if (CHECK_SANITY(! pcm->setup)) {
                SNDMSG("PCM not set up");
                return -EIO;
        }
        return frames * pcm->frame_bits / 8;
}

which makes me think that the assert might be failing.  I'll start to track it back through android since this code is untouched by us.

[Anonymous]

Originally posted by: r3gis...@gmail.com

I added 0.00-12-19 here : https://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-19.apk

If you only support 8kHz, things are coherent with logs. So that's fine.
CSipSimple will fallback to the only available rate (8kHz) so the fact james get a better quality with 32kHz was probably just a more lucky try since frequency parameter doesn't change anything and audio is always open with 8kHz.

So if only 8kHz is supported, g722 is probably not the best candidate since it is a 16kHz codec.

Ben can you try the last one (with logs at level 4 max) and if possible enabling only PCMA/PCMU codecs. It would be interesting to see if you reproduce the buffer overflow of the audiorecord and also if you can while in call watch the process cpu usage (using top on a adb shell for example).

[Anonymous]

Originally posted by: r3gis...@gmail.com

Thanks for the pointer to the stack trace, I'll also check it (I guess that it is the alsa port available in the android git that is in use?)

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

I'll be checking into this more today.  Using pcma / pcmu only, there was about 3 - 4% cpu utilization displayed in 'top'.  So I don't think that's the issue.  I'll run a log to verify.  Also, the 'buffer overflow' for audio record is a non-issue (as far as I can tell).    I'll let you know more as I test through the day.

[Anonymous]

Originally posted by: ben.friedberg@gmail.com

It isn't clear to us how a SIP client is supposed to select the audio routing that it needs.  MODE_IN_CALL is not appropriate for a SIP client, because (at least on our platforms), when the routing is IN_CALL, the audio chip and the GSM modem are directly connected, so Android (and therefore the SIP client) never sees the audio stream.

We're looking into creating a new audio route that is appropriate for this application to see if that resolves our outgoing audio difficulties...

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok ! Now I understand better why on some device setting mode in call cause the micro to be really quiet. That's the reason why in my code there is a test (depending on the phone information) that test if set mode should be done.
But for other phone, setting mode in_call allow to properly use routing.

Maybe I could try using another audio route? Is there a mode you advise me to use (regardless your implementation...) MODE_NORMAL maybe?
I'll try that ! If it can avoid the check and make the code always valid... could be great.

Many thanks for your investigations!
I'll test Mode_normal on my nexus one and probably provide something soon.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Yeah ! Sounds really good !! On nexus one using Mode_normal and keeping the old routing api (in addition to the new api), seems to solve an intermittent bug I add using some codecs.

I attached a new build.

Let me know if better on your device and once again many thanks for your help.

[Anonymous]

Originally posted by: jamesl...@gmail.com

I just got home and tested the latest version 12-22,
attached is the log, and at first I used the g722 at 8khz,
and then tried gsm at 16khz(which has worked the best so far to this point)
the latest version has not improved anything, and actually is worse
on incoming calls now, and outgoing isnt any better.  also the earpiece
quit working on this version.

Thanks again

[Anonymous]

Originally posted by: r3gis...@gmail.com

I miss logs from pjsip in your log, but :

I think that since I use the old API I get this error when playback stream is created
01-01 02:21:41.594 E/ALSALib ( 1600): external/alsa-lib/src/pcm/pcm.c:2201:(snd_pcm_open_noupdate) Unknown PCM AndroidPlayback_Earpiece_normal
01-01 02:21:41.594 E/ALSALib ( 1600): external/alsa-lib/src/pcm/pcm.c:2201:(snd_pcm_open_noupdate) Unknown PCM AndroidPlayback_Earpiece
I know that it is a deprecated API but should in the worse case do nothing. I attached a build which check api version to not use deprecated routing api
(in fact I was still using the old routing api since some device even if in api>5 still need the call of the old routing api - at least was the case when using mode_in_call, I should re-test with mode_normal on these devices).

That's probably why earpiece is not working anymore. Maybe there something to see on your side for this part. I deeply advise you to be robust regarding the use of the old api, will be appreciated by developers ;)

Don't know if it can has an effect on the call quality after? There is probably no reason for playback routing affect recording. So probably not the only problem.

Then the interesting second log I see is this one :

01-01 02:21:43.914 W/AudioRecord(10919): obtainBuffer timed out (is the CPU pegged?) user=00000640, server=00000780
01-01 02:21:43.924 E/ALSALib ( 1600): external/alsa-lib/src/pcm/pcm.c:7231:(snd_pcm_recover) overrun occured

As you previously said, I think too that record overflow are quietly normal for the beginning of the call (CPU is highly used and android views are created). What I observe then on devices on which I test is that recorder overflow disappear or only appear at a low rate.
But, the fact that obtaining buffer timeout is follow by an overrun sounds to be an issue. As if capturing from alsa doesn't flow the audioflinger.
As a precision I can add that the AudioRecord object is created with as source MIC (integer 1) http://developer.android.com/reference/android/media/MediaRecorder.AudioSource.html#MIC should we try another source? Or try another audio mode?

P.S. : warning file name is the same -12-22