Droid 4: make audio calls work in all normal scenarios

[levomer]

can't use headphone during calls.

[MerlijnWajer]

Thanks for reporting. I assume that the earpiece does not work for you as well?

[levomer]

right, but it worked great will playing audio from file.

[MerlijnWajer]

I think this a known issue currently, I believe @IMbackK had some patches that might make some of the other components work for calls, but this is something we have to fix in the kernel.

(We're still working on making the phone and conversation app behave, and work well with audio routing)

[IMbackK]

yes this is a known issue/bug in the droid 4's kernel.

[levomer]

@IMbackK this issue/bug also prevent the use of bluetooth headphones during calls?

[IMbackK]

yes this issue prevents any and all outputs except the speakerphone working, and even that only works if the register state happens to line up when the call is entered, ie speakerphone is also really broken.

The problem is also not understanding why this happens in hardware, setting up the device for a call on any output incl. bluetooth is extremely simple with just a couple of registers needed as all the needed audio operations and filters are implemented in hardware with no cpu involvement on d4, but the current droid 4 audio driver is implemented in a framework in the kernel not suited to cases like the d4 where audio may be setup go from some device to some other device with no cpu involvement.

[IMbackK]

to descibe this a bit more

So the combination of the generic graph-card and cpcap-codec that together assemble to be the audio driver on mapphones use the asoc framework

to save power asoc has dapm, in dapm every hw device (ie dai, amp, mixer, switch, whatever) is a node, nodes can be connected to eatch other and audio flows to/from dais to/from output nodes thrugh the nodes. when a dai is active all the nodes downstream of it or upstream of it are powerd on. The framework dose not let you power on nodes for any other reason.
you can observe this in:
/sys/kernel/debug/asoc/Mapphone\ Audio/cpcap-codec.0/dapm/

while for instance playing music through the speaker the you can start at Speaker Left PGA and work your way up the chain, note that as soon as you break the chain all the downstream nodes will be powered off.

When you go into a voice call, the chain is correctly reconfigured and you will note that now the voice if is at the base of the chain.
The problem is the that the voice if is considered inactive by the kernel, this is because the kernel is not using this if at all. Because it isent, the modem is using it. this causes all the downstream nodes to be put in off state.
Particularly the $(WHATEVER)PGA nodes are off, the $(WHATEVER)PGA nodes control bits in the CPCAP_REG_RXCOA register. You can check out the bits in this register with:
cat /sys/kernel/debug/regmap/spi0.0/registers | grep 0824

This register controls what output device output amp is connected to. If you look at the MC13783 datasheet it looks like the register would work like a mixer that allows you activate any outputs you want, but in reality cpcap has stict requirements on what are valid bit patterns. you can only have 2 associated bits set to activate amps for a left and right channel and having no bits set is also not valid.
Invalid register settings cause cpcap to behave fairly weirdly, with behavior also being influenced by the previous register settings, this is the reason why when you disable all outputs often the left speaker will turn on while sometimes this will have other effects. setting 3 or more outputs also has quite unpredictable results.

Anyhow if you patch the kernel to allow writes on regmaps and set CPCAP_REG_RXCOA appropriately while in a call the call audio will work absolutely fine in every way.
So the problem is that we cant create a if for the modem thats allways on when motomdm driver is in a call, because the cpcap-codec driver is just a codec driver and the generic graph card driver dosent supply sutch a facillty. as far as i can tell there is no way to make the cpcap-codec driver do what we want. We could fork the graph-card driver to add what we need, and this is what i have atempted, but thus far i have not been able to make this work

[MerlijnWajer]

I think we should build a kernel that allows writing the registers for now, we can just have it in -devel only. I'd really like to test some call audio.

[MerlijnWajer]

Ok, on my kernel I can now see the register values:

root@maindroid:~# cat /sys/kernel/debug/regmap/spi0.0/registers | grep 0824
0824: 0000

Reading the code, writing it could be done like (note: untested!):

echo -n 0824 0001 > /sys/kernel/debug/regmap/spi0.0/registers

I don't know this works and what value I should write, so that's to be figured out next...

[MerlijnWajer]

I guess the correct value ought to be BIT(CPCAP_BIT_PGA_CDC_EN) ?

[MerlijnWajer]

I could try to help with a graph-card-driver fork if the work is shared somewhere, but I'll probably have more questions. :)

[MerlijnWajer]

00:24 < Wizzup> as in I'm trying to figure out what to write so I can test that it works for me
00:24 < uvos__> Wizzup: hmm?
00:26 < uvos__> Wizzup: you just have to write the route you want to use
00:26 < uvos__> you can use registers as set when a audio file is playing via whatever route you want
00:26 < uvos__> then place a call and write the register back to that state
00:30 < Wizzup> uvos__: I don't think I know how
00:30 < Wizzup> oh, hm...
00:30 < Wizzup> so does that make earpiece work for calls too?
00:30 < Wizzup> (because you wrote 'whatever route you want')
00:30 < uvos__> yes
00:31 < uvos__> also headphones
00:31 < uvos__> whatever you want
00:31 < Wizzup> hmm
00:31 < Wizzup> so how many registers do I have to look at, not just the one you mention then?
00:32 < uvos__> just the one really
00:32 < uvos__> unless you also want to use a different mic
00:35 < Wizzup> so 0824 ?
00:36 < uvos__> if thats the resiter i mentioned
00:36 < uvos__> i dont know it by heart :P
00:41 < Wizzup> uvos__: https://github.com/maemo-leste/bugtracker/issues/584#issuecomment-1120241298
                looks like it

[MerlijnWajer]

Looks like the register doesn't change when playing music on any output:

# grep 0824 registerlogs/*.txt
registerlogs/earpiece-music.txt:0824: 0000
registerlogs/headset-pluggedin.txt:0824: 0000
registerlogs/headset-unplugged.txt:0824: 0000
registerlogs/nothing-playing.txt:0824: 0000
registerlogs/speaker-music.txt:0824: 0000

[MerlijnWajer]

23:39 < Wizzup> but for the record, if you're in a call, go to pavucontrol and set the output you
                want, and then also the register write
23:39 < Wizzup> echo 081c 0002 > /sys/kernel/debug/regmap/spi0.0/registers
23:39 < Wizzup> that's speakerphone
23:39 < Wizzup> echo 081c 0001 > /sys/kernel/debug/regmap/spi0.0/registers
23:39 < Wizzup> that's earpiece
23:39 < Wizzup> echo 081c 0260 > /sys/kernel/debug/regmap/spi0.0/registers
23:39 < Wizzup> that's headphone

[MerlijnWajer]

23:52 < Wizzup> sicelo: ok mics are 0
23:53 < sicelo> :-)
23:53 < Wizzup> I can hear myself when pavucontrol is set to speakerphone
23:54 < Wizzup> but not when it's set to earpiece
23:56 < Wizzup> uvos: ok so it looks like mic1/mic2 are 0 on my phone by default, and only in
                speakerphone mode in pavucontrol do I hear the d4
