Wizzup | sure, I'm just waiting for the kernel build to finish to I can test earpiece :) | 00:00 |
---|---|---|
Wizzup | checking if this phone still has android | 00:05 |
Wizzup | kernel is almost done | 00:06 |
Wizzup | uvos: hm, I don't think I get any audio now | 00:25 |
Wizzup | wait I can hear over earpiece | 00:25 |
Wizzup | but indeed the mic does not work | 00:26 |
Wizzup | hmm... | 00:27 |
Wizzup | yeah, to be continued | 00:28 |
Wizzup | uvos: shall I make a fixup commit to disable speaker right pga? | 11:36 |
Wizzup | uvos: so yeah I think CPCAP_REG_RXOA.CPCAP_BIT_A1_EAR_EN is required at least for the earpiece | 11:51 |
Wizzup | but we do have the earpiece pga in your force enable | 11:52 |
Wizzup | oh yeah, that's why I did hear things :) | 11:55 |
Wizzup | uvos: yeah ok so we don't enable the mic capture pga's it seems | 11:56 |
Wizzup | should I enable the "Left Capture Route", or do something else? | 11:59 |
Wizzup | could also just enable Microphone 1 PGA and Microphone 2 PGA | 11:59 |
Wizzup | uvos: fyi I called this one 5.18.14exp | 13:17 |
Wizzup | uvos: so on top of my latest patch I also need this: | 13:47 |
Wizzup | python regtool.py set CPCAP_REG_CC.CPCAP_BIT_MIC1_CDC_EN 1 | 13:47 |
Wizzup | then earpiece works ok | 13:47 |
Wizzup | and then headphone works for input, but not for output | 13:51 |
Wizzup | uvos: so that register is "ADC Right" in the codecs/cpcap.c | 13:57 |
Wizzup | ok, kernel that builds now should work out of the box for speakerphone and handset | 14:05 |
Wizzup | not yet for headset, only mic works there | 14:05 |
Wizzup | (no android dump to compare with) | 14:05 |
Wizzup | uvos: ok with latest experimental it should work ok for speaker and earpiece | 15:27 |
Wizzup | uvos: I suspect we should just make the dapm force enable list a little more exhaustive just in case | 15:28 |
Wizzup | uvos: one time it didn't work, but I had pavucontrol open (the gtk version), maybe that somehow affected it, I did run a reg cmp and there was a small difference | 15:45 |
Wizzup | here:http://dpaste.com/3JD7B5Y3D | 15:45 |
Wizzup | so maybe I should at least also enable the left adc | 15:45 |
eloy | I was looking into porting FBReader from Fremantle, what is the logical place where the svn repos are located? I could only find this: http://repository.maemo.org/extras/pool/fremantle/free/source/f/fbreader/ | 17:36 |
uvos | ok | 17:48 |
uvos | ill try and dump headset at some point | 17:49 |
Wizzup | eloy: there is no one repos for the svn, but let me search for you | 19:14 |
Wizzup | eloy: so normally I look at garage.maemo.org but it seems to be down (atm) | 19:16 |
eloy | ah, well thanks already :) | 19:21 |
Wizzup | I asked about garage, let's see | 19:22 |
Wizzup | easiest might be to just take the patches (assuming they are patched applied onto orig source) and see if they can be forward ported | 19:23 |
Wizzup | (assuming you want to use latest fbreader as a base) | 19:23 |
Wizzup | uvos: ok, that'd be nice | 19:37 |
uvos | musscle memory really kills me when using the d4 with android | 19:54 |
uvos | capslock/shift, home is not tasknav the menu button is instead | 19:54 |
uvos | Wizzup: | 20:01 |
uvos | http://uvos.xyz/maserati/stockinfo/call | 20:01 |
Wizzup | thanks | 20:09 |
Wizzup | and the cpu recording txt, do you know what the output was when recording | 20:10 |
Wizzup | (I can try to guess, just wondering if you remember) | 20:10 |
uvos | pretty sure i dident change it | 20:10 |
uvos | ie its default - earpiece | 20:10 |
eloy | Wizzup: yeah, I'd like to use the latest. I tried compiling the latest Fremantle source, but I'm running into all kinds of C++ errors, so that sounds like a better approach. Modern compilers are less tolerant I think. | 20:13 |
Wizzup | eloy: either that or some of the libs it uses changed | 20:20 |
Wizzup | uvos: ok, ty, will investigate what is needed momentarily for headset | 20:20 |
Wizzup | uvos: looks like we need CPCAP_REG_RXOA.CPCAP_BIT_ST_HS_CP_EN to be 1 | 20:30 |
uvos | Wizzup: sensible | 20:30 |
uvos | dose some widget controll this bit/ | 20:30 |
uvos | ? | 20:30 |
Wizzup | will check momentarily | 20:31 |
eloy | btw, the latest status link in the topic here still links to the fourteenth update instead of the sixteenth | 20:32 |
Wizzup | eloy: fair enough... | 20:32 |
Wizzup | we'll have another newspost soon | 20:33 |
eloy | :D | 20:34 |
uvos | newspost: mapphone calls work!!!!! | 20:35 |
uvos | Wizzup: do you know whats needed in sphones pulse output swtiching callback? | 20:35 |
uvos | i want to takle this nex | 20:35 |
uvos | t | 20:35 |
uvos | unless you have this laying around | 20:35 |
Wizzup | I looked into the api, but didn't have it working, -yet- | 20:36 |
Wizzup | let me find the code | 20:36 |
Wizzup | 5 mins multitasking a bit too much... | 20:36 |
uvos | no rush | 20:36 |
Wizzup | https://github.com/maemo-leste/sphone/commit/7d58c4577c844a8793c42434c4c80eed766f6197 it was this, but it doesn't work atm, I probably made some mistakes, I didn't debug it at all yet and iirc it hard crashed | 20:37 |
Wizzup | that's all I have in any case | 20:37 |
uvos | Wizzup: ok | 20:38 |
Wizzup | probably even some string corruption mistake or so | 20:42 |
Wizzup | but that should at least be the right pa call :) | 20:42 |
Wizzup | uvos: so the corresponding entry is "Headset Charge Pump" | 20:45 |
Wizzup | DAPM wise I think we're ok | 20:45 |
Wizzup | "Headset Right PGA" | 20:45 |
Wizzup | "Headset Left PGA" | 20:45 |
Wizzup | uvos: not sure if I see any code at all that sets this reg | 20:48 |
Wizzup | well, I see a line that sets it to 0 | 20:48 |
Wizzup | maybe the headset charge pump needs a dapm entry, let me debug | 20:52 |
Wizzup | great now ofono ignored the 'accept call' :D | 20:53 |
uvos | i mean if its nessecary for the pga to work at all | 20:53 |
uvos | it should just be set with the pga | 20:53 |
uvos | imo | 20:53 |
Wizzup | it is | 20:53 |
Wizzup | {"HSR", NULL, "Headset Charge Pump"}, | 20:53 |
Wizzup | {"HSL", NULL, "Headset Charge Pump"}, | 20:53 |
uvos | right then i dont see the point of add antoher widget | 20:53 |
Wizzup | and: | 20:53 |
uvos | wait the widget exists? | 20:53 |
Wizzup | {"HSR", NULL, "Headset Right PGA"}, | 20:53 |
Wizzup | {"HSL", NULL, "Headset Left PGA"}, | 20:53 |
uvos | and it dosent set the reg? | 20:54 |
Wizzup | exists where? | 20:54 |
uvos | in the widget array | 20:54 |
Wizzup | I think so... | 20:55 |
uvos | SND_SOC_DAPM_SUPPLY("Headset Charge Pump", | 20:55 |
uvos | CPCAP_REG_RXOA, CPCAP_BIT_ST_HS_CP_EN, 0, NULL, 0), | 20:55 |
uvos | yes | 20:55 |
uvos | CPCAP_BIT_ST_HS_CP_EN | 20:55 |
Wizzup | right, but it's not in the list, but it is referred to from the widget | 20:55 |
uvos | it sets the reg | 20:55 |
Wizzup | it sets it to 0 though? | 20:55 |
Wizzup | but yeah, it might set it to 1 later | 20:55 |
uvos | no it sets it to 0 at startup | 20:55 |
Wizzup | in any case our current code -does not- set it | 20:55 |
Wizzup | maybe it's dapm messing with it, let me try to find out now | 20:55 |
uvos | because the Headset Charge Pump is not active probubly | 20:56 |
uvos | check in debugfs | 20:56 |
Wizzup | active dapm wise? | 20:56 |
uvos | yes | 20:56 |
Wizzup | yes, I wsa at that point | 20:56 |
uvos | its a dapm widget | 20:56 |
Wizzup | and then ofono played a joke on me | 20:56 |
uvos | he | 20:56 |
Wizzup | yeah I think that's it | 20:57 |
Wizzup | so we just force enable the charge pump? | 20:57 |
Wizzup | # cat Headset\ Charge\ Pump | 20:57 |
Wizzup | Headset Charge Pump: Off in 0 out 0 - R2076(0x81c) mask 0x200 out "static" "HSL" out "static" "HSR" | 20:57 |
Wizzup | weird though, I figured HSR or HSL being forced on would power this up | 20:57 |
uvos | no | 20:57 |
uvos | forcing somethign dosent affect the other nodes at all | 20:57 |
Wizzup | ah | 20:58 |
uvos | theres a special check for that | 20:58 |
Wizzup | well, let me build a kernel with added then :) | 20:58 |
uvos | anyhow setting them on by changeing the struct dosent work either | 20:58 |
uvos | because the chain isent checked for some reason | 20:58 |
uvos | (that i dont understand at all) | 20:58 |
Wizzup | right | 21:00 |
Wizzup | let me just add this one for now and test | 21:00 |
Wizzup | building now | 21:03 |
eloy | okay this might not be the most popular choice here, but I'm amazed that I could clone a NodeJS project on my Droid 4, install a whole bunch of dependencies using npm and run a local webserver that does audio stuff and it just worked flawlessly :D | 21:03 |
Wizzup | :D | 21:05 |
Wizzup | eloy: btw garage.maemo.org is back up now, but I can't find fbreader stuff on it (I am not very proficient with garage.maemo.org) | 21:06 |
Wizzup | uvos: the recording to cpu part I suppose would just reroute the call audio to ... what exactly? | 21:36 |
sicelo | eloy: which source did you want to use? fbreader is closed source since a while ago, iirc | 21:36 |
Wizzup | sicelo: you sure? I don't think so | 21:36 |
Wizzup | oh, maybe it is now... | 21:37 |
Wizzup | FBReader is not open-source since 2015. For developers, we offer FBReader SDK: a library that allows creating own ebook readers. | 21:37 |
Wizzup | I have 0.99 locally on my computer, which is foss for sure | 21:37 |
eloy | yeah, it's sad, but the latest foss version will live on forever :P | 21:38 |
Wizzup | https://fbreader.org/files/desktop/fbreader-sources-0.99.4.tgz this still works at least | 21:38 |
sicelo | there's not FBReader 2.x :-) | 21:38 |
Wizzup | uvos: so re: sphone, I will try to fix the rtcom logging now, and then next step I think is to try to make a glib telepathy plugin for calls (and sms, but I want to be able to turn that off) | 21:39 |
sicelo | eloy: anyway, so yes, there was no garage repo for it. using garage was not a requirement. | 21:39 |
eloy | sicelo: I see | 21:39 |
Wizzup | sicelo: yeah we were just searching for a svn or git repo | 21:39 |
Wizzup | but in some cases those don't even exist and it's just a source tarball upload I think | 21:39 |
uvos | Wizzup: the call recording path cant really work at all rn | 21:40 |
uvos | i just ignore it | 21:40 |
uvos | we dont even have the dai to use it | 21:41 |
uvos | Wizzup: so can you switch outputs via pactl? | 21:41 |
uvos | i dont get i - or pactl is buggy | 21:41 |
Wizzup | uvos: let me try to do it now | 21:42 |
uvos | pactl list | 21:42 |
Wizzup | yeah I know how it should work, let me try :) | 21:42 |
uvos | Sink #0 | 21:42 |
uvos | ok | 21:42 |
uvos | alsa_output.0.HiFi__hw_Audio_0__sink, Ports: Earpiece: Internal Earpiece (priority: 200) | 21:42 |
uvos | pactl set-sink-port alsa_output.0.HiFi__hw_Audio_0__sink Earpiece | 21:43 |
uvos | Failure: No such entity | 21:43 |
uvos | ??? | 21:43 |
uvos | pactl set-sink-volume alsa_output.0.HiFi__hw_Audio_0__sink 0.1 | 21:43 |
uvos | works | 21:43 |
Wizzup | I am looking at set-sink-port, but it's not clear to me how to ref the sink | 21:44 |
eloy | Wizzup: yeah, so I guess I'll try to extract the Maemo specific stuff from the tarball and add that on top of the latest open source fbreader repo + other deps | 21:44 |
uvos | alsa_output.0.HiFi__hw_Audio_0__sink works for volume | 21:44 |
Wizzup | uvos: got it | 21:44 |
Wizzup | pactl set-sink-port alsa_output.0.HiFi__hw_Audio_0__sink '[Out] Earpiece' | 21:44 |
uvos | ie set-sink-volum | 21:44 |
uvos | ah out | 21:44 |
uvos | silly | 21:44 |
eloy | might be worth to look for fbreader forks that occured since 2015 | 21:44 |
Wizzup | uvos: yes, silly | 21:44 |
Wizzup | it also works with number | 21:45 |
Wizzup | pactl set-sink-port 20 '[Out] Earpiece' | 21:45 |
Wizzup | (#20 for me) | 21:45 |
Wizzup | (useless otherwise, just fyi) | 21:45 |
uvos | sure | 21:45 |
uvos | ok | 21:45 |
Wizzup | so that's probably why my code did not work :) | 21:45 |
uvos | yeah | 21:45 |
Wizzup | (the [Out] missing) | 21:45 |
Wizzup | loll | 21:45 |
uvos | we need a real way to figure out what sink to use tho | 21:46 |
uvos | i gues you can query the default sink somehow | 21:46 |
uvos | checking | 21:46 |
Wizzup | so I think we can probably configure this | 21:46 |
Wizzup | i.e. we don't need it to be alsa_output.0.HiFi__hw_Audio_0__sink | 21:46 |
Wizzup | we have /etc/pulse/leste.pa.d | 21:47 |
uvos | sure but just using the default sink should be fine | 21:47 |
Wizzup | but yes, that is another thing my code didn't do yet - enumerate the sinks to find the 'right' one | 21:47 |
Wizzup | probably | 21:47 |
uvos | its alsa_output.0.HiFi__hw_Audio_0__sink in hifi mode | 21:47 |
Wizzup | I would find one that has the ports we want | 21:47 |
uvos | and changes to alsa_output.0.Voice_Call__hw_Audio_0__sink | 21:47 |
uvos | when in voice call | 21:47 |
uvos | so that tracks | 21:47 |
Wizzup | ok, latest kernel is in experimental, will test hp | 21:48 |
Wizzup | I need to get a new sd card for my d4 I think, I/O is so slow now | 21:55 |
Wizzup | kernel upgrade makes the device not usable for some time | 21:55 |
Wizzup | all I/O just blocks | 21:55 |
Wizzup | uvos: now CPCAP_REG_RXOA.CPCAP_BIT_HS_L_EN and CPCAP_REG_RXOA.CPCAP_BIT_HS_R_EN need to be set manually | 22:12 |
Wizzup | maybe that's a different problem | 22:12 |
Wizzup | idgi | 22:15 |
Wizzup | uvos: also if you figure this out, please default to earpiece (ofc hp if hp is plugged) :) | 22:27 |
Wizzup | not speaker | 22:27 |
uvos | Wizzup: sphone dose this alleady | 22:43 |
uvos | it sets earpiece when it switches profiles | 22:43 |
uvos | ofc this dosent do anything atm | 22:43 |
Wizzup | ok | 23:12 |
Wizzup | right | 23:12 |
uvos | Wizzup: seting routs works now | 23:22 |
uvos | Wizzup: did you change rtcom yet? | 23:23 |
uvos | if so please push so i can make a sphone release for both | 23:23 |
Wizzup | not yet @ rtcom | 23:24 |
Wizzup | probably tomorrow | 23:25 |
Wizzup | :) | 23:25 |
uvos | Wizzup: anyhow new sphone with working audio_route_triggeris on the way https://github.com/maemo-leste/sphone/commit/303cf47d0d0322120044a67136e4510a4b887ee4 | 23:29 |
Wizzup | sweet | 23:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!