no outgoing audio on device

[GoogleCodeExporter]

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

Original issue reported on code.google.com by jamesl...@gmail.com on 19 Aug 2010 at 2:42

[GoogleCodeExporter]

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.

Original comment by robert.b...@gmail.com on 19 Aug 2010 at 4:42

[GoogleCodeExporter]

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

Original comment by jamesl...@gmail.com on 19 Aug 2010 at 5:07

Attachments:

• testlog8-19b.log

[GoogleCodeExporter]

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)

Original comment by r3gis...@gmail.com on 19 Aug 2010 at 5:52

Attachments:

• CSipSimple_0.00-12-17.apk

[GoogleCodeExporter]

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.  

Original comment by jamesl...@gmail.com on 19 Aug 2010 at 6:10

Attachments:

• testlog8-19d.log

[GoogleCodeExporter]

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.

Original comment by ben.friedberg@gmail.com on 19 Aug 2010 at 7:36

[GoogleCodeExporter]

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 : 
http://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.

Original comment by r3gis...@gmail.com on 19 Aug 2010 at 8:47

• Changed state: Accepted

[GoogleCodeExporter]

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?

Original comment by ben.friedberg@gmail.com on 20 Aug 2010 at 3:32

Attachments:

• csipsimple.12-18.call.log

[GoogleCodeExporter]

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).

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 3:55

[GoogleCodeExporter]

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?

Original comment by jamesl...@gmail.com on 20 Aug 2010 at 5:22

[GoogleCodeExporter]

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. 

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 7:34

Attachments:

• CSipSimple_0.00-12-19.apk

[GoogleCodeExporter]

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

Thanks again

Original comment by jamesl...@gmail.com on 20 Aug 2010 at 8:03

Attachments:

• CSIP-simple8-20.log

[GoogleCodeExporter]

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

Original comment by ben.friedberg@gmail.com on 20 Aug 2010 at 8:26

[GoogleCodeExporter]

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/te
st-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?

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 8:36

[GoogleCodeExporter]

@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?

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 8:40

[GoogleCodeExporter]

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.

Original comment by ben.friedberg@gmail.com on 20 Aug 2010 at 8:41

[GoogleCodeExporter]

Yes Ive gone through all the way up to 441

Original comment by jamesl...@gmail.com on 20 Aug 2010 at 8:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by ben.friedberg@gmail.com on 20 Aug 2010 at 9:06

[GoogleCodeExporter]

I added 0.00-12-19 here : 
http://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).

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 9:17

[GoogleCodeExporter]

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?)

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 9:22

[GoogleCodeExporter]

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.

Original comment by ben.friedberg@gmail.com on 23 Aug 2010 at 4:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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...

Original comment by ben.friedberg@gmail.com on 23 Aug 2010 at 8:27

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 23 Aug 2010 at 8:57

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 23 Aug 2010 at 9:22

Attachments:

• CSipSimple_0.00-12-22.apk

[GoogleCodeExporter]

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 

Original comment by jamesl...@gmail.com on 23 Aug 2010 at 10:31

Attachments:

• csip22.log

[GoogleCodeExporter]

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.h
tml#MIC should we try another source? Or try another audio mode?

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

Original comment by r3gis...@gmail.com on 23 Aug 2010 at 11:27

Attachments:

• CSipSimple_0.00-12-22.apk

[GoogleCodeExporter]

Ok, 
with that version it registers with my voip server (asterisk 1.4, freepbx 2.7) 
but will not initiate an echo test, I have tested with another sip phone and it 
working properly, attached is the log

Thank you again

Original comment by jamesl...@gmail.com on 23 Aug 2010 at 11:57

Attachments:

• csip22b.log

[GoogleCodeExporter]

Oh yes sorry that's probably the same bug than this one :
http://code.google.com/p/csipsimple/issues/detail?id=158#c2

I've just pushed it and include all latest change and solve this bug. (Was a 
regression introduced recently -- I try to do so much thing in the same time 
and it's time to sleep for me ;) )
Sorry.