23:56 < Wizzup> uvos: does that sound familiar?
23:57 < Wizzup> tmlind: ^^
23:57 < uvos> hmm what
23:58 < sicelo> 1592517205 <sicelo> got sound on N900 with a phone call after all :) N900 can 'hear'
                the other person quite good. i can't really hear N900 on the ohter phone. will test
                further tomorrow
23:58 < sicelo> almost two full years ago
23:59 < Wizzup> uvos: what in particular should I elaborate on :)
23:59 < uvos> uvos: ok so it looks like mic1/mic2 are 0 on my phone by default, and only in
              speakerphone mode in pavucontrol do I hear the d4
23:59 < uvos> are 0 what?
23:59 < Wizzup> 0% out of 100%
23:59 < Wizzup> so it's literally silent
23:59 < Wizzup> which part of the puzzle of why I never heard the d4 on the remote side
Day changed to 11 May 2022
00:00 < Wizzup> on top of that I also only hear the d4 if the pavucontrol output device is speakerphone
00:00 < Wizzup> if it's earpiece or headphone I can't hear it
00:00 < uvos> the mic only woring in some modes is familiar
00:00 < Wizzup> oh, and I had to switch the "left" item to mic1 or mic2
00:01 < Wizzup> right
00:01 < Wizzup> "left" in the alsamixer F4 capture devices
00:01 < uvos> it has the same problem as the output amps
00:01 < uvos> just in a different place

