yashsingh1/xdaforums huggingface dataset:
[Miscellaneous Android Development] siljaer:
[MENTION=7319300]ottmi[/MENTION] is innocent, changes to audio section were mine...

would you please elaborate? can't the other side hear you? can't you hear anything?

who's hearing the echo, you or the other party?

It's really puzzling me: two different people seemingly complaining of two opposite problems...
[Miscellaneous Android Development] marcachas:
Hi, thanks.

The other people listen echo, only the others, me listen vero Clearly.
[Miscellaneous Android Development] siljaer:
have you experienced that problem with the previous release (@Wenderer71 's changes) ?
[Miscellaneous Android Development] ottmi:
I'll leave the echo issues to [MENTION=7529884]siljaer[/MENTION] as he's the master of mixer_paths :)

Can you provide a logcat and dmesg for sdcard issues? Without I can't do anything as these problems don't appear on my phone..
[Miscellaneous Android Development] siljaer:
Well, I must admit I am puzzled.

What we (@Wenderer71 and I) have done so far to deal with the echo problem was brutally simple: to decrease the volume of the earpiece (less signal going to the mic) and the volume/gain of mic (less signal picked up by the mic). Incidentally, this is what manufacturers of cheap phones do, instead of implementing patented echo cancellation algorithms. Obviously, the side effects are low volume in the earpiece and low volume perceived by the other party, a common complain with cheap phones.

A much better way would be using qualcomm voice processing features; I've been looking into the sources: some phones have a voice processing folder in the device tree. Trunk has not, Swift has not and so on. Actually, in the sources I have found references for a different platform than snapdragon410. I think that we cannot use those features at the moment. And having one single mic, we could not expect the same results of dual mic phones.

The idea about increasing mic digital volume and decreasing mic gain did not work. With a gain lower than 6, the mic cannot pick up voice (unfortunately, the mic is facing away from the mouth of the speaker).

Now, we have a user complaining about low volume (if I have understood correctly) and one complaining about echo still present. Naturally, the trunk is only one part of the path, being the other two the network and the other party's phone. Such different results make me think that network has an important part in the problem and maybe there's something else: we could have different batches of mics/earpieces in different production lot.

As an experiment, we could provide month and year of production (found on a mini sticker near the imei numbers).

Mines are 11/2015
[Miscellaneous Android Development] Bizen-Ya:
Hi,

Mine is 10/2015

The volume is very low on my side, and something like horrible/weird on the other ( never ask your wife for technicals details ;) )

i'll try to find a utility to record my phone call ...

thx !
[Miscellaneous Android Development] siljaer:
Thanks.

For a quick fix, you can try manually editing your /system/ect/mixer_paths_qrd_skuh.xml.

1) Find these sections and change values as follows:

<path name="handset">
<!-- RX1 -> RX1 -->
<ctl name="RX1 MIX1 INP1" value="RX1" />
<!-- connect RX1 to RDAC2 -->
<ctl name="RDAC2 MUX" value="RX1" />
<!-- set volume and gain to prevent echo-->
<ctl name="RX1 Digital Volume" value="84" />
<!-- set earpiece gain -->
<ctl name="EAR PA Gain" value="POS_6_DB" />
<ctl name="EAR_S" value="Switch" />
</path>

<path name="handset-mic">
<!-- use ADC1 -->
<path name="adc1" />
<!-- feed ADC1 output to IIR1 for sidetone -->
<ctl name="IIR1 INP1 MUX" value="DEC1" />
<!-- set volume and gain to prevent echo-->
<ctl name="ADC1 Volume" value="6" />
<ctl name="DEC1 Volume" value="84" />
</path>

2) reboot

That should fix volume issues. If you experience echo, you can try decreasing RX1 Digital Volume. If the other party cannot hear you yet, you can try increasing ADC1 Volume up to 9.

As I have said earlier, it really puzzles me that you and [MENTION=7419342]marcachas[/MENTION] are experiencing opposite issues.

---------- Post added at 20:33 ---------- Previous post was at 20:01 ----------

Hi [MENTION=7319300]ottmi[/MENTION],

old conversation, I know, but maybe I have an answer now:

I THINK we'd better use the android standard pre-processor. I am not sure that voice processing features are enabled for msm8916, I am not sure at all they can work with a single mic and I have found so many complaints about Qualcomm implementation that I think it would create even more problems.

Android pre-processor, instead, looks simpler : "Acoustic Echo Canceler (AEC) is an audio pre-processing which removes the contribution of the signal received from the remote party from the captured audio signal. ". That is, just what we need, as we have a single mic and cannot take advantage of complicated proprietary algorithms that try to build a spatial model and so on.

Would you investigate whether is possible to use android standard pre-processing libs instead of qualcomm's?

Thanks! :)
[Miscellaneous Android Development] ottmi:
I think for now we're not using any pre-processor. This would require setting a pre_processor library in audio_effects.conf, setting the respective uuid for the library and finally enabling it for the devices of interest. The Android standard pre-processor is in /system/lib/soundfx/libaudiopreprocessing.so which is already contained in the ROM. You just need to un-comment the corresponding blocks in the current audio_effects.conf file. Without the comments, the file should then look like this:

libraries {
bundle {
path /system/lib/soundfx/libbundlewrapper.so
}
reverb {
path /system/lib/soundfx/libreverbwrapper.so
}
visualizer {
path /system/lib/soundfx/libvisualizer.so
}
downmix {
path /system/lib/soundfx/libdownmix.so
}
loudness_enhancer {
path /system/lib/soundfx/libldnhncr.so
}
pre_processing {
path /system/lib/soundfx/libaudiopreprocessing.so
}
}

effects {
bassboost {
library bundle
uuid 8631f300-72e2-11df-b57e-0002a5d5c51b
}
virtualizer {
library bundle
uuid 1d4033c0-8557-11df-9f2d-0002a5d5c51b
}
equalizer {
library bundle
uuid ce772f20-847d-11df-bb17-0002a5d5c51b
}
volume {
library bundle
uuid 119341a0-8469-11df-81f9-0002a5d5c51b
}
reverb_env_aux {
library reverb
uuid 4a387fc0-8ab3-11df-8bad-0002a5d5c51b
}
reverb_env_ins {
library reverb
uuid c7a511a0-a3bb-11df-860e-0002a5d5c51b
}
reverb_pre_aux {
library reverb
uuid f29a1400-a3bb-11df-8ddc-0002a5d5c51b
}
reverb_pre_ins {
library reverb
uuid 172cdf00-a3bc-11df-a72f-0002a5d5c51b
}
visualizer {
library visualizer
uuid d069d9e0-8329-11df-9168-0002a5d5c51b
}
downmix {
library downmix
uuid 93f04452-e4fe-41cc-91f9-e475b6d1d69f
}
loudness_enhancer {
library loudness_enhancer
uuid fa415329-2034-4bea-b5dc-5b381c8d1e2c
}
agc {
library pre_processing
uuid aa8130e0-66fc-11e0-bad0-0002a5d5c51b
}
aec {
library pre_processing
uuid bb392ec0-8d4d-11e0-a896-0002a5d5c51b
}
ns {
library pre_processing
uuid c06c8400-8e06-11e0-9cb6-0002a5d5c51b
}
}

pre_processing {
mic {
aec {}
}
voice_communication {
aec {}
}
}

I think we should also remove any references to AUDIO_DEVICE_IN_BACK_MIC and AUDIO_DEVICE_IN_SECONDARY_MIC in audio_policy.conf. The latter one is not even a valid value..

I made another observation: We also have a file "/system/etc/aanc_tuning_mixer.txt" which is referenced by libacdbloader.so. Neither the Wileyfox Swift nor the Motorola G3 have it. It seems to set some mixer settings and I'm wondering whether this would override anything we set in mixer_paths.xml ?

Talking of ACDB: We have all sorts of ACDB calibration files in /system/etc/acdbdata/QRD. Do you have any idea what they are good for? I'm not sure whether they are specific to the actual device or just the chipset. But the ones we are using now are from the Wileyfox Swift. Maybe we should use the files from the Trunk stock ROM instead?
[Miscellaneous Android Development] siljaer:
we have already discussed about it, and I have already tried, it doesn't work. I don't why, I have only a few ideas, that's why I was asking you about it, my questions are:

- pre-processors effects work only if they are supported by HAL. So, is android pre-processor AEC supported? maybe only proprietary qualcomm effects are supported

- in audio_effects.conf you can add parameters for an effect. From the sources, it seems that AEC (and AECM, the mobile version for constant latency) use WebRTC algorithm and that has three levels of echo suppression. Unfortunately, I haven't been able to find any hint on how to add such a parameter in audio_effects.conf.

BTW, it looks like AGC code is commented out in many source files.

I tried that a few days ago too. It results in no audio at all (!). However, I will try again, because I've found a new option to add to build.prop to disable dual mic. Maybe it can work now.

EDIT: I have just tried: it's working now. I don't know whether it's because of your new release or because of my addition to build.prop, that for the record is:

ro.config.dualmic=false

it's unclear whether this line also disables preprocessor (someone wrote so....).

I've seen that file too, but it seems it deals with settings not appliable to the trunk. So, I haven't tried anything with it. But you are right, maybe it's needed, so it must be rewritten (how? that's the real issue!).

No, I don't, unfortunately. AFAIK Swift has two mics, so maybe we should use the files from stock. But I've found every sort of stuff for Qualcomm chipsets in the stock ROM. It looks like a standard image that needs only a few customization (if any). However, I will try to figure something more out about those files, maybe it's important.
[Miscellaneous Android Development] siljaer:
Well, I have checked: they have different sizes for sure. Let's try the stock acdb files, then :)

BTW, surfing the stock rom, I have found calmodule.cfg:

libcalmodule_qmc7983.so
libcalmodule_akm.so
libcalmodule_gyroscope.so

qmc7983 is a 3-axys magnetometer. Yes, I guess we haven't nothing like that on board... but I wonder why stock rom has it.
[Miscellaneous Android Development] siljaer:
I have found some answers for it.

I looked for QRD SKUH specs (BTW, is the trunk really a SKUH?), but I could not find anything eolxcept this:

http://blog.chinaunix.net/uid-20321537-id-5155640.html

Then, I followed instructions here:

http://xdaforums.com/android/software-hacking/how-to-convert-qualcomms-dtb-to-dts-t3221223

So I extracted kernel configuration of stock rom. It contains modules for several magnetometers and gyroscope, the same hardware that trunk (stock rom) cannot initialize at boot.

Have you any QRD SKUH specs?
[Miscellaneous Android Development] 21prods:
I'm sorry, I don't want to go off topic, but these last posts concerning your investigations to definitely end with the echo during calls make me feel as if I was reading a mystery novel. You people are awesome, I wish I had the knowledge to investigate with you but I'm no more than an end user of your outstanding work.

Enviado desde mi Nexus 5 mediante Tapatalk
[Miscellaneous Android Development] ottmi:
Are you sure? I think you had a syntax error in the audio_effects.conf you posted a while ago in the pre_processing section..

I'm not sure whether it's supported by HAL. But then again it's generic, so why wouldn't it be?

AEC takes only one parameter which has something to do with the delay. I don't know the keyword for it, though, as I haven't found the code where the .conf file is parsed yet.

It works fine without any changes to build.prop.

The dualmic setting is specific to Qualcomm and is only evaluated if Fluence is enabled. If fluence is set to none, it doesn't metter whether it's set or not.

Maybe if using Qualcomm's preprocessing..

I've tried with the Trunk files now, but it doesn't make any difference since they are not being used anyway. The ACDB Loader doesn't initialize properly, so it doesn't use any calibration data..
[Miscellaneous Android Development] ottmi:
I'm pretty sure it's a SKUH, at least the board ids match, but I also don't have any specs for this board. The DTBs in the stock ROM contains configuration data for many boards, not just the SKUH.

I don't think there's any more sensors on the board than what we have now: light, proximity, acceleration. Of course there's no autodetect on ARM platforms but everything relies on the DTB files, so we don't know for sure. If I have some spare time at my hand i might try compiling i2c-tools for Android and then see whether it's auto-detect yields any additional i2c devices we don't have in our DTB yet.
[Miscellaneous Android Development] siljaer:
I cannot remember. I tried a week ago, maybe a few days more... but a silly typo is a likely explanation