Let me know how it goes with the one attached to issue 158 comment 2.

Original comment by r3gis...@gmail.com on 24 Aug 2010 at 12:04

[GoogleCodeExporter]

Ok, placing calls again now, but 
Im attaching two logs, one with g722, and a GSM 
the audio is a continuous robotic sound as opposed to patchy when I spoke, 
and it is just using the speakerphone again, not the ear piece

Thanks

Original comment by jamesl...@gmail.com on 24 Aug 2010 at 12:31

Attachments:

• csip22g722.log
• csip22gsm.log

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Strange thing about earpiece/speaker. The only thing I changed between the last 
0.00-12-22 on this thread and the one posted in issue 158 is related to dialing.
An besides in the previous log (on your comment 29) we have still the also 
error about earpiece. Maybe because of the fact since phone was still running 
the previous routing setting was still valid and so it was still trying to 
apply routing to earpiece. So finally, the use of the old api is maybe needed 
on your device. Did you reboot between comment 29 & 31? 

There is something I'm just thinking about : 
can you check my audio thread priority are well raised to -16 (using top -p XXX 
-t or ps -p XXXX -t (I never remember the tool that list thread)?)

Original comment by r3gis...@gmail.com on 24 Aug 2010 at 5:51

[GoogleCodeExporter]

ok, weird question.  We added a new audio mode called MODE_IN_CALL_NETWORK to 
our API that allows the AudioManager to select the correct route.  Is there a 
way to send us a new build with that mode set?  It's 3 in the enum. (IN_CALL is 
2).  Are you able to just specify an int or does that parameter have to be 
type-safe within the enum?  Maybe you could branch the code that you've been 
sending us and we could check it out and compile here against our sdk?

Original comment by ben.friedberg@gmail.com on 24 Aug 2010 at 3:00

[GoogleCodeExporter]

Well here : http://www.r3gis.fr/tmp_builds/CSipSimple_0.00-12-22-custo.apk a 
build with audio mode set to 3 (the parameter can be put directly as an int).

I can integrate this into the trunk the only thing I need is something to 
detect that I'm running your device. So can you provide me :
android.os.Build.BRAND or android.os.Build.DEVICE (the one you think is more 
relevant or both, or any android.os.Build.* value you think I should test on).

P.S. : I asked google for an extra attachement quota since we reached the max. 
If you need to send me logs, you can directly use my address (r3gis.3r at gmail 
dot com)

Original comment by r3gis...@gmail.com on 24 Aug 2010 at 4:16

[GoogleCodeExporter]

Here on my galaxy 9000i this branch (CSipSimple_0.00-12-22-custo.apk) fixes 1 
issue:
The dailout from the system phone book works the fisrt time, CSipSimple does 
not crash
But the microphone makes no sounds at all any more ...well better then the 
robotic sound :-)
Need to say, that will get the best app for android.

Original comment by m...@ufritz.de on 24 Aug 2010 at 6:29

[GoogleCodeExporter]

well, that 22-custo definitely selected the correct audio mode, so that's good. 
 We're taking a look at our internal ALSA implementation now.  We're seeing 

E/ALSALib ( 1519): external/alsa-lib/src/pcm/pcm.c:7231:(snd_pcm_recover) 
overrun occured                                                                 

W/AudioRecord( 1384): obtainBuffer timed out (is the CPU pegged?) 
user=00002080, server=000021c0 

on our audio record thread which is ~probably~ bad.  We are also seeing that 
same seg fault when hanging up.  We'll get back to you when we track something 
down.

Original comment by ben.friedberg@gmail.com on 25 Aug 2010 at 2:07

[GoogleCodeExporter]

@mail (comment 36) - not due to the fix for this branch / was fixed in the 
trunk. The custom build is not intended to work with any other device (in this 
one, audio layer is initialized with the custom implementation from Ben).

@ben : don't forget to provide me android.os.Build.BRAND & 
android.os.Build.DEVICE for your device so that I can definitely put the 
changes in my code for your device. If you want me to test other ways for the 
audioTrack/audioRecord instanciation or initialization let me know, I can 
provide you custom builds.

