<Wizzup>
uvos: fmg isn't around atm, do you know what component he changed to support more of the xdg spec for notifications?
lyubov has left #maemo-leste [WeeChat 3.0]
akossh has quit [Quit: Leaving.]
pere has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
xmn has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 244 seconds]
macros_ has joined #maemo-leste
ceene has joined #maemo-leste
fab has joined #maemo-leste
xmn has quit [Ping timeout: 246 seconds]
fab has quit [Quit: fab]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
fab has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: hildon-home
<uvos__>
flashing the xt910 modem fw to xt912 wont do anything, (if it isent rejected on signing key grounds) as the pcb if physicaly different
akossh has joined #maemo-leste
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #maemo-leste
pere has quit [Ping timeout: 245 seconds]
RedW has quit [Quit: huh upgrades]
RedW has joined #maemo-leste
pere has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 244 seconds]
rafael2k_ has joined #maemo-leste
l_bratch has joined #maemo-leste
l_bratch has quit [Read error: Connection reset by peer]
* maxwelld
wonders where usov knows so many details about phones and phone hardware.
<maxwelld>
uvos*
<maxwelld>
where from*
<dsc_>
hi
<dsc_>
is it possible to hook incoming calls
<dsc_>
example: incoming call triggers some arbitrary script
<dsc_>
because there are databases on the internet that contain phone numbers that are known to be spammers (robo calls)
<dsc_>
so maybe its possible to verify incoming phone numbers this way by doing some REST call and then `kill -9` the call process (or however calling works)
<uvos__>
since the process that handles the call is running on the modem
<uvos__>
not on the main cpu
<uvos__>
you must use the ofono dbus interface to hangup the call
<dsc_>
cool :)
<arno11>
really cool
rafael2k_ has quit [Quit: Leaving]
<arno11>
Wizzup: sicelo: after triple-checking, SIP calls and messages are working at 100% on N900 through Twinkle, no more troubles with inbound sound, following the process from yesterday night (GMT lol)
<arno11>
On the other side the CPU usage is still very high because of PA threads.
<arno11>
One more thing, PA autospawn must be activated.
<arno11>
But that's already activated per default anyway
ceene has quit [Read error: Connection reset by peer]
_CN_ has joined #maemo-leste
fab has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
<arno11>
(note: now i have SIP calls working at 100% in my old install as well, re-activating autospawn and PA realtime stuff...)
arno11 has left #maemo-leste [#maemo-leste]
xmn has joined #maemo-leste
<sicelo>
at 100% means ... 100% cpu usage?
arno11 has joined #maemo-leste
<arno11>
sicelo: i mean 100 % working :)
<bencoh>
so no more sound hiccups? what did you have to change?
<arno11>
bencoh: on N900 from a fresh install and devel dist-upgrade: alternate sample rate to 4000, resampling method to 'trivial'
<bencoh>
4khz? uh ...
<arno11>
yes
<bencoh>
that's kinda ... on the low side
<arno11>
yes
<arno11>
tbh, even at 4khz the sound is not bad
<arno11>
and that's only the number of samples per sec
<bencoh>
well, it also cuts frequencies higher than ~2khz
_CN_ has quit [Ping timeout: 240 seconds]
<arno11>
not sure because of resampling
<arno11>
and that's probably why PA cpu usage is so high
<Wizzup>
arno11: why does pa autospawn need to be activated?
<arno11>
Wizzup: apparently because it avoids 'disk sleep' state for PA sink thread
<Wizzup>
but pa autospawn only means it will start another PA next to the one we already have
<Wizzup>
I don't think it means anything else, right?
<Wizzup>
sorry, it's ~7am here so still waking up
<arno11>
ok lol so good morning.
<Wizzup>
sicelo: btw I pushed the news post draft online to github in case you want to looksie
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
in any case I will retrace the same steps today at work, see if I get calls with audio working, in ~2-3 hours
<Wizzup>
if I have working audio in SIP then I can also toy with the settings
<Wizzup>
see if there's some performance to be gained and such
<arno11>
Wizzup: for autospawn: imagine pa sink thread is bugging and not working, it cannot restart with no autospawn i think
<Wizzup>
so, I might be wrong, but I think autospawn just means that if PA isn't running yet for the given user, it will be started
<arno11>
ok for retracing steps
<Wizzup>
so the only effect of autospawn will be that it starts another PA daemon as your user
<Wizzup>
rather than use the running system one (which is pulse user)
<Wizzup>
and it might very well have different settings
<arno11>
ok to be 100% sure i'll deactivate autospawn again to see what happens
arno11 has left #maemo-leste [#maemo-leste]
arno11 has joined #maemo-leste
<arno11>
Wizzup: ok i was wrong ;) it works with no autospawn
<bencoh>
nice
<arno11>
so the keys are 4000hz rate and resampling
<arno11>
and to be sure realtime scheduling is activated (but with default cfg it's ok)
<arno11>
in fact the same settings were blocking phone calls and sip from the beginning
<arno11>
it seems we can't communicate with the modem using sample rate > 4KHz
<Wizzup>
arno11: ok, great
<Wizzup>
so then we will disable autospawn just in case, I think
<Wizzup>
just to have it not mess with us in the future
<arno11>
totally agree
<Wizzup>
I wonder if there is anything to be learned from the pa config on fremantle, settings wise, there is a big difference in versions and it had nokia specific (closed and open) modules also
<Wizzup>
but maybe just to see what their sample rate was, and if they had some alternate sample rate
<Wizzup>
arno11: something that I don't understand yet, I think PA can downsample 44.1k to 4000, right? So why do we need alternate sample rate?
<Wizzup>
is it because both mic and modem only like 4000Hz?
<Wizzup>
(but this is not advertised clearly?)
<arno11>
very good questions, no idea
<Wizzup>
as in, I would think that if PA *knows* that the mic is only 4000Hz and so is the modem, then it should just downsample, and yet it might cost cpu, but it should still -work-
<Wizzup>
ok
<Wizzup>
because in that case we might be able to fix that in the driver or ucm, to advertise the right rates, or we missed some setting that allows it to record at higher freq
<arno11>
maybe
<arno11>
looking to fremantle stuff should be interesting...
<Wizzup>
probably also very confusing jfyi
<arno11>
yes probably :)
<arno11>
one more thing, fremantle is using dsp
<arno11>
maybe that's the only way to use higher freqs
<Wizzup>
right, it probably is
<Wizzup>
I don't know anything about that
<Wizzup>
got to go, back in 20-30 mins
<arno11>
ok
norayr has left #maemo-leste [Error from remote client]
<Wizzup>
I'm here btw, just waking up with some coffee
<Wizzup>
I will retrace your sip steps this morning, see if I can get some audio
<Wizzup>
(this isn't the official news post yet btw)
maxwelld has left #maemo-leste [Error from remote client]
<arno11>
Wizzup: for audio: cool. for n900 stuff: i'll have a look
<tg-bridge-bot>
<Peduityourselfism> Just was gonna ask about the official post. I have been following what you guys do, last night till the end and on other days too. Just awesome what you do. Just not giving notice cause your talks are above my pay grade and security credentials.
<arno11>
Wizzup: could be cool to talk a bit about overclock (i use it for now 6 months and it is really stable and never crashed). i think it is an important feature for most Fremantle users.
<arno11>
otherwise, i think the most important stuff with N900 now is stability and Leste is really stable on it now
<Wizzup>
re: overclock, good idea, I wonder if we can make it easier for people where it surives kernel upgrades so to say
<arno11>
i think the easy way is to provide a bash script to create a new uImage after each kernel update.
<arno11>
or providing a custom kernel for power users like fremantle :)
<Wizzup>
It's just some device tree magic right?
<arno11>
just a different opp table in dts (arround 50 lines of code only)
doc has joined #maemo-leste
<arno11>
but need another uImage to work because doesn't work on the fly
<Wizzup>
yeah
<tg-bridge-bot>
<Peduityourselfism> power-kernel sounds old maemo, which would be great.
<arno11>
agree :)
norayr has joined #maemo-leste
maxwelld has joined #maemo-leste
noidea__ has joined #maemo-leste
noidea_ has quit [Ping timeout: 250 seconds]
<arno11>
Wizzup: i just noticed you talk about n900-pm script in news post. but we can't use it as is because off soc_idle_states (off mode)
pere has quit [Ping timeout: 244 seconds]
<arno11>
if we remove soc idle part and start script it gives n900 arround 4 more hours idle (keeping only uart suspending stuff)
<arno11>
i can make a PR if you want
noidea__ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
Guest3941 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
maxwelld has left #maemo-leste [Error from remote client]
<Wizzup>
arno11: yeah but we can use it to measure some stuff
<Wizzup>
arno11: hm, probably good @ pr!
maxwelld has joined #maemo-leste
pere has joined #maemo-leste
<arno11>
to measure stuff: yes indeed, i mean just commenting the soc_idle part is enough to avoid reboot or weird screen stuff.
norayr has joined #maemo-leste
xmn has joined #maemo-leste
Guest3941 has quit [Quit: SIGINT received]
norayr has left #maemo-leste [Error from remote client]