I don't know, but comments say:

# Default pre-processing effects. Add to audio_effect.conf "effects" section if
# audio HAL implements support for them.

Qualcomm's audio road is riddled with pitfalls....
[Miscellaneous Android Development] siljaer:
It would bre really strange to find anything not used in the stock rom... but I'm looking forward to your results :)

BTW, have you any clue about the ODM/OEM of the trunk? Its code name should be L500, as I see it silkscreened on the mainboard and I find that name in the comments too. In the comments they refer to a "uniscope driver"; could it be uniscope?
[Miscellaneous Android Development] Bizen-Ya:
Hi,

i switched to Benefit Ark mixer_paths.xml , it seems to be fine...

<ctl name="HPHL Volume" value="9" />
<ctl name="HPHR Volume" value="9" />

<!-- digital gains for interpolation filters RX1, RX2, RX3 -->
<!-- 84 = 0 dB -->
<ctl name="RX1 Digital Volume" value="86" />
<ctl name="RX2 Digital Volume" value="86" />
<ctl name="RX3 Digital Volume" value="86" />

<path name="secondary-mic">
<ctl name="DEC1 MUX" value="ADC2" />
<ctl name="MICBIAS CAPLESS Switch" value="1" />
<ctl name="ADC2 MUX" value="INP3" />
</path>

<path name="sidetone-handset">

<path name="sidetone-iir" />

<ctl name="IIR1 INP1 Volume" value="53" />

<ctl name="RX1 MIX2 INP1" value="IIR1" />
</path>

<path name="sidetone-headphone">

<path name="sidetone-iir" />

<ctl name="RX1 MIX2 INP1" value="IIR1" />
<ctl name="RX2 MIX2 INP1" value="IIR1" />

<ctl name="IIR1 INP1 Volume" value="53" />
</path>

<path name="speaker-dmic-endfire">
<path name="adc1" />
<ctl name="DEC2 MUX" value="ADC2" />
<ctl name="MI2S_TX Channels" value="Two" />
<ctl name="ADC2 MUX" value="INP3" />
<ctl name="IIR1 INP1 MUX" value="DEC1" />
</path>

I know that the trunk has only one mic, but at the other end there is no more echo i think ( two call and noboby complains right now ).
[Miscellaneous Android Development] ottmi:
There's a new ROM available for download:

http://xdaforums.com/devdb/project/dl/?id=19622

I did some changes to the GPS config files as I had trouble with previous versions obtaining a lock. It now works much better for me, I usually get a lock within a few seconds now.

I also did some modifications to the audio subsystem. Probably nothing you would notice, but basically doing the ground work for further changes to finally fix audio volumes and echo cancellation.

And as always, I've updated to the latest CM13 source..

Yeah, ACDB was messed up with the previous version of my ROM. The new ROM now uses the ACDB libraries from Crackling and calibration files from Trunk. At least now ACDB initializes properly, but there are still error messages left. I've also disabled Fluence in build.prop and enabled the aec effect in audio_effects.conf. However, I'm not sure it actually works (aec that is).

So what does Sound Trigger actually do? There are some references to ACDB in the library..
[Miscellaneous Android Development] siljaer:
If it works for you, good for you! :) Don't ever touch anything more :)

Actually, the changes you quoted only increase slightly the earpiece volume. I guess there's something more if people can hear you now. Probably you also increased mic gain/volume.

For some unknown reason, your phone seems to be immune from the echo and suffers from low volume.

---------- Post added at 14:41 ---------- Previous post was at 14:37 ----------

I don't know exactly, but I've found that the following sequence from stock rom is missing from CM13:

I/soundtrigger( 274): audio_extn_sound_trigger_update_device_status: device 0x2 of type 0 for Event 1, with Raise=0
W/audio_hw_utils( 274): audio_extn_utils_update_stream_app_type_cfg: App type could not be selected. Falling back to default
I/audio_hw_primary( 274): select_devices Selected apptype: 69936
D/soundtrigger( 274): audio_extn_sound_trigger_update_stream_status: uc_id 1 of type 0 for Event 3, with Raise=0
D/ACDB-LOADER( 274): ACDB -> send_audio_cal, acdb_id = 14, path = 0
D/ACDB-LOADER( 274): ACDB -> send_asm_topology
D/ACDB-LOADER( 274): ACDB -> ACDB_CMD_GET_AUDPROC_STREAM_TOPOLOGY_ID
D/ACDB-LOADER( 274): ACDB -> send_adm_topology
D/ACDB-LOADER( 274): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TOPOLOGY_ID
D/ACDB-LOADER( 274): ACDB -> send_audtable
D/ACDB-LOADER( 274): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TABLE
D/ACDB-LOADER( 274): ACDB -> AUDIO_SET_AUDPROC_CAL
D/ACDB-LOADER( 274): ACDB -> send_audvoltable
D/ACDB-LOADER( 274): ACDB -> ACDB_CMD_GET_AUDPROC_GAIN_DEP_STEP_TABLE
D/ACDB-LOADER( 274): ACDB -> AUDIO_SET_AUDPROC_VOL_CAL
D/ACDB-LOADER( 274): ACDB -> send_afe_cal
D/ACDB-LOADER( 274): ACDB -> ACDB_CMD_GET_AFE_COMMON_TABLE
D/ACDB-LOADER( 274): ACDB -> AUDIO_SET_AFE_CAL
D/ACDB-LOADER( 274): ACDB -> send_hw_delay : acdb_id = 14 path = 0
D/ACDB-LOADER( 274): ACDB -> ACDB_AVSYNC_INFO: ACDB_CMD_GET_DEVICE_PROPERTY
I/audio_hw_utils( 274): audio_extn_utils_send_app_type_cfg app_type 69936, acdb_dev_id 14, sample_rate 48000
D/audio_hw_primary( 274): select_devices: done
[Miscellaneous Android Development] siljaer:
I have found a way to trigger the bug (?):

- Open messaging app

- press "back" two times
[Miscellaneous Android Development] Bizen-Ya:
yes this is really better , thank you again !

---------- Post added at 06:14 PM ---------- Previous post was at 06:11 PM ----------

Everything is working fine now, except one thing..

My phone is very hot when i run two apps ( waze and spotify together ), it was already like that before.

With this rom, the overheat shutdown seems to happen sooner than the stock one ( ~ 80°c )

you have the same issue ?
[Miscellaneous Android Development] siljaer:
some vital signs (at least)

Well, by adding those files I mentioned before, by modifying audio_effect.conf in order to use android preproccessor instead of qcom's and by adding:

pre_processing {
voice_communication {
aec {
}
}
voice_call {
aec {
}
}
voice_uplink {
aec {
}
}
}

I've got:

8-03 19:06:30.334 5431 5431 D hardware_info: hw_info_append_hw_type : device_name = handset-mic
08-03 19:06:30.334 5431 5431 D audio_hw_primary: disable_snd_device: snd_device(34: handset-mic)
08-03 19:06:30.335 5431 5431 I AudioFlinger: loadHwModule() Loaded primary audio interface from QCOM Audio HAL (audio) handle 1
08-03 19:06:30.335 5431 5431 I AudioFlinger: openOutput(), module 1 Device 2, SamplingRate 48000, Format 0x000001, Channels 3, flags 2
08-03 19:06:30.335 5431 5431 D audio_hw_primary: adev_open_output_stream: enter: sample_rate(48000) channel_mask(0x3) devices(0x2) flags(0x2) stream_handle(0xf6277100)
08-03 19:06:30.335 5431 5431 W audio_hw_utils: audio_extn_utils_update_stream_app_type_cfg: App type could not be selected. Falling back to default
08-03 19:06:30.335 5431 5431 D audio_hw_primary: adev_open_output_stream: Stream (0xf6277100) picks up usecase (deep-buffer-playback)
08-03 19:06:30.335 5431 5431 I AudioFlinger: AudioStreamOut::open(), mHalFormatIsLinearPcm = 1
08-03 19:06:30.336 5431 5431 I AudioFlinger: HAL output buffer size 960 frames, normal sink buffer size 960 frames
08-03 19:06:30.348 5431 5431 V PreProcessing: PreProcessingLib_GetDescriptor() got fx Acoustic Echo Canceler