[MerlijnWajer]

So things to do now, I think:

1. Figure out register required for input when not in speakerphone mode (@IMbackK said he doesn't have the android register dumps at the moment)
2. Write dbus-scripts or sphone module that uses the register hacks to perform switching, maybe route-registerhack

See if with this module, sphone phone call work nicely

[MerlijnWajer]

00:13 < uvos> sphone calls the function more than once becasue that way it dosent have to keep track of what module loaded when and if one that requires libhildon allready loaded
00:13 < uvos> Wizzup: sphone can run sh scripts out of the box btw
00:14 < uvos> Wizzup: see this module https://github.com/maemo-leste/sphone/blob/master/src/modules/external-exec.c
00:16 < Wizzup> ok, but on what events?
00:16 < Wizzup> like if I press 'speaker' or something, there's no event, right?
00:16 < uvos> no i was expecting you just wanting to hack a working setup for one route into it
00:16 < uvos> that you could do on CallAwnserd
00:17 < Wizzup> right
00:17 < Wizzup> that can also be done with dbus-scripts, but yes, sphone itself might be easier
00:17 < Wizzup> well I would probably just go for the earpiece route, but that first requires working input in that mode
00:17 < Wizzup> in speakerphone mode I get nasty noise cancelling issues
00:17 < Wizzup> so that's not useful for day-to-day stuff
00:18 < uvos> the speakerphone headphone etc buttons in sphone actually do nothing at all btw
00:18 < uvos> https://github.com/maemo-leste/sphone/blob/897e852d3eab9ef0cf1aba23ff3975ee1b0f2221/src/modules/route-pulseaudio.c#L189
00:18 < uvos> i never implemented it since it cant be tested
00:20 < Wizzup> why not?
00:20 < Wizzup> with register hacks it can right?
00:20 < uvos> sure i mean via pulse
00:20 < uvos> the module is called route-pulseaudio not route-registerhacks
00:20 < Wizzup> :p
00:20 < uvos> anyhow you get https://github.com/maemo-leste/sphone/blob/master/src/modapi/types.h#L36
00:20 < uvos> in there
00:20 < uvos> (this function)
00:22 < Wizzup> right
00:22 < Wizzup> is it possible to have more than out route plugin?
00:22 < uvos> yes
00:22 < Wizzup> like what if I actually made a route-registerhack :)
00:22 < Wizzup> can we use them both at once?
00:22 < uvos> sure
00:22 < uvos> yes
00:22 < Wizzup> (well preferrably pa first)
00:22 < Wizzup> it almost seems worth it to me
00:23 < Wizzup> (for now)
00:23 < uvos> eh
00:23 < Wizzup> well there's many things that are in flight / work in progress, but if with some simple work we can make the d4 actually make calls reliably, I think that's pretty big
00:24 < Wizzup> of course it's not a ready solution in that sense
00:24 < Wizzup> but if it allows me to toy around with making calls, I think that's pretty neat
00:25 < Wizzup> like, I would switch my main device over if the following worked: (1) stable ofono (2) audio in calls (3) telepathy conversations with sms working
00:25 < uvos> you dont have to write a multi page motivation statment  to me, just do it if you like
00:25 < uvos> i just would not do so myself, since i dont condone sutch terrible hackery
00:26 < uvos> and yeah sure would be neat

[MerlijnWajer]

So what's left to make this work in a hackish (but stable) way:

• implement some datapipe filtering in sphone to restore certain regs before pulseaudio is called
• add regs for headphone and speaker
• add code to switch to speaker (and back to handset) using pa

I've been making calls for weeks now on my droid 4, and it's been pretty good. (some local changes are required atm)

[MerlijnWajer]

The non-hacky path would involve mailing the kernel folks and figuring out how we can get alsa dapm to behave.

[MerlijnWajer]

I think this is mostly fixed in -devel, right?

[levomer]

Yes, thanks.
I check branch maemo-6.1, and I manage to set the earpiece and the headphone setup.
The Bluetooth work as well?

[levomer]

Succeed to use headphone during calls.

[MerlijnWajer]

Great to hear, I don't think bluetooth audio works yet for calls.

[IMbackK]

please dont close this untill a proper (ie non hacky) kenrel implementation is found. in practice it is true that it works atm from a users perspective