mrkrisprolls has quit [Ping timeout: 272 seconds]
vectis has quit [Ping timeout: 245 seconds]
Daanct12 has joined #maemo-leste
vectis has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
asrieldreemurr has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
BenLand100 has quit [Read error: Connection reset by peer]
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
ikmaak has quit [Ping timeout: 252 seconds]
ikmaak has joined #maemo-leste
vgratian has left #maemo-leste [#maemo-leste]
vgratian has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
vagag has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> Wizzup: your shure this dosent do anything whilest not recording?
<uvos> otherwise it would waste quite some power while just playing stuf i presume
pere has joined #maemo-leste
<Wizzup> uvos: will verify
<uvos> https://github.com/maemo-leste/bugtracker/issues/618 please also check this on a pp
<Wizzup> ok
<Wizzup> so there's recording/playback with echo cancel, pp testing for #618 and droid3 kernel with opp removed for today
<Wizzup> I also wanted to try out pipewire on my laptop, but that can maybe wait ;)
<Wizzup> btw the echo cancel works really well
<Wizzup> it makes an insane difference in sip calls
<Wizzup> (on speaker)
<uvos> ok
<uvos> but this is just echo canceling right. can pulse do fancy background noise cancelation like the d4 modem dose?
<Wizzup> yes, it can
<Wizzup> -but-
<Wizzup> it doesn't work well in my experience, and it has some show stopping bugs
<Wizzup> but other than that rnnoise works amazingly well
<Wizzup> I've clapped my hands, sat next to a road, etc, and none of it came through
<uvos> cool
<uvos> but thats not what the d4 dose
<Wizzup> I don't know what the d4 does then
<uvos> it uses a second mic and amps the difference between them
<uvos> and then subtracts that
<uvos> and one is closer to the speaker
<Wizzup> ah:
<Wizzup> PulseAudio comes with a module that can be used to perform acoustic echo cancellation of the microphone input, and some background noise reduction.
<Wizzup> I think it might do both then
<uvos> cool
<Wizzup> (instead of default sink)
<uvos> yeah
<uvos> depends on how it behaves i gues
<Wizzup> right
<Wizzup> >In the particular case of Pulseaudio the echo cancellaton includes noise filters. It would be better if they were separate, but it can still be an improvement in input quality nevertheless, even if the echo isn't a problem.
<Wizzup> ok, cool
<Wizzup> but I really loved the rnnoise for meetings fwiw
Pali has joined #maemo-leste
xmn has quit [Ping timeout: 245 seconds]
<Wizzup> uvos: btw we -could- try to make device-specific params for beamforming: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-echo-cancel
<Wizzup> (see mic_geometry, target_direction and aec_args)
<Wizzup> but I think we typically use just one mic
<Wizzup> uvos: looks like it doesn't idle well :(
<Wizzup> hm... or does it
<Wizzup> so just mpv with playback seems unaffected
vgratian has left #maemo-leste [#maemo-leste]
vgratian has joined #maemo-leste
<Wizzup> ok I did make a mistake in leste-config :)
<Wizzup> I forgot to run the magic script
<Wizzup> yeah ok so with the config I pushed it definitely doesn't always idle
<Wizzup> *sigh* :)
<Wizzup> uvos: yeah so I can confirm that just loading the module seems to cause it to do work, even though sink/source is not in use
<Wizzup> will have to rethink the approach. :)
<Wizzup> (afaik pipewire does not have this problem fwiw)
<lel> eloydegen opened an issue: https://github.com/maemo-leste/bugtracker/issues/624 (X terminal title does not revert back when disconnecting from ssh)
Daanct12 has quit [Remote host closed the connection]
Danct12 has quit [Ping timeout: 244 seconds]
<uvos> Wizzup: yeah thought so
<uvos> Wizzup: a envvar would be a good idea then
<Wizzup> will see what it does
<Wizzup> atm just having it loaded is a problem
<Wizzup> so let's see if it gets unloaded
<Wizzup> btw I think sphone still swaps the rtcom uids
<Wizzup> I'll add that to my list
<uvos> yes i dident change this
<lel> eloydegen closed an issue: https://github.com/maemo-leste/bugtracker/issues/624 (X Terminal window title does not revert back when disconnecting from ssh)
noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
vgratian has left #maemo-leste [#maemo-leste]
vgratian has joined #maemo-leste
Kabouik_ is now known as kabouik
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
<eloy> oh nice, there is a GitHub IRC bot :)
<eloy> some other issue I am experiencing on my Droid 4: random shutdowns during installations from the App Manager. I can't find any open bug for that, not sure if it's just me. It happened with QTWebBrowser and Surf. Surf was working after a second attempt, my Droid 4 shutdown again after trying to install QTWebBrowser a second time. It's probably not a rootfs size issue, I ran that /etc script before installing.
<eloy> maybe my microSD is borked, since the installation is quite heavy in I/O terms. But weird that dd'ing Leste itself seems to have worked fine then
<eloy> oh hey, it works now, on a third try! Pleasantly surprised how smooth QTWebBrowser is working :D
<uvos> is there white led light during this shutdown?
xmn has joined #maemo-leste
<eloy> uvos: hmm, not sure if there was. Wouldn't that have indicated a locked screen? Pressing the power button showed me the Motorola logo.
<eloy> uvos: okay, it happened again but using `apt install`. It showed a white led indeed for a few seconds. Then I could boot again.
<uvos> yeah thats dsme shuting down because of a temporarly non working deamon
<uvos> Wizzup: dident we disable this travesty>
<uvos> eloy: dose /etc/no_lg_reboots exist?
<eloy> lol I can't even finish booting because it shuts down before finishing boot :')
<uvos> either 1 during the upgrade you broke a deamon
<eloy> I saw some issue about libthermalobject.so not being found
<uvos> so now dsme is in a bootloop
<eloy> fun stuff :D
<eloy> time to dd again
<uvos> no
<eloy> oh
<uvos> you can insert the sdcard into a pc
<uvos> and create the /etc/no_lg_reboots file
<eloy> ah, I'll do that
<eloy> thanks
<eloy> uvos: should it exists as a regular file? it currently is a symlink to /etc/no_lg_reboots.leste
<eloy> well, I made it a regular file anyway, and now it works. thanks!
Livio has joined #maemo-leste
<uvos> aha
<uvos> Wizzup: ^^^
<uvos> eloy: you need to finish the apt dist-upgrade now
<eloy> uvos: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded :)
rafael2k has joined #maemo-leste
<Wizzup> uvos: hmmm I thought we did add it to leste-config
<Wizzup> let me see
<uvos> Wizzup: we did
<uvos> but apearntly dsme checks for a regular file
<uvos> and its a link
<Wizzup> ah...
<Wizzup> that's a problem in leste-config, we can't do that another way
<Wizzup> maybe we need to fix that in dsme then
<uvos> i mean its a zero byte file
<uvos> you could just touch in postinst
<uvos> but yeah fixin dsme is better
rafael2k has quit [Ping timeout: 245 seconds]
<Wizzup> uvos: true, but then removing it gets more tricky
rafael2k has joined #maemo-leste
rafael2k has quit [Client Quit]
<Wizzup> so the check in dsme is:
<Wizzup> if (access(FILE_REBOOT_OVERRIDE, F_OK) != 0) {
<Wizzup> uvos: hmm shouldn't that just work with symlinks?
<Wizzup> eloy: can you confirm that it really doesn't work as a symlink?
<Wizzup> # /tmp/test
<Wizzup> ret=0
<Wizzup> (my test program doing the same as dsme)
<Wizzup> so I think ew're looking at something else
<eloy> hmm I don't have a way to test that will reliable shutdown the phone
<eloy> might be something else
<Wizzup> well, was it fixed when you removed the symlink and touched the file?
Livio has quit [Ping timeout: 240 seconds]
hexagonwin has joined #maemo-leste
<uvos> Wizzup: hmm so i figured out why its not propagating
<uvos> Wizzup: so the "DAC Voice" widget outputs to Voice PGA
<uvos> but the Voice PGA dosent have DAC Voice as an input
<uvos> that... should not be possible at all
<Wizzup> huh, that's weird
<Wizzup> that's a problem regardless I think
<Wizzup> uvos: I guess that's in the intercon[] static var yeah?}
<uvos> yeah
<Wizzup> I mean that might also be a problem regardless of our 'hack'
<Wizzup> so it's [output, switch, input] ?
<uvos> yeah
<uvos> but that would not help anyhow
<uvos> i put printfs in the printing function
<uvos> and it never even checks if the voice call path is active
<uvos> so i dont understand how this is even supposed to work at all
<uvos> *i put printfs in the path checking function
<Wizzup> hm...
<uvos> i mean this works
<uvos> (just made a call, output works fine, not sure about mic in)
<uvos> but yeah
<uvos> asoc needs more investigation
<uvos> best case we get someone who knows how this is supposed to work
<uvos> to talk to us
<Wizzup> is sre still around?
<uvos> i send him an email about it
<uvos> he dident awnser
<uvos> but he dose have some activity on the malining list
<uvos> *mailing list
<uvos> Wizzup: anyhow so what was needed to make mic input also work?
<uvos> register wise
<Wizzup> uvos: I think it was what I pushed to leste-config, just enabling certain things
<Wizzup> not registers themselves, but if that's not it, I have to see what it was
<uvos> ok
<Wizzup> I made a tool to compare the register states with human readable output
<uvos> could you maybe build the current kernel
<Wizzup> so it should be pretty simple to compare with what I have in my sphone branch
<uvos> and diff the regs for mic input?
<uvos> the output works ok now
<uvos> OXRA or what the register was called
<Wizzup> currente kernel, do you mean with the commit you linked?
<uvos> yes i pushed that to the maemo tree
<Wizzup> ok, so make a new -devel one then
<Wizzup> I will do that
<uvos> no wait
<uvos> sec
<Wizzup> (I was also building a kernel for the droid3 on my laptop with the opp disabled)
<uvos> Wizzup: should be ok
<uvos> so all i need to do is kick it via lel?
<uvos> or do i need to change the changelog?
<uvos> this is a bit akward since the changelog lives in a different branch
<Wizzup> we need a tag, changelog, etc
<uvos> ok
<uvos> tag where
<uvos> the source branch
<uvos> or the packaging branch
<Wizzup> the tag should be on the src
<Wizzup> the changelog should be in maemo/beowulf-devel
<Wizzup> (with the right tag as version of course)
<Wizzup> uvos: lmk if you want me to do it
<uvos> Wizzup: no go away xD
<Wizzup> :D
<uvos> ill do it :)
<uvos> Wizzup: [21:52] <lel> Unauthorized
<uvos> i gues not
<uvos> :P
<Wizzup> we should probably change/fix the bot
<Wizzup> it's very labour intensive currently to add folks
<Wizzup> so I'll wait for this to build, upgrade and then check sphone on my d4 again
<uvos> check
<uvos> ill try 5.18.14 in the mean time
<Wizzup> is that just a newer stable release?
<uvos> yeah
<uvos> no reason not to update while at it
<Wizzup> yes
<Wizzup> will upgrade now
<Wizzup> hm, the upgrade seems stuck in i/o or something
<Wizzup> ah continud now
<uvos> 5.18.14 also works fine btw
<Wizzup> ok
<Wizzup> rip 10 days uptime ;)
<Wizzup> hm wifi just connected on first try after boot
<Wizzup> probably unrelated :)
<uvos> Wizzup: ok
<uvos> i just updated it for 5.18.14
<uvos> so you can kick it again if you want
<Wizzup> ok, I think indeed that the mic doesn't work yet, let me debug now (restarting device to make sure)
<Wizzup> uvos: hm I am not sure if I can still write registers
<Wizzup> did you remove that commit?
<uvos> no
<uvos> but that commit never made it to the devel
<uvos> its in expieramental
<uvos> so no its not there
<Wizzup> ok
<Wizzup> well I think it maybe just works?
<Wizzup> you sure you don't have mic?
<Wizzup> it's a bit hard for me to test with two phones next to each other (it starts ringing quickly)
<Wizzup> but I have muted my fremantle and I can hear my d4 mic
<uvos> um ok maybe it just works yeah
<uvos> is the register state ok?
<Wizzup> so I definitely made some changes to the UCM
<Wizzup> did you get those?
<Wizzup> ok there's definitely still some stuff to work out
<Wizzup> but speakerphone call should work
<Wizzup> switching to earpiece in pulse didn't work for me
<Wizzup> and I need the reg writing to test what it is :)
<uvos> huh
<uvos> why would you need write access to read the state
<Wizzup> left: current in call after selecting, right: my known good preset
<Wizzup> (I also don't hear anything in the earpiece)
<Wizzup> I think I am selecting the right things in alsamixer but without a kernel reg actually being on they might not do the right thing
<Wizzup> uvos: yeah so the reg access just makes it easy to see what in particular I need
<uvos> ok sec let me upgrade
<uvos> if you want write access please rebase the expiramental kernel
<uvos> anyhow it just worked (output) so im not sure whats going on
<Wizzup> do you mean speakerphone?
<uvos> no handset
<Wizzup> I see
<Wizzup> how about mic?
<uvos> dunno
<uvos> im calling a service that tells you the time
<Wizzup> so what I do: I have my fremantle n900 with a headset, and I call up my d4
<Wizzup> and then after a short time I mute the n900
<Wizzup> (otherwise it starts ringing)
<Wizzup> (ofc I unmute the n900 to test earpiece)
<Wizzup> this is a semi easy way to test calls in any case imh
<uvos> i call +4940428990
<uvos> still works
<Wizzup> just saying, in case you wanted to test another way
<Wizzup> sphone still prefers speakerphone, yeah?
<uvos> sphone just switches the profile
<uvos> pulse just sets something by default
<uvos> (last used maybe?)
<uvos> anyhow switching after in pavucontroll-qt works fine here
<Wizzup> I am in a call now, trying it
<Wizzup> I just get nothing
<Wizzup> internal speaker works
<Wizzup> internal earpiece is neither input nor output
<Wizzup> where do you select this, just to be clear?
<Wizzup> my X segfaulted
<Wizzup> or maybe the screen hangs
<Wizzup> argh
<Wizzup> oh yea it's stuck in this sigalrm business
* Wizzup restarts
<uvos> ok so i boot the phone
<uvos> start ofono, online the modem enter the pin
<uvos> start sphone and pavucontrol-qt
<uvos> call +4940428990, wati untill it starts speaking via the speakerphone
<uvos> switch to internal earpiece port in the output devices tab
<Wizzup> yeah ok so apart from the number we're doing the same thing
<uvos> oh wait
<uvos> i bootet the wrong kernel
<uvos> ahh uvos: I think it is missng maemo-kernel-5.18.14
<uvos> i tagget it 5.18.14-1
<uvos> its building the wrong commit
<Wizzup> shall I stop the one on jenkins?
<uvos> yes
<Wizzup> it never built fwiw
<uvos> so wait
<Wizzup> see ##leste-ci
<uvos> how dose the tag relate to the version
<uvos> ie how am i supposed to know what to tag it with
<Wizzup> the tag has to correspond to the changelog entry
<Wizzup> so whatever you put in the changelog has to be in the tag
<uvos> yeah but thats omap-linux (5.18.14-1) unstable; urgency=medium
<uvos> same for the older versions
<Wizzup> I see your question
<uvos> omap-linux (5.18.9-3) unstable; urgency=medium
<Wizzup> see debian/gbp.conf in maemo/beowulf-devel
<Wizzup> it is maemo-kernel-(...)
<uvos> okay
<Wizzup> because it otherwise gets confusing with actual linux tags
<Wizzup> but for the other kernel, that I am testing, you made the correct tag, right?
<uvos> but maemo-kernel-5.18.9-3 dosent exist
<uvos> Wizzup: no
<uvos> its wrong it dosent have the commit
<uvos> its maemo-kernel-5.18.9
<uvos> so im not sure how the different -x versions are supposed to work
<Wizzup> ah, ok
<Wizzup> uvos: yes, that's why I just increase the version or add .1 or something
<uvos> * [new tag] maemo-kernel-5.18.14 -> maemo-kernel-5.18.14
<uvos> anyhow that should be ok
<Wizzup> so do we just try 5.18.14 then, with the commit in?
<uvos> i hope
<uvos> yes
<uvos> thats what i was useing
<uvos> (localy built)
<Wizzup> ok, so that might explain it then :)
<Wizzup> started the build
<Wizzup> btw, not sure what makes more sense, but when moving to a new testing release, shouldn't we rebase on top of it instead of merging it in?
<Wizzup> I guess it doesn't matter much, but it's just easier to see our commits that way
<uvos> eh
<uvos> i rebase on major versions
<uvos> or remerge rather
<Wizzup> ok
<Wizzup> just checking
<uvos> building the source package is hella slow
<Wizzup> it has to fetch it
<Wizzup> if we host our own git on the same machine it'd be faster
<Wizzup> but I am not sure if I want all of that at my home :)
<uvos> no more need for gas heating in winter
<Wizzup> I'm not usually home anyway so no heating required :P
vagag has left #maemo-leste [Error from remote client]
<Wizzup> the droid3 just reset on my, with I think a kernel with the opp patch applied
<Wizzup> -- OMAP 00004430 (version 00000b22) PPA release1.3.5 R2
<Wizzup> Reset reason = 000379a2
<Wizzup> Model ID is 0x00000003
<Wizzup> I think that's just part of the boot procedure, mostly, right?
<uvos> thats mbm yeah
<Wizzup> in any case not sure if the opp patch really helps
<uvos> 000379a2 is wdr i think
<Wizzup> I recall that you said that before, but IDK where the values come from :)
<uvos> i dont either, but you can see a pattern in those after a while
<uvos> but i think its just dumping the omap register
<uvos> so you could look in trm
<Wizzup> right
<Wizzup> root@devuan-droid3:/sys/bus/cpu/devices/cpu0# cat cpufreq/scaling_available_frequencies
<Wizzup> 300000 600000 800000 1008000
<Wizzup> yeah so the patch worked I'd say, but it doesn't have the intended effect
<uvos> yeah its clearly something else
<uvos> maybe check emif registers
<uvos> ie diff them between android and us
<Wizzup> compare with android? or?
<Wizzup> ok
<Wizzup> I think that's something I'll try to do another day (maybe tomorrow)
<Wizzup> btw your patch:
<Wizzup> I think you want to disable Speaker Right PGA
<uvos> oh yeah
<uvos> ok ill fix that tomorrow
<Wizzup> sure, I'm just waiting for the kernel build to finish to I can test earpiece :)
<Wizzup> checking if this phone still has android
<Wizzup> kernel is almost done
elastic_dog has quit [Ping timeout: 244 seconds]
elastic_dog has joined #maemo-leste
<Wizzup> uvos: hm, I don't think I get any audio now
<Wizzup> wait I can hear over earpiece
<Wizzup> but indeed the mic does not work
<Wizzup> hmm...
uvos has quit [Ping timeout: 245 seconds]
<Wizzup> yeah, to be continued