It seems to work somehow, but I need more testing.
[Miscellaneous Android Development] ottmi:
Seems to work fine for me. Can you try a re-flash and wipe system and cache before?

So you need to have Sound Trigger to make AEC work?
[Miscellaneous Android Development] siljaer:
I've done it. Still almost random reboots. However, if it's just me then there's something wrong with MY phone (sw or hw).

I've checked. If I don't add those files, but only the modified audio_effects.conf, the AEC still appears in the log. So, it's not needed.

I have no proof it's actually used, though. With speakerphone it looks like it's working better, with handset it doesn't work with mixer_paths values known to trigger echo.
[Miscellaneous Android Development] siljaer:
It looks like it's a surfaceflinger bug with latest CM13 sources: our swift "cousins" (among others) are also experiencing that. Probably, for me it's eveb worse because of my habits (back key instead of home to exit apps).

http://xdaforums.com/wileyfox-swift/development/rom-temaseks-unofficial-build-v18-5-t3267354/page19

https://forum.cyanogenmod.org/topic/127690-i9300-keeps-soft-rebooting/

https://forums.oneplus.net/threads/official-cm13-oneplus2-discussions-downloads.427906/page-228
[Miscellaneous Android Development] Sampierdarena:
Hello [MENTION=7319300]ottmi[/MENTION],

I installed the latest version of your ROM. Wipe cache -> wipe ART cache -> Installation.

Maybe it's my problem, I point out that the device restarts by itself, it does very often.

Any suggestions?
[Miscellaneous Android Development] josoft86:
Sampierdarena Hello, for me the same thing with further warming. Disassembled, correct earlier recovery with inclusion of the file: mixer_paths_qrd_skuh.xml of cm-13.0-20160506-NIGHTLY-benefit.zip version which solved most of the echo problem even with an acceptable volume. I solved these bugs I think it could be a more acceptable version that even if the version (cm-13.0-20160506-NIGHTLY-benefit.zip) is the best pity it is not 64-bit. Greetings to all fans.
[Miscellaneous Android Development] ottmi:
That's the joy of compiles early in the month. They usually pull in plenty of new stuff from Android upstream at the beginning of the month and that's not always bug-free..

There have in fact been some fixes to surfaceflinger in the CM13 repo. I'm now compiling a new ROM and will upload it later tonight. That should hopefully fix these issues..

EDIT:

And here it is:

http://xdaforums.com/devdb/project/dl/?id=19676
[Miscellaneous Android Development] ottmi:
It happened to me once or twice that the phone would shut down on a hot day when I was using GPS navigation in my car and charging at the same time.

The default CM13 shutdown temperature is 68°C which is what I'm using and it's the same the stock ROM is using. I suppose we could go a little bit higher than that, maybe 75°C..
[Miscellaneous Android Development] ottmi:
Try the new build and let me know whether it fixed the problem
[Miscellaneous Android Development] siljaer:
yes, but this time there was also an important security fix...

Thank you :) And take it easy, if it isn't working many devices will be affected, not only the trunk...
[Miscellaneous Android Development] Bizen-Ya:
We need to recompile to modify this, or can i test it by changing some file ?

I dont think the stock ROM has the same setting, my phone can get really hotter with the stock
[Miscellaneous Android Development] Sampierdarena:
Hello,

With the new release of 05 August, I tried the "Sound Recorder" and the result is a distorted voice. In fact, even "Ok Google" it does not work anymore, maybe the voice gets distorted.

Maybe it's a problem of my smartphone. Please try to check if it's Bug, or my problem.

Thank you.
[Miscellaneous Android Development] ottmi:
The settings are in /system/framework/framework-res.apk. You will have to unpack, modify, and repack it. Look out for config_shutdownBatteryTemperature in res/values/integers.xml.

But again: I've checked, and the stock rom uses the same values. Unless they have some hack somewhere else that overrides this setting, it's the same.