Original comment by r3gis...@gmail.com on 25 Aug 2010 at 7:41

[GoogleCodeExporter]

r3gis,

the brand is 'sdg' and the device is 'bip6000'.  Those are set in our .mk file 
as PRODUCT_BRAND and PRODUCT_DEVICE.  I believe they are passed along to the 
build system and stored, is that correct?  How else can I check that from my 
device (They didn't seem to be in getprop...)

As far as managing the audiorecord / audiotrack, I'm wondering what parameters 
you are passing in to the set() method on line 696 of android_dev.cpp.  Where 
does that log method (pj_log) send it's info?

One test might be to redirect the audio output to a file to see if it is 
RECORDING mangled sound or not...

Original comment by ben.friedberg@gmail.com on 26 Aug 2010 at 1:22

[GoogleCodeExporter]

It should be ok with PRODUCT_BRAND in your .mk file. I've just integrated a 
test on the brand. If sdg, so audio mode will be set to 3. Else I'll keep 
mode_normal.

http://code.google.com/p/csipsimple/source/browse/trunk/pjsip_android/apps/pjsip
/project/pjmedia/src/pjmedia-audiodev/android_jni_dev.cpp is the relevant file.
here is how I init the audio track :
0, // stream type VOICE_CALL : usefull to be able then to setStreamSolo on 
voice stream and avoid playing music to mix in.
param->clock_rate, // generally this one is the frequency set in the settings 
of the app
2, // CHANNEL_CONFIGURATION_MONO
sampleFormat, // Should be 2 : ENCODING_PCM_16BIT
inputBuffSizePlay, // Exactly the minBufferSize returned by the invokation of 
getMinBufferSize from the android sdk
1); // MODE_STREAM ... as we are streaming audio

For audio record :
1, // Mic input source
param->clock_rate, //same as above
2, // CHANNEL_CONFIGURATION_MONO
sampleFormat, //same as above
inputBuffSizeRec); //return by getMinBufferSize call on AudioRecord with good 
parameters

pj_log redirect logs to logcat of android if level is set in csipsimple app 
(Settings > UI > Log level (last entry) ; when in debugging mode 4 is the good 
value).

Good idea to record in a file (all the more so as pjsip has already something 
to do so - and could be a stub for future implementation of this feature). I'll 
see what I can quickly do for that.

Original comment by r3gis...@gmail.com on 26 Aug 2010 at 2:54

[GoogleCodeExporter]

thanks r3gis.  From 
http://developer.android.com/reference/android/media/AudioFormat.html#CHANNEL_CO
NFIGURATION_MONO, should you use a different channel specification?

Original comment by ben.friedberg@gmail.com on 26 Aug 2010 at 3:08

[GoogleCodeExporter]

Even if deprecated should fall back to the good value. At least I hope. If I 
use another value it will not be compatible with android 1.5 and 1.6 devices. 
I didn't implement anything to allow the java app to configure the native app 
audio for now. I can do it but will take a little bit time.

If you want me to provide you a build with CHANNEL_OUT_MONO and CHANNEL_IN_MONO 
hard coded, I can do it. 
Then, if things are better, I'll consider to have a way to configure the audio 
layer from the java app (or get back the current sdk version using jni)
Let me know if such a build is required.

Original comment by r3gis...@gmail.com on 26 Aug 2010 at 3:38

[GoogleCodeExporter]

No, I don't think I need one.  I'm just trying to figure out what is causing 
outgoing sound on our side to break.

Original comment by ben.friedberg@gmail.com on 26 Aug 2010 at 3:47

[GoogleCodeExporter]

Should be ok now.
Let me know, but with stun if needed; it should be fine with the new 
implementation (that works fine with samsung galaxy s that also has an alsa 
based implementation)

Original comment by r3gis...@gmail.com on 12 Oct 2010 at 7:14

• Changed state: NextRelease

[GoogleCodeExporter]

