maemish_ has quit [Quit: Connection closed for inactivity]
Twig has joined #maemo-leste
akossh has quit [Quit: Leaving.]
Twig has quit [Remote host closed the connection]
joerg has quit [Ping timeout: 276 seconds]
joerg has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
macros_2ndPC has quit [Ping timeout: 260 seconds]
macros_2ndPC has joined #maemo-leste
maemish_ has joined #maemo-leste
elastic_dog has joined #maemo-leste
elastic_dog has quit [Killed (lead.libera.chat (Nickname regained by services))]
k1r1t0_N900 has joined #maemo-leste
k1r1t0_N900 has left #maemo-leste [#maemo-leste]
norayr has quit [Quit: Gateway shutdown]
norayr has joined #maemo-leste
xmn has quit [Ping timeout: 255 seconds]
Twig has joined #maemo-leste
joerg has joined #maemo-leste
akossh has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: i need your help to test something with pulse.c
<arno11>
using my pactl tweak pulseaudio is just using the correct 16ms latency request from pulse.c
<arno11>
i see it from pactl
<arno11>
but the real answer from pa is arround 29ms
<arno11>
it can't do better i think
<arno11>
that's probably why there is a huge cpu usage
<arno11>
i think we should try to set pa_usec_to_bytes to 30ms (30 * 1000)
<arno11>
this way i think we will have a real 30ms latency and less cpu power cons
<arno11>
just a theory from what i see from pactl output
<arno11>
so i think we should try to set pa_usec to 30ms from the stock pulse.c
Twig has quit [Remote host closed the connection]
Twig has joined #maemo-leste
Twig has quit [Remote host closed the connection]
Twig has joined #maemo-leste
Twig has quit [Read error: Connection reset by peer]
Pali has joined #maemo-leste
<Wizzup>
arno11: hi
<Wizzup>
arno11: maybe you can modify the source (change 16 * 1000) to (32*1000), or maybe go for 50-100ms first to see if it works at all
<Wizzup>
since normally it was 600ms
<arno11>
hi
<Wizzup>
maybe try 100 * 1000 first for both sink and source
<arno11>
indeed maybe 50-100 first
<Wizzup>
and if it's still 5s then there's something else wrong
<Wizzup>
(maybe what I am doing)
<arno11>
makes sense for me
<arno11>
so 100 or maybe 64 ?
<Wizzup>
I think either is probably fine
<Wizzup>
maybe higher is safer as a first step
<Wizzup>
(so 100)
<arno11>
ok
<Pali>
Hello! I played with 0xFFFF again and implemented generating of mmc part layout for fiasco image.... Now it is possible to unpack all parts of Nokia MMC fiasco image and pack it back, and resulting fiasco image is byte exactly same as the original one.
<arno11>
Wizzup: now your changes from yesterday work ;)
<arno11>
with 100ms settings
<arno11>
but surprisingly pa configured 30ms request
<arno11>
and 43ms result
mrkrisprolls has joined #maemo-leste
<arno11>
sound is good
<arno11>
comparable to my previous tweak
<arno11>
and no real diff in latency perception
<arno11>
the weird result are probably due tsched and number of fragments
<arno11>
i can change that in daemon.conf iirc
<Wizzup>
arno11: great!!
<Wizzup>
arno11: can you elaborate on the tsched and fragment numbers?
<Wizzup>
the pa doc said to leave that unset so that PA can figure it out
<arno11>
yes indeed but per default (like 4000hz freq) pulseaudio use 4 fragments and tsched is active iirc
<arno11>
let me check
<Wizzup>
I think -1 in the case of the source code it just lets PA figure it out
<Wizzup>
I don't know what it means in context of daemon conf
<arno11>
daemon.conf is on top of all other stuff apparently
<arno11>
same s**t than frequencies lol
<Wizzup>
hm, does that void the code I wrote, I don't think so, right?
<arno11>
i'm wrong that's not in daemon.conf so no risk to void the code
<Wizzup>
ok, great
<arno11>
yes
<Wizzup>
how is the cpu usage?
<arno11>
still high
<arno11>
and not understanding why
<arno11>
3 or 4 pa process at the same time
<arno11>
looking similar
<Wizzup>
probably related to rate conversion honestly
<Wizzup>
anyway, we can deal with that a bit later I think
<arno11>
yes
<Wizzup>
do you want to reply on the ml to let pavel and others know that this fixes the latency issue mostly?
<arno11>
ok no probs
<arno11>
now i think the 2 next things to fix are: the portrait/landscape issue with sphone and the tricky way to start nokia modem with no sphone/ofono crash
<arno11>
for nokia modem i think i should find a solution
<Wizzup>
sphone can be worked around with a one liner, but I don't think uvos wants it because he thinks we should fix rotation in n900 driver
<Wizzup>
which is fair enough
<arno11>
indeed
<Wizzup>
sphone needs to pick up on modems being added
<Wizzup>
though
<Wizzup>
and we should ensure ofono on n900 can deal with modems being added ok
<Wizzup>
meanwhile I fixed all compile warnings/errors in cloudgps at least
<arno11>
cool !!!
<Wizzup>
for the sphone modem added bug, I think that is one for uvos
<arno11>
ok
<Wizzup>
is there still also a bug loading the module?
<Wizzup>
on boot say
<arno11>
no idea
<arno11>
i'll try on next reboot
<l_bratch>
Good afternoon, exciting news for N900 voice calls on the mailing list and above! :-) P.S. Is there a working mailing list archive anywhere? The one at https://mailinglists.dyne.org/pipermail/maemo-leste/ gives a 404. Thanks!
<Wizzup>
I tried to contact the dyne folks about it and they didn't reply
<Wizzup>
let me try again
<l_bratch>
thanks very much
<arno11>
google "maemo leste dyne.org" first link ;)
<freemangordon>
or, maybe it comes from -experimental, dunno
<Wizzup>
beowulf is newer one
<Wizzup>
did you build for the correct codename?
<Wizzup>
btw, PA installs /etc/pulse/client.conf.d/01-enable-autospawn.conf as symlink to /run/pulseaudio-enable-autospawn and /etc/init.d/pulseaudio-enable-autospawn
<Wizzup>
and /etc/init.d/pulseaudio-enable-autospawn runs on boot
<Wizzup>
we really don't want this
<Wizzup>
not sure what the cleanest way to deal with it is
<freemangordon>
Wizzup: anyway, I don;t see how we can build tp-gabble now, because of the broken dependencuis
<freemangordon>
*dependencies
<Wizzup>
can you remind me?
<Wizzup>
is that the dh python crap?
<freemangordon>
yes
* Wizzup
faceplams
<Wizzup>
I tried to forget about the debian stupidity there
<Wizzup>
shall we just build our own dh-python and ignore them?
<freemangordon>
wait
<freemangordon>
I don't understand why tp-gabble has python-is-python2 dependency
<freemangordon>
if I install dh-python, I can happily build it
<freemangordon>
and yes, it installs stuff in /debian
<bencoh>
maybe they required python2 at some point?
<Wizzup>
point is that debian broke python-is-python2 and dh-python
<Wizzup>
even though it worked fine from backports
<freemangordon>
yeah
<freemangordon>
E: dh_python2 dh_python2:408: no package to act on (python-foo or one with ${python:Depends} in Depends)
<freemangordon>
can;t we port whatever has to be ported?
<Wizzup>
no
<Wizzup>
unless you want to move to gtk3
<Wizzup>
bbiab
<freemangordon>
no, wait, I n=mean - for that particular package
<freemangordon>
*I mean
<Wizzup>
you can, but the system as a whole will remain broken
<freemangordon>
ok, what does this package need python for? tests?
<freemangordon>
so, do you tell me that we can;t have pythin3 and python2 installed in parallel?
<freemangordon>
IIUC we should just port tests from python2 to python3, shouldn't be that hard
<freemangordon>
Wizzup: btw, it is commit 61014ecc8c9d7f191f8fa50ad13d43b90e9688bf that causes to to place stuff in /debian
<Wizzup>
freemangordon: no
<Wizzup>
what I am saying is
<Wizzup>
we cannot build any python 2 package anymore
<Wizzup>
period
<Wizzup>
they just broke that
<Wizzup>
and there is no gtk2 for python3
<Wizzup>
so yeah
<freemangordon>
ok, but for that particular package, we don't need gtk at all
<freemangordon>
also, it needs python for its tests only
<freemangordon>
thus, I don;t see why we cannot port it to python3
<Wizzup>
sure you can do that, and iirc it was already done
<freemangordon>
umm, where?
<Wizzup>
some other tp pkg
<freemangordon>
in upstream?
<Wizzup>
but I won't do it, because I want python2 + dh-python to just work
<freemangordon>
ah
<freemangordon>
ok, lets ship our dh-python then
<freemangordon>
Wizzup: ok, but what shall we do now we have a broken tp-gabble? it does not use python because of the removed tests and yet it requires dh_python
<Wizzup>
freemangordon: shall I just ship a fixed dh-python
<Wizzup>
and then we can build it?
<freemangordon>
package does not need it now
<freemangordon>
E: dh_python2 dh_python2:408: no package to act on (python-foo or one with ${python:Depends} in Depends)
<freemangordon>
I (force) installed dh-python
<freemangordon>
but it does nothing because of the disabled tests
<freemangordon>
so I don;t understand why you want dh-python in our repos for that particular case
<Wizzup>
I don't know what the error that you shared means
<Wizzup>
but I think this is the same that I am talking about
<Wizzup>
where they just broke dh python 2
<freemangordon>
no
<freemangordon>
there is no error
<freemangordon>
sec
<Wizzup>
so iirc, 5.20221122 is the last version that worked
<Wizzup>
# This is not autoloaded on the N900 somehow on Linux 6.1
<Wizzup>
nokia-modem
<arno11>
oh
<arno11>
nice thx
<arno11>
need to reboot to try
<arno11>
sicelo: sorry now i remember it i not ti.com but simply in cmtspeech docs
arno11 has left #maemo-leste [#maemo-leste]
<sicelo>
i'll do my own tests too in next few days. afaict, it's been autoloading for me ... even on 6.3-rc1 (nokia-modem)
<sicelo>
rc6, i mean
arno11 has joined #maemo-leste
<arno11>
nokia-modem loaded on boot but not working
<arno11>
just shows pin stuff
<arno11>
sure it is because of the other modules
<arno11>
sicelo: should be interesting to see if nokia modem works if you load cmt_speech and omap_ssi on boot on your device
<arno11>
to be sure i'll block the 2 modules to test
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
arno11, hm... I see
<Wizzup>
I recall way back we had some init script that loaded the module a bit later, IIRC
arno11 has joined #maemo-leste
<arno11>
Wizzup: ah an init script a bit later makes lot of sense to me according of what's happening on my device
<arno11>
because removing other modules doesn't work
<arno11>
modem is loaded correctly but is not working
<arno11>
i need to check if i forgot a change i made...
<arno11>
anyway if modem is loaded after boot everything is fine
<arno11>
Wizzup: which var log could be helpful to check what's happening with modem on boot ?
<arno11>
oh i found the error
<arno11>
it is not working on my device because startup-pin is looking for the wrong device...
<arno11>
n900_2 instead of n900_4
<arno11>
that's probably because of stuff i tested with ofono scripts...
<arno11>
according to syslog
norayr has left #maemo-leste [Error from remote client]
<arno11>
weird thing is startup-pin is looking on the wrong device only if modem is loaded on boot
<arno11>
anyway that's a waste of time, everything should be ok on other n900's
<freemangordon>
Wizzup: I still fail to see how it will install instead of version in debian repos
<freemangordon>
also, besides tp-gabble, what other packages depend on that?
<sicelo>
arno11: that makes sense ... as i said, n900 + ofono been a rock solid combination for a long time. i was really surprised you were experiencing issues lately.