xray256 has quit [Ping timeout: 260 seconds]
xray256 has joined #maemo-leste
wunderwungiel[m] has quit [Ping timeout: 240 seconds]
M1peter10[m] has quit [Ping timeout: 240 seconds]
BlagovestPetrov[ has quit [Ping timeout: 248 seconds]
aat596 has quit [Ping timeout: 240 seconds]
humpelstilzchen[ has quit [Ping timeout: 260 seconds]
MartijnBraam[m] has quit [Ping timeout: 260 seconds]
Caleb[m] has quit [Ping timeout: 252 seconds]
scops has quit [Ping timeout: 252 seconds]
mighty17[m] has quit [Ping timeout: 256 seconds]
ungeskriptet has quit [Ping timeout: 248 seconds]
Pali has quit [Ping timeout: 240 seconds]
xmn has joined #maemo-leste
wunderwungiel[m] has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
ungeskriptet has joined #maemo-leste
Caleb[m] has joined #maemo-leste
belcher has quit [Ping timeout: 240 seconds]
BlagovestPetrov[ has joined #maemo-leste
humpelstilzchen[ has joined #maemo-leste
mighty17[m] has joined #maemo-leste
belcher has joined #maemo-leste
yanu has quit [Ping timeout: 276 seconds]
aat596 has joined #maemo-leste
M1peter10[m] has quit [Ping timeout: 240 seconds]
mighty17[m] has quit [Ping timeout: 250 seconds]
scops has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
mighty17[m] has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
belcher has quit [Ping timeout: 276 seconds]
belcher has joined #maemo-leste
sunshavi_ has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
sunshavi has joined #maemo-leste
<tmlind> no idea on the voice call mic issues.. but i'm slowly rebasing patches for v5.18, there are bunch of n_gsm fixes that just got merged, also fixed a few module reload issues for the d4 serdev drivers but have not yet pushed out anything, maybe over the weekend
<tmlind> unlikely any of these affect m-l, but being able to reload the modules makes development easier, that's been buggy for a while
<Wizzup> agreed, great
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
<Wizzup> tmlind: but you have voice calls working on non-speakerphone for you still?
<tmlind> Wizzup: i only have been using speakerphone and some hackish scripts, no ofono so far..
<Wizzup> ok, how is noice cancelling for you?
<Wizzup> yeah ofono doesn't manage our audio routes either
<Wizzup> sorry, echo cancelling*
<Wizzup> when I tried speakerphone it was not usable due to echo
mardy has joined #maemo-leste
<Wizzup> I can load the pa echo cancelling module and try that of course
<Wizzup> I had the switch on in alsamixer I think
<tmlind> Wizzup: mdm6600 has built in noise cancellation, i keep that enabled in the alsamixer all the time
<Wizzup> yeah I had that on too
<Wizzup> maybe it needs to be on at the start of the call and I didn't have it then or something
<Wizzup> not sure what else it could be
yanu has joined #maemo-leste
uvos__ has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
uvos__ has joined #maemo-leste
uvos__ has quit [Ping timeout: 252 seconds]
uvos__ has joined #maemo-leste
<uvos__> Wizzup: we cant add pa noise cancelation or any filter whatsoever since the audio never passes throug the cpu
<uvos__> that said the built in echo cancelation worked fine when i used it
<uvos__> s/noise/echo
uvos__ has quit [Remote host closed the connection]
Pali has joined #maemo-leste
macros_ has joined #maemo-leste
macros_ has quit [Quit: Closed IRC Client]
macros_ has joined #maemo-leste
macros_ has quit [Ping timeout: 260 seconds]
macros_ has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
<Wizzup> uvos: I think we can, since the audio leaves the speakers?
uvos__ has joined #maemo-leste
<uvos__> Wizzup: no the speakers are directly connected to the modem in this mode
<Wizzup> aha
<uvos__> nothing you do on the cpu can change the audio ouptut
<Wizzup> ok, well, I am pretty sure it was on in alsamixer but it was clearly not working
<uvos__> its all in hw the omap4 can be off in a call for all the modem cares
<Wizzup> right
<uvos__> there is a way you could do it tho
<Wizzup> I don't think we need to investigate that way atm, I'd rather figure out why the echo cancel doesn't work even though it's on
<uvos__> theres a modem<->cpu dai that android uses for call recording
<Wizzup> aha
<uvos__> you could use that path all the time and disconnect the speakers from the mode
<uvos__> but this means looksing the awsome talk time the d4 has
<Wizzup> right
<Wizzup> btw, I tried to use ofono + data again on the d4 today while travelling and about every time I do it, it works for a bit, and then bugs in our ofono driver bite me hard
<Wizzup> I'll try to do a few more calls when I get home in an hour or two, see if I can get echo cancellation to work
<uvos__> iirc cpcap provides eco cancellation not the mdm
<uvos__> so maybe check the datasheet for the bit
<Wizzup> if you know how I can figure out the required registers for earpiece/hp... that'd be neat
<uvos__> but im pretty sure it was working
<Wizzup> maybe writing to the same register somehow causes issues
<Wizzup> I will try again
<Wizzup> I guess for input mostly the handset matters, not hp so much
enyc has quit [Ping timeout: 248 seconds]
enyc has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
ceene has quit [Remote host closed the connection]
macros_ has quit [Quit: Closed IRC Client]
xmn has joined #maemo-leste
<uvos__> your freeing an uninitalized pointer
<uvos__> (you fail to set data in init)
<Wizzup> uvos__: let me fix that
<Wizzup> the code wasn't quite ready for normal usage yet :)
<tmlind> Wizzup, uvos__: pushed out an updated v5.18-rc6 based topic branch for d4 modem serdev stuff: https://github.com/tmlind/linux/commits/serdev-gsm-pending-v5.18
<tmlind> as always, had to first fix yet another kernel regression for the phy, one for n_gsm debug.. rebased on the recern n_gsm changes, fixed up issues on reloading the d4 serdev modules
<tmlind> probably no need to backport anything to m-l
<tmlind> will do a v5.18-rc based topic branch for the pending pvr patches, i think i have one fix i should improve a bit and then send out, then backport freemangordon's patches in linux next
<tmlind> but that will likely be few days
<tmlind> hmm i also have a musb pm fix for dumb chargers that i need to test
<tmlind> looks like with some dumb chargers musb never idles currently..
<Wizzup> I can try to rebase on m-l tree on this, I suppose we don't have the pvr stuff on top of it yet?
<tmlind> Wizzup: best to wait few days so we get a much cleaner pvr topic branch
<Wizzup> ok, I can wait
<tmlind> i think we pretty much only have one pvr kernel patch left now :)
<Wizzup> I plan to put me teeth in ofono on the d4 and not let go once it works in a stable manner - it's been the source of much frustration in my day to day usage :P
<Wizzup> right, sweet
<tmlind> well one patch left for omapdrm for mainline i mean, the whole pvr kernel driver is a big mess
<Wizzup> right
<tmlind> Wizzup: yeah ok, i suggest you use some temporary shell script to change the cpcap voice output if you need that for own usage
<tmlind> well could be clock changes are also needed.. uvos knows
<tmlind> hmm so the serial console issue again.. so that happens on shutdown or reboot?
<tmlind> and serial console needs to be detached for it to happen?
<tmlind> i could not reproduce the last time i tried with just a kernel and a minimal filesystem so some more info would be nice
<tmlind> too much computing for me already today, will be mostly offline for the rest of the day though :)
<Wizzup> tmlind: with voice output, do you mean for speakerphone/headphone/earpiece, or you mean input?
<Wizzup> tmlind: if for output from the call, I'm working on a temporary sphone module for that
<Wizzup> if for input from the call, I don't know how to get it to work with anything but speakerphone yet
<Wizzup> input for the call*
<Wizzup> I think we should re-test the serial problems on 5.18
<Wizzup> no need to try to reproduce it on older
<tmlind> Wizzup: ok yeah let's retest on 5.18
<tmlind> Wizzup: sounds like you're all set with a temporary sphone module then, that's better than a shell script :)
<Wizzup> tmlind: right, apart from the fact that switching to earpiece or headphone is not useful as the input doesn't work then, so the other side cannot ehar me
<Wizzup> hear me*
<Wizzup> so really only speakerphone 'works' at this point (and I still need to re-test the echo cancellation alsamixer stuff again)
<uvos__> ucm should set the echo cancellation correctly
<uvos__> if it dosent its a bug
<Wizzup> it was set but didn't work, but I will re-test to rule out pebcak
<uvos__> ok
pere has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
uvos__ has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
uvos__ has quit [Ping timeout: 252 seconds]
uvos__ has joined #maemo-leste
<buZz> ait, borrowing a pinephone soon
<buZz> oh nice, voice routing stuff coming soon? :) my mom will be happy
<buZz> i was discussing yesterday with dreamer a bit, and we both thought it would be cool if we could run asterisk and get the voice routing into that
<dreamer> hehe
<dreamer> something we've been saying for years already
<dreamer> no clue how doable though
<Wizzup> buZz: well I'd be happy when it works with headset, not just speakerphone
<Wizzup> but we'll get there I think
<Wizzup> hmmm dreamer, don't you run android on those things?
<sixwheeledbeast> Does it even need asterisk?
<dreamer> Wizzup: I have a dual boot and a leste
<dreamer> but personal dev focus lately has been nearly entirely on music :#
<buZz> sixwheeledbeast: the idea was doing locally run voicemail mostly
<buZz> and call screening, possibly some IVR to catch spammers etc
<sixwheeledbeast> oh i see, I am not much of a voicemail user. I assume telepathy-gabble will be able to do calls via XMPP like N900?
<sixwheeledbeast> well fremantle
Bratch has joined #maemo-leste
l_bratch has quit [Read error: Connection reset by peer]
Bratch is now known as l_bratch
<Wizzup> sixwheeledbeast: yes, planned
<Wizzup> dreamer: ok, maybe you can help get some debug regs later
Twig has joined #maemo-leste
<dreamer> Wizzup: regs?
<Wizzup> sry mtg
<dreamer> one of my installs is the "dumb user doing dist-upgrade once every 6-12 months" which imo is a good indication for stability ;)
<dreamer> mtg?
<Wizzup> meeting
<dreamer> ah :)
akossh has joined #maemo-leste
<buZz> dreamer: there's some registers on the modem/baseband or something that determine how/where audio gets routed
<buZz> the android might help to show which settings are used for what :)
<Wizzup> right and I think uvos__ had done that before
<dreamer> buZz: aha
<lel> MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/617 (pinetab image loads pinephone braveheart dts)
<Wizzup> uvos__: thx for that find btw @ not setting data
<Wizzup> uvos__: can you ping me when you're home?
Twig has quit [Ping timeout: 256 seconds]
uvos has joined #maemo-leste
<uvos> Wizzup: im here
Danct12 has quit [Quit: Quitting]
<Wizzup> uvos: unrelated but I just made a call, and the n900 started ringing, but ofono didn't let sphone know until I hung up
<Wizzup> sphone: comm-ofono: Error: Timeout was reached
<Wizzup> sphone: comm-ofono: call: /motmdm_0/voicecall01, state: Active, line identification , emergency: 0
<Wizzup> sphone: comm-ofono: call_added_cb: /motmdm_0/voicecall01
<Wizzup> sphone: comm-ofono: ofono_voice_call_properties_add_handler: /motmdm_0/voicecall01
<Wizzup> sphone: manager: check_needed_state: call state Active
<Wizzup> sphone: manager: check_needed_state: incall true, incall_no_route false
<Wizzup> sphone: sphone-mce: call_mode_trigger: active
<Wizzup> one more for the bucket of ofono bugs :)
<Wizzup> also if there's an active call in this state (well, according to ofono or sphone), you can't "hang up"
<uvos> you sure that was ofonos fault?
<uvos> (the n900 thing)
<Wizzup> yes. 100%
<Wizzup> this is entire consistent with it not getting other notifications like data connection ready, sms received, etc
<Wizzup> it's random, of course
<uvos> ok
<uvos> Wizzup: ill do the reg dumping on android later
<Wizzup> ok :)
<uvos> like in 1h
<Wizzup> cool
mardy has quit [Quit: WeeChat 2.8]
akossh has quit [Quit: Leaving.]
<Wizzup> ok, this time when I toggled it (off, on) noise cancelling worked
<Wizzup> (had to get another person involved and get them to walk away)
Danct12 has joined #maemo-leste
tk has quit [Quit: Well, this is unexpected.]
tk has joined #maemo-leste
<Wizzup> great
<Wizzup> interesting to see 0006 for 081c
<uvos> which one?
<uvos> handset has 0x1
<uvos> as expected
<uvos> ah speakerphone
<uvos> right
<uvos> yeah thats the real value for it
<uvos> 0x0 is invalid
<uvos> it should never be 0, its a mux 0 makes no sense
<Wizzup> I've seen it at 0002
<uvos> Wizzup: right android is enabling the left speaker too
<uvos> even though it dosent exist
<uvos> this is harmless
<uvos> i think its because the code base is shared and xt912 has 2 speakers
<uvos> also mz6xx
<uvos> anyhow muteing the mic in android changes CPCAP_REG_TXI
<Wizzup> I see
<uvos> maybe check what it is in leste
<Wizzup> when not in calls:
<Wizzup> # cat /sys/kernel/debug/regmap/spi0.0/registers | grep 0814
<Wizzup> 0814: 0084
<Wizzup> compared to 0cc0 in android?
<uvos> 0cc6
<uvos> and 0cc0 muted
<Wizzup> right
<Wizzup> hm 0828 is also diff for headset vs speakerphone
<Wizzup> there is also CPCAP_REG_TXMP
<uvos> ok
<Wizzup> its mic gain
<Wizzup> I guess?
<uvos> so the bit its setting in 0814 is ATXINEN
<uvos> that makes sense (mic amp enable)
<uvos> but we have that set
<uvos> and "ATXOUTEN Reserved for output TXOUT enable, currently not used"
<uvos> i gues this has maybe a different meaning in cpcap
<uvos> than mc13783
<Wizzup> yeah
<Wizzup> hm CPCAP_REG_TXI also changed for headset and speakerphone
<uvos> im sure they change all the gains and such
<uvos> i would just place a call on leste
<uvos> and then sync up the headset register values with android untill it works
<uvos> thats basicly what i did
<uvos> and there was just one bit or so that was really nessecary that was missing
<uvos> s/headset/handset
<uvos> (besides 081c)
<Wizzup> ok
<Wizzup> I think the left/right being set to the right mic also helps with echo cancel somehow?
<uvos> no idea
<Wizzup> I think I synced up most in the 0x8* range
<Wizzup> echo 0804 60df > /sys/kernel/debug/regmap/spi0.0/registers
<Wizzup> this one I think
<Wizzup> from 60cf to 60df
<Wizzup> at least that seems to make the difference
<Wizzup> speakerphone also works with that
<Wizzup> interesting
<uvos> speakerphone with 081c at 0 has really wierd behavior
<uvos> if you mess with the other regs
<Wizzup> anyway maybe try this:
<Wizzup> echo 0804 60df > /sys/kernel/debug/regmap/spi0.0/registers
<uvos> CPCAP_REG_CC
<Wizzup> codec
<uvos> so what bit makes the difference?
<Wizzup> 60cf vs 60df
<uvos> so bit 5
<Wizzup> yes
<Wizzup> sorry it took me a bit to remember bin() in python
<Wizzup> so is that CPCAP_BIT_AUD_LOWPWR_SPEED ?
<Wizzup> wait nvm
<uvos> CPCAP_BIT_MIC1_CDC_EN
<uvos> right
<Wizzup> yeah 0 indexed
<uvos> that makes sense :)
<Wizzup> ACD left/right ?
<uvos> so do we set CPCAP_BIT_MIC1_CDC_EN when in hifi mode?
<Wizzup> adc*
<uvos> or is this a indipendant bug
<Wizzup> we always set it to 0 at least in cpcap.c
<uvos> ok
<uvos> so its just a oversigt then
<uvos> let me check what android dose
<Wizzup> you mean the old kernel src?
<uvos> whilest recording ti cpu
<Wizzup> ok
<Wizzup> if you're on it, maybe you can also check out the headphone setup, although I guess that maybe just works
<Wizzup> let me try that
<uvos> i dont have a headset with mic
<uvos> and android can tell
<uvos> (ie it will use the internal mic in this case)
<Wizzup> right
<uvos> i dont get what register CPCAP_REG_CC is in mc13783 datasheet
<uvos> (also why the heck dose the datasheet not give register values)
<Wizzup> is this the same ic?
<uvos> this annoys me every time
<uvos> no
<uvos> but some hw blocks are the same
<uvos> the audio block is one of those
pere has quit [Ping timeout: 240 seconds]
<Wizzup> can't reproduce it right now, I think I'm too tired, but that bit was the last one I changed and it made the diff
<uvos> Wizzup: ok
<uvos> i added recording to cpu register state
<Wizzup> is that in handset?
<Wizzup> or speakerphone?
<Wizzup> looks like a big difference in regs :p
<Wizzup> most things except for 0x0814
<uvos> thats recording from mic1
<uvos> and no audio output
Pali has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
<Wizzup> ok
uvos__ has quit [Remote host closed the connection]
uvos has quit [Remote host closed the connection]