Wizzup | arno11: what about the 2s sleep added in d3c9fa56647447adbf0ebf834ec748829804a5e1 - can that go now? | 01:48 |
---|---|---|
Wizzup | also I imagine the 2048 read instead of 160 will also make the cpu usage less | 01:49 |
Wizzup | building for -devel now | 01:50 |
arno11 | Wizzup: that's what i was thinking but cpu usage is still high. | 07:54 |
arno11 | for 2s sleep i don't know, i need to test, specially without overclock | 07:56 |
freemangordon | arno11: BTW, did you find where those values come from? | 07:56 |
freemangordon | q60 that is | 07:56 |
freemangordon | *160 | 07:56 |
arno11 | it has been modified by pavel in 2017. 1024 to 128 then 160 to improve things with alsa. but because outgoing sound was not working it was impossible to see/ear the consequences with PA | 08:02 |
freemangordon | so initially it was 1024? | 08:02 |
arno11 | yes from the beginning | 08:03 |
freemangordon | but then why do you increase it to 2048? | 08:03 |
freemangordon | I guess 1024 is what nokia put there, no? | 08:03 |
arno11 | because at 1024 there is still 3-4 sec latency at the beginning of calls | 08:04 |
arno11 | yes for nokia | 08:04 |
arno11 | but nokia was using dsp | 08:05 |
freemangordon | dsp? | 08:05 |
freemangordon | no | 08:05 |
freemangordon | what dsp | 08:05 |
arno11 | the dsp chip | 08:05 |
freemangordon | I know what dsp is, my question is - why do you think DSP is used for calls | 08:06 |
arno11 | because there is specific code in cmtspeech to use dsp | 08:06 |
freemangordon | could you point me to it? | 08:07 |
arno11 | yes let me few minutes i have a baby in the hands... | 08:07 |
freemangordon | oh :) | 08:07 |
arno11 | :) | 08:08 |
freemangordon | hmm, where is NEON optimized code? | 08:12 |
freemangordon | wtf? | 08:12 |
arno11 | libcmtspeechdata/utils/dsp.c (the code points to dev/dsp) | 08:12 |
arno11 | for neon good question | 08:12 |
arno11 | i forgot to ask | 08:13 |
freemangordon | arno11: this code is not for n900/fremantle | 08:14 |
freemangordon | there is no /dev/dsp in fremantle kernel | 08:14 |
arno11 | ? really | 08:15 |
arno11 | i didn't know that | 08:15 |
freemangordon | yes, there is no | 08:15 |
freemangordon | it is NEON code that is used to resmaple on fremantle | 08:15 |
freemangordon | I REed the library back then | 08:16 |
freemangordon | sec | 08:16 |
freemangordon | arno11: see what we have https://notabug.org/freemangordon/pulseaudio-nokia/src/fremantle/src | 08:17 |
freemangordon | I can't remember where resamplers are | 08:19 |
freemangordon | see https://notabug.org/freemangordon/pulseaudio-nokia/src/fremantle/src/voice/voice-convert.h | 08:19 |
freemangordon | the fuck? I didn't push the optimized code | 08:22 |
freemangordon | oh, wrong repo | 08:23 |
freemangordon | this https://github.com/community-ssu/pulseaudio-nokia | 08:23 |
freemangordon | arno11: look at https://github.com/community-ssu/pulseaudio-nokia/tree/master/src/common | 08:23 |
freemangordon | src-XXX files | 08:23 |
freemangordon | so, I would say high CPU usage is caused by unoptimized resampling code | 08:25 |
freemangordon | Wizzup: ^^^ | 08:25 |
freemangordon | so, I have no idea where Pavel found the code he is using | 08:27 |
arno11 | (sorry network issue) | 08:29 |
freemangordon | right | 08:29 |
freemangordon | see the log if you missed my last ~10 lines | 08:29 |
arno11 | yes, actually reading | 08:30 |
arno11 | now we know why cpu usage is high. nice | 08:31 |
freemangordon | do you know who does the resampling? | 08:31 |
arno11 | not sure now lol | 08:34 |
freemangordon | because on fremantle (and meego) it is done by PA speech module | 08:34 |
freemangordon | s/speech/voice/ | 08:35 |
freemangordon | BTW, we have *everything* from fremantle REed (including xprot), but voice BLOB | 08:36 |
arno11 | on leste seems everything is done by PA itself, with many generic modules involved | 08:39 |
freemangordon | arno11: so, if we find where resampling is done, I can easily RE the neon code that's used on fremantle | 08:39 |
arno11 | nice :) | 08:40 |
freemangordon | still, we have C code to test with | 08:40 |
arno11 | ok | 08:40 |
freemangordon | this https://github.com/community-ssu/pulseaudio-nokia/blob/master/src/common/src-48-to-8.c and https://github.com/community-ssu/pulseaudio-nokia/blob/master/src/common/src-8-to-48.c | 08:41 |
freemangordon | TBH, I think NEON optimized code was made by armcc | 08:41 |
freemangordon | so maybe recent gcc is good enough to do the same | 08:42 |
freemangordon | arno11: so does 8000 Hz ring a bell? | 08:43 |
freemangordon | see https://github.com/community-ssu/pulseaudio-nokia/blob/master/src/voice/voice-hw-source-output.c#L458 | 08:45 |
arno11 | (sorry, baby again) let me few min to have a look | 08:45 |
freemangordon | sure | 08:45 |
arno11 | freemangordon: arghh sorry i have to go but now i understand how nokia did the trick to avoid high cpu usage :) thx | 09:16 |
arno11 | back in few hours | 09:16 |
uvos | freemangordon: adding a contact in abook with abook in portrait hangs abook | 11:24 |
maxwelld | uvos, how would you suggest me to trace the osso-xtrem problem? | 12:36 |
maxwelld | i did strace, and i got the same floating point exception | 12:36 |
Wizzup | gdb | 12:38 |
maxwelld | ok, so far strace log: https://bpa.st/TDZDG | 12:40 |
maxwelld | let me remember how to do a gdb backtrace | 12:40 |
maxwelld | hmmm i think i have no gdb, and it cannot find gdb in the repos... | 12:41 |
Wizzup | https://leste.maemo.org/Debugging | 12:41 |
Wizzup | https://leste.maemo.org/Debugging#Dealing_with_Maemo_Launcher_.2F_Maemo_Invoker | 12:41 |
maxwelld | ty | 12:42 |
* maxwelld is doing apt-get update, hopefully after that gdb will be found | 12:43 | |
maxwelld | and i'll do gdb /usr/bin/osso-xterm, and then bt i guess. | 12:43 |
Wizzup | but that is not what is on the wiki | 12:44 |
Wizzup | why not do what is on the wiki | 12:44 |
maxwelld | ok (: | 12:44 |
uvos | freemangordon: Wizzup: ok so the problem with osso-addressbook's recent not working with sphones events is not sphones fault | 12:47 |
uvos | this is the fuction that fails | 12:49 |
uvos | https://github.com/maemo-leste/osso-addressbook/blob/71d03ad2e7ece8f073299e668145b1bd35fec6c5/src/osso-abook-recent-view.c#L227 | 12:49 |
uvos | https://github.com/maemo-leste/osso-addressbook/blob/71d03ad2e7ece8f073299e668145b1bd35fec6c5/src/osso-abook-recent-view.c#L262 <-- this fails as it assumes that the protocoll is known by tp but sphone/ofono/sphone is not tp ofc | 12:50 |
uvos | thats ok and expected | 12:50 |
uvos | but then teh fallback there https://github.com/maemo-leste/osso-addressbook/blob/71d03ad2e7ece8f073299e668145b1bd35fec6c5/src/osso-abook-recent-view.c#L274 | 12:50 |
uvos | assumes that remote_account_name is a uri, but its not, its a phone nummber | 12:51 |
uvos | this is correct and is the same as wizzups fremantle database | 12:51 |
uvos | so then the function bails | 12:51 |
maxwelld | in gdb: Program received signal SIGFPE, Arithmetic exception. | 12:51 |
uvos | maxwelld: bt? | 12:52 |
uvos | freemangordon: Wizzup: instead this function should check event_type_id and if thats a phone call it should know that remote is a phone number and act accordingly | 12:52 |
uvos | uris are only used for ip accounts in rtcom-el | 12:52 |
maxwelld | it says it doesn't have stack 😕 | 12:52 |
maxwelld | doing dist-upgrade in the hope it'll solve something. | 12:53 |
uvos | smells memory corruption | 12:54 |
uvos | try valgrind | 12:54 |
uvos | maxwelld: what are you doing exactly to make it crash anyhow? | 12:58 |
uvos | what device architecture are you using | 12:58 |
freemangordon | uvos: no, it should be URI | 13:07 |
freemangordon | either tel:// or phone:// or whatever | 13:07 |
freemangordon | https://github.com/maemo-leste/osso-addressbook/blob/master/src/app.c#L1478 | 13:08 |
Wizzup | maxwelld: you need to intsall debug pkgs do get the backtrace | 13:09 |
freemangordon | the fix is simple - when code pushes into db, it should prefix with tel:// | 13:09 |
uvos | freemangordon: thats not what fremantle dose | 13:10 |
freemangordon | sure it does | 13:10 |
freemangordon | otherwise it will not work for unknown numbers | 13:10 |
uvos | Wizzup's fremantle db is exactly like sphones | 13:10 |
freemangordon | so? | 13:11 |
uvos | it works because the account is a telepathy one | 13:11 |
freemangordon | right | 13:11 |
uvos | so the fallback path is not taken | 13:11 |
freemangordon | right | 13:11 |
uvos | the fallback path is simply wrong | 13:11 |
maxwelld | oh, so i cannot do dist-upgrade: | 13:11 |
maxwelld | E: This installation run will require temporarily removing the essential package hildon-base:armhf due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option. | 13:11 |
maxwelld | E: Reverse conflicts early remove for package 'elogind:armhf' failed | 13:11 |
Wizzup | uvos: there is a small chance that the obfuscation breaks something but inlikely | 13:11 |
uvos | freemangordon: it must check event_type_id to know what the remote name is supposed to be | 13:11 |
freemangordon | uvos: fallback path is correct, it is how it is done in fremantle. most-probably db you are using has no received calls from unknown numbers | 13:12 |
freemangordon | ttyl | 13:13 |
uvos | the fallback path is _never_ used on fremantle | 13:13 |
uvos | so its not how its done there | 13:13 |
freemangordon | it *is*, when you have call from unknow numbe and do "add to contacts" | 13:14 |
uvos | no | 13:14 |
uvos | becuse even then the account will be ring/tel/ring | 13:14 |
uvos | so the path above is taken | 13:14 |
freemangordon | this is *local* account | 13:14 |
freemangordon | not remote | 13:14 |
uvos | yes and the local account is checked | 13:14 |
uvos | account = osso_abook_account_manager_lookup_by_name(NULL, local_account_name); | 13:15 |
uvos | thisi s where it diverges | 13:15 |
freemangordon | hmm | 13:15 |
freemangordon | so, once we have tp plugin for sphone (which we must have anyways), this will start working | 13:15 |
uvos | the fallback path is sill broken | 13:15 |
uvos | and we will keep the ofono plugin then still | 13:16 |
freemangordon | where is that event_type_id? | 13:16 |
Wizzup | freemangordon: it's actually working, it just needs one silly fix for anon call id for outgoing calls being the default | 13:16 |
uvos | in the db | 13:16 |
uvos | it tells you its a phone call | 13:16 |
uvos | or a sms | 13:16 |
uvos | or a ip call | 13:16 |
uvos | etc | 13:16 |
uvos | sms and phone call are a specal case | 13:16 |
freemangordon | does abook have that info? | 13:16 |
uvos | where remote is not a url | 13:17 |
freemangordon | ah, event_type_id | 13:17 |
freemangordon | event_id | 13:17 |
uvos | no | 13:17 |
uvos | thats the id of the event | 13:17 |
uvos | event_type_id is a different field | 13:17 |
freemangordon | this https://github.com/maemo-leste/osso-addressbook/blob/71d03ad2e7ece8f073299e668145b1bd35fec6c5/src/osso-abook-recent-view.c#L253 | 13:18 |
freemangordon | ah | 13:18 |
freemangordon | ok, will look at this later | 13:18 |
freemangordon | bbl | 13:18 |
arno11 | (Wizzup: i doublechecked 2s sleep and we need to keep it, otherwise incoming sound is a bit distorted) | 13:21 |
Wizzup | ok | 13:24 |
maxwelld | got backtrace from osso-xterm: https://bpa.st/QDKUI | 13:24 |
Wizzup | you need more dbgsym packages | 13:24 |
maxwelld | but osso-xterm doesnt depend on anything | 13:24 |
maxwelld | except libc and | 13:24 |
Wizzup | It most definitely needs glib and all of those debug packages | 13:25 |
Wizzup | you're probably running ldd on the maemo launcher binary or something | 13:25 |
Wizzup | and not on oss-xterm.launch | 13:25 |
Wizzup | osso-xterm.launch | 13:25 |
maxwelld | omg osso-xterm.launch uses lots of libs | 13:26 |
Wizzup | you just want the glib dbgsym for now | 13:28 |
Wizzup | that's most important | 13:28 |
maxwelld | ok so installed some glibc dbgs but i have same bt. | 13:38 |
maxwelld | Backtrace stopped: previous frame identical to this frame (corrupt stack?) | 13:38 |
Wizzup | *glib* | 13:38 |
Wizzup | not glibc | 13:38 |
maxwelld | i wrote a script that would install all the dbg packages of all deps, should i do it? | 13:39 |
maxwelld | yes glib | 13:39 |
maxwelld | sorry | 13:39 |
Wizzup | how do you run gdb? | 13:39 |
maxwelld | because i was saying glibc in other chat. but i installed glib. | 13:39 |
maxwelld | glib's dbg packages. | 13:39 |
maxwelld | several of them. | 13:39 |
Wizzup | which ones? | 13:39 |
Wizzup | please be explicit | 13:39 |
maxwelld | minute | 13:40 |
maxwelld | i did | 13:40 |
maxwelld | apt-get install libglib2.0-0-dbgsym libglib2.0-bin-dbgsym libglib2.0-dev-bin-dbgsym libglib2.0-tests-dbgsym libpackagekit-glib2-18-dbgsym | 13:40 |
maxwelld | when i am trying to run with gdb osso-xterm, it tells about corrupted stack | 13:40 |
maxwelld | when osso-xterm.launcher | 13:41 |
maxwelld | https://bpa.st/NTXE6 | 13:41 |
uvos | maxwelld: your backtrace is not usefull because you dident do what the wiki sais and used maemo-invoker with gdb | 14:21 |
uvos | also the fact that launching the .launch directly worked for you suggests your stillon beowulf, which makes your issue non-interesting to us because we no longer support or work on bewulf and have all moved on to chimaera | 14:22 |
Wizzup | maxwelld: are you on beowulf? | 14:33 |
arno11 | Wizzup: freemangordon: so cmtspeech in leste works really differently than cmtspeech + pulseaudio-nokia in fremantle | 14:49 |
arno11 | there is no resample code in cmtspeech (leste) and PA seems to do everything itself | 14:52 |
maxwelld | > also the fact that launching the .launch directly worked for you suggests your stillon beowulf, which makes your issue non-interesting to us because we no longer support or work on bewulf and have all moved on to chimaera | 14:52 |
maxwelld | i understand that wizzup suggested to run that. my trace without .launch i also shared. | 14:52 |
maxwelld | it says that the stack frame repeats and maybe stack is corrupted. | 14:52 |
maxwelld | that's why it stops showing the stack. | 14:52 |
arno11 | (for low cpu usage) the trick in fremantle is to record at 48khz and downsampling to 8 to be able to communicate to the modem | 14:55 |
arno11 | it's not possible in leste without a specific module like pulseaudio-nokia | 14:57 |
Wizzup | let's stick with what we have working now wrt calls and then revisit the specific modules later | 14:58 |
arno11 | agreed | 14:58 |
arno11 | it was to answer fmg questions | 14:58 |
arno11 | and let you know | 14:59 |
arno11 | Wizzup: btw do you know who is generating tone and ringtone ? | 15:17 |
uvos | maxwelld: your missing maemo-invoker | 15:21 |
uvos | you need to use "gdb --args maemo-sumener /usr/bin/osso-xterm.launch" | 15:21 |
uvos | exactly that | 15:21 |
uvos | but if your on beowulf - dont bother | 15:21 |
uvos | upgrade to chimaera | 15:21 |
uvos | check cat /etc/os-release to see if its chimaera of beowulf | 15:22 |
uvos | s/of/or | 15:22 |
Wizzup | arno11: don't really know | 15:24 |
Wizzup | uvos: I think he's also not up to date with apt regardless | 15:24 |
Wizzup | iirc from what I saw earlier | 15:24 |
norayr | uvos, Wizzup, os-release says chimaera. i think it might be even not updated to chimaera system, but freshly installed back then. | 17:35 |
norayr | but i guess with this flag gdb is even less useful: https://bpa.st/LJH4E | 17:36 |
norayr | or i am doing something wrong. | 17:36 |
norayr | i do apt-get update regulargly, but apt-get dist-upgrade yes, indeed, doesn't work well because of udev issues, as i remember. forgot already, though looked today. | 17:37 |
uvos | its "maemo-summoner" i misstyped | 17:44 |
uvos | what do you mean "doesn't work well because of udev issues" | 17:44 |
uvos | its probubly pointless to chase xterm not working if your system is broken/ half updated | 17:45 |
Wizzup | pretty sure the dist-upgrade would just get him going | 18:05 |
maxwelld | oh let me try | 18:22 |
maxwelld | but dist-upgrade has a package conflict. can you help to solve it? | 18:22 |
Wizzup | yes, just check the news post | 18:25 |
Wizzup | https://maemo-leste.github.io/maemo-leste-five-year-anniversary-and-chimaera-release.html#upgrading | 18:25 |
norayr | here with maemo-summoner: https://bpa.st/53TFW | 18:31 |
Wizzup | norayr: please dist upgrade firstr | 18:38 |
Wizzup | otherwise we will have no way to reproduce, if the problem persists anyway | 18:39 |
norayr | what can i do https://bpa.st/RDKJ2 ? | 18:43 |
uvos | Wizzup allready told you, do what he linked above | 18:43 |
norayr | oh... wait, maybe i disconnected and i dont have the logs? | 18:56 |
norayr | dist-upgrade doesn't work for me. if that's his recommendation | 18:56 |
norayr | then it doesn't work, and the output is linked https://bpa.st/RDKJ2 | 18:56 |
norayr | but otherwise i searched all the history, i didn't get any recommendation with apt. | 18:57 |
Wizzup | 18:39 < Wizzup> norayr: please dist upgrade firstr | 18:59 |
Wizzup | 18:39 < Wizzup> otherwise we will have no way to reproduce, if the problem persists anyway | 18:59 |
Wizzup | 18:25 < Wizzup> yes, just check the news post | 18:59 |
Wizzup | 18:26 < Wizzup> https://maemo-leste.github.io/maemo-leste-five-year-anniversary-and-chimaera-release.html#upgrading | 18:59 |
norayr | Wizzup: but... i showed you the problem... i cannot dist-upgrade | 19:10 |
norayr | and i am on chimaera | 19:10 |
norayr | but let me try the link | 19:10 |
norayr | are these firmware related warnings ok? | 19:46 |
norayr | https://bpa.st/JDCHO | 19:46 |
norayr | anyway, i restarted, did update according to wiki | 19:46 |
norayr | osso-xterm fails. | 19:46 |
norayr | i'll reinstall the system... will try to preserve the home... | 19:46 |
norayr | i guess my sdcard is the reason :/ | 19:47 |
Wizzup | bad sdcard again? | 21:01 |
Wizzup | 19:47 < norayr> anyway, i restarted, did update according to wiki | 21:01 |
Wizzup | do you mean according to the news post? | 21:01 |
Wizzup | but yeah, FPE errors I can see happen when the sd card is corrupt | 21:01 |
arno11 | sicelo: any idea about what is managing/generating tone and ringtone during calls ? seems to be not cmtspeech directly, maybe ofono or sphone, or ? (i need to fix a bug) | 21:40 |
sicelo | fmg might know better, but i think there's package `tonegend` or similar somewhere | 21:46 |
sicelo | oh but ringtone is controlled by profile, no? | 21:47 |
arno11 | yes but i need to understand how it is played and through which service | 21:49 |
Wizzup | I think ringtone before a call is not the same as tones during a call | 21:49 |
Wizzup | one is just HiFi playing some audio file | 21:49 |
Wizzup | the other one is more complicated, and I think arno11 is asking about that | 21:49 |
Wizzup | (am I wrong?) | 21:50 |
arno11 | you're right :) | 21:50 |
sicelo | yes the other tones are handled by `tonegend` iirc. fmg will have better details though :-) | 21:53 |
arno11 | ok thx | 21:55 |
maxwelld | yes | 22:32 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!