I am facing the similar problem. However, I can hear audio.
Mediaserver is crashing twice. Once when I pick-up the call and when I end-up 
the call. The logs appearing are as follows (these matches exactly with that of 
Ben's log)
04-07 22:14:29.118 I/DEBUG   (  933): *** *** *** *** *** *** *** *** *** *** 
*** *** *** *** *** ***

04-07 22:14:29.118 I/DEBUG   (  933): Build fingerprint: 
'generic/zoom2/zoom2/zoom2:2.1/ERD79/eng.root.20110408.105921:eng/test-keys'

04-07 22:14:29.118 I/DEBUG   (  933): pid: 935, tid: 986  >>> 
/system/bin/mediaserver <<<

04-07 22:14:29.118 I/DEBUG   (  933): signal 11 (SIGSEGV), fault addr 00000098

04-07 22:14:29.118 I/DEBUG   (  933):  r0 00000082  r1 403074b0  r2 b67da0f3  
r3 b67da0f3

04-07 22:14:29.118 I/DEBUG   (  933):  r4 8008b818  r5 8008ba38  r6 8007f0f0  
r7 8007f1ec

04-07 22:14:29.118 I/DEBUG   (  933):  r8 00000000  r9 ab70f608  10 00001000  
fp ab70d178

04-07 22:14:29.118 I/DEBUG   (  933):  ip afbc30c8  sp 40307d30  lr ab707b00  
pc 8004314c  cpsr 60000010

04-07 22:14:29.298 I/System.out( 1134): PhoneTabPanel*=*=*=*=*=*= ONRECEIVE: 
ph=IDLE, fg: DISCONNECTED, bg: IDLE

04-07 22:14:29.298 D/InCallScreen( 1134): delayedCleanupAfterDisconnect()...  
Phone state = IDLE

04-07 22:14:29.298 I/System.out( 1134): phoneIsInUse :: false

04-07 22:14:29.337 I/DEBUG   (  933):          #00  pc 0004314c  
/system/lib/libasound.so

04-07 22:14:29.345 I/DEBUG   (  933):          #01  pc 00008088  
/system/lib/libaudio.so

04-07 22:14:29.345 I/DEBUG   (  933):          #02  pc 0001ffce  
/system/lib/libaudioflinger.so

04-07 22:14:29.368 I/DEBUG   (  933):          #03  pc 0001bde6  
/system/lib/libutils.so

04-07 22:14:29.368 I/DEBUG   (  933):          #04  pc 0001c23c  
/system/lib/libutils.so

04-07 22:14:29.368 I/DEBUG   (  933):          #05  pc 0000fd74  
/system/lib/libc.so

04-07 22:14:29.368 I/DEBUG   (  933):          #06  pc 0000f840  
/system/lib/libc.so

04-07 22:14:29.368 I/DEBUG   (  933): 

04-07 22:14:29.368 I/DEBUG   (  933): code around pc:

04-07 22:14:29.368 I/DEBUG   (  933): 8004313c e58d2000 e1a02006 e1a0e00f 
e595f000 

04-07 22:14:29.384 I/DEBUG   (  933): 8004314c e5983098 e59f1050 e1a00007 
e58da004 

04-07 22:14:29.384 I/DEBUG   (  933): 8004315c e1a02006 e0844001 e58d3008 
e58d4000 

04-07 22:14:29.392 I/DEBUG   (  933): 

04-07 22:14:29.392 I/DEBUG   (  933): code around lr:

04-07 22:14:29.400 I/DEBUG   (  933): ab707af0 e0841001 e3a0c000 e5cdc40b 
ebfffcbe 

04-07 22:14:29.415 I/DEBUG   (  933): ab707b00 e59d240c e5963000 e1520003 
1a000002 

04-07 22:14:29.431 I/DEBUG   (  933): ab707b10 e28dd014 e28ddb01 e8bd80f0 
ebfffcd1 

04-07 22:14:29.431 I/DEBUG   (  933): 

04-07 22:14:29.431 I/DEBUG   (  933): stack:

04-07 22:14:29.431 I/DEBUG   (  933):     40307cf0  0000f424  [heap]

04-07 22:14:29.431 I/DEBUG   (  933):     40307cf4  afe3119c  
/system/lib/libc.so

04-07 22:14:29.431 I/DEBUG   (  933):     40307cf8  80e01aad  
/system/lib/hw/alsa.default.so

04-07 22:14:29.431 I/DEBUG   (  933):     40307cfc  00000100  

04-07 22:14:29.431 I/DEBUG   (  933):     40307d00  afe3ae08  
/system/lib/libc.so

04-07 22:14:29.431 I/DEBUG   (  933):     40307d04  afe3e84c  

04-07 22:14:29.431 I/DEBUG   (  933):     40307d08  fffffff0  

04-07 22:14:29.431 I/DEBUG   (  933):     40307d0c  000f4240  

04-07 22:14:29.439 I/DEBUG   (  933):     40307d10  00000000  

04-07 22:14:29.439 I/DEBUG   (  933):     40307d14  b67da0f3  

04-07 22:14:29.447 I/DEBUG   (  933):     40307d18  00000000  

04-07 22:14:29.462 I/DEBUG   (  933):     40307d1c  8008b818  
/system/lib/libasound.so

04-07 22:14:29.462 I/DEBUG   (  933):     40307d20  8008ba38  
/system/lib/libasound.so

04-07 22:14:29.462 I/DEBUG   (  933):     40307d24  8007f0f0  
/system/lib/libasound.so

04-07 22:14:29.462 I/DEBUG   (  933):     40307d28  df002777  

04-07 22:14:29.462 I/DEBUG   (  933):     40307d2c  e3a070ad  

04-07 22:14:29.462 I/DEBUG   (  933): #00 40307d30  8007f24c  
/system/lib/libasound.so

04-07 22:14:29.462 I/DEBUG   (  933):     40307d34  00001000  

04-07 22:14:29.462 I/DEBUG   (  933):     40307d38  00038c98  [heap]

04-07 22:14:29.470 I/DEBUG   (  933):     40307d3c  b67da0f3  

04-07 22:14:29.470 I/DEBUG   (  933):     40307d40  ab70d038  
/system/lib/libaudio.so

04-07 22:14:29.470 I/DEBUG   (  933):     40307d44  00035a08  [heap]

04-07 22:14:29.470 I/DEBUG   (  933):     40307d48  00001000  

04-07 22:14:29.470 I/DEBUG   (  933):     40307d4c  00038c98  [heap]

04-07 22:14:29.470 I/DEBUG   (  933):     40307d50  00000000  

04-07 22:14:29.470 I/DEBUG   (  933):     40307d54  00000000  

04-07 22:14:29.470 I/DEBUG   (  933):     40307d58  00024950  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d5c  ab70808c  
/system/lib/libaudio.so

04-07 22:14:29.478 I/DEBUG   (  933): #01 40307d60  00000001  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d64  00000000  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d68  000336cc  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d6c  00035a18  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d70  ab70d038  
/system/lib/libaudio.so

04-07 22:14:29.478 I/DEBUG   (  933):     40307d74  000000e4  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d78  00033638  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d7c  0003365c  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d80  0003365c  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d84  00000001  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d88  00033638  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307d8c  ab02b4b8  
/system/lib/libaudioflinger.so

04-07 22:14:29.478 I/DEBUG   (  933):     40307d90  00000000  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d94  00100000  

04-07 22:14:29.478 I/DEBUG   (  933):     40307d98  a9d1c1d5  
/system/lib/libutils.so

04-07 22:14:29.478 I/DEBUG   (  933):     40307d9c  40208000  

04-07 22:14:29.478 I/DEBUG   (  933):     40307da0  00035a40  [heap]

04-07 22:14:29.478 I/DEBUG   (  933):     40307da4  ab01ffd1  
/system/lib/libaudioflinger.so

Also 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;
}
Any pointers would be helpful to resolve this.

Original comment by chaitral...@gmail.com on 8 Apr 2011 at 7:08