<freemangordon>
looks like blocksize of 4k and eraseblock of 512k
<gnarface>
i uh... don't know how to read this output
<gnarface>
i usually just check with hdparm -I and believe what it says
<freemangordon>
anyway
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 245 seconds]
<freemangordon>
hmm, moving swap to a partition on sd card makes lots of difference
<Wizzup>
didn't we determine earlier that swap on mainline was broken? or was that presumably fixed
ungeskriptet has joined #maemo-leste
mkfx has left #maemo-leste [Error from remote client]
System_Error has quit [Ping timeout: 264 seconds]
System_Error has joined #maemo-leste
<freemangordon>
we did, however, I was using swapfile on sdcard
<freemangordon>
now I made a dedicated partition
trix has joined #maemo-leste
Twig has quit [Ping timeout: 248 seconds]
Twig has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
freemangordon: it makes a huge diff on my device as well
<arno11>
(i also use a sandisk extrem)
<arno11>
qt5 launch time is quite similar to chimaera now
<freemangordon>
how?
<arno11>
8-10 sec cold, 2-6 sec warm
<freemangordon>
this is the same on chimaera?
<arno11>
quite the same
<freemangordon>
ok
<arno11>
but with tg-desktop, that's crazy: cold was 7 min on daedalus, now 45 sec...(like chimaera)
<freemangordon>
what has changed?
<arno11>
what do you mean ?
<arno11>
i just use swap on partition instead of swap file
<arno11>
*dedicated partition
<arno11>
but it is still a way slower to launch qt apps than using qt5ct tweak, specially if i launch several apps
<Wizzup>
freemangordon: is it different on 6.12 I wonder
<Wizzup>
we're still on 6.6 right?
<arno11>
still on 6.6
lyubov has joined #maemo-leste
arno11 has quit [Quit: leaving]
<freemangordon>
Wizzup: no idea, but we shall plan kernel upgrade anyways
kiva has joined #maemo-leste
kiva has quit [Quit: Client closed]
mkfx has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
sphone should more gracefully handle pa failing
lyubov has quit [Quit: WeeChat 3.8]
arno11 has joined #maemo-leste
<arno11>
uvos: it helps, yeah, ty
<arno11>
now when the call fails, sphone is immediately ready to use. but sound in next incoming or outgoing call still doesn't work (kind of 'expected')
<arno11>
then next calls are ok
<arno11>
freemangordon: really wonder what has changed @swap or kernel or whatever. sounds not normal that swap on sd partition works better than swapfile, no ? should be similar (?)
<uvos>
"now when the call fails, sphone is immediately ready to use. but sound in next incoming or outgoing call still doesn't work (kind of 'expected')"
<uvos>
not totally expected from sphones side, sphone starting should sync its state up with pa again on the first call not the second
<uvos>
but sphone restarts fairly fast it could be that pa has not recovered from whatever the problem was by the time sphone has started again
<uvos>
logs would help
xes_ has quit [Quit: WeeChat 3.5]
<Wizzup>
pa recovering means pa restarting I think
<Wizzup>
there is no other reason you'd lose your connection to it
<Wizzup>
maybe we just pull in latest PA and see if it's more stable
<Wizzup>
I think PA is probably a dead end in the next few years as everything is moving to pipewire, and pipiwire as PA emulation (incl. modules)
<arno11>
yeah seems an easy stuff to use pipewire PA module
xes has joined #maemo-leste
pere has quit [Ping timeout: 248 seconds]
nela7 has quit [Ping timeout: 252 seconds]
<Wizzup>
maybe, it might also pose challenging
<arno11>
dealing with audio in linux is always a challenge :P
<arno11>
Wizzup: btw i wonder why it fails to switch ucm profile quickly from ringtone to call, and not if i play a song from audacious and receive a call (in this case, the switch hifi/voicecall works fine)
<arno11>
maybe something is wrong with gstreamer/ringtone ?
<freemangordon>
hmm, why dbus created processes are reniced to dbus process priority?
<freemangordon>
oh, it is inherited on fork :(
uvos has quit [Quit: Konversation terminated!]
ikmaak2 has joined #maemo-leste
ikmaak has quit [Read error: Connection reset by peer]
pere has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
arno11: in the ringtone case sphone switches profile and then stops the ringtone at more or less the same time
<uvos>
arno11: these 2 things happening at once is probubly what is causing pa to trip
<uvos>
i think mapphones should more or less just work with pipewire, n900 is a different matter.
<arno11>
ok i get it, ty
<freemangordon>
uvos: is it possible to first stop the ringtoe and then to switch the profile?
<uvos>
the call to pa is handed off to a different thread
<uvos>
so not really
pere has quit [Remote host closed the connection]
<uvos>
i mean you could add syncroniztion but pa should not crash just because gst and sphone are both using the interfaces at the same time
pere has joined #maemo-leste
<freemangordon>
yeah
<Wizzup>
we can try to pull in latest PA, and if it doesn't work, pull in pipewire with PA module
<Wizzup>
although the latter could be more work
<arno11>
hmm fo n900 case, it is supposed to not crash ofc but supposed to remix everything (once switched to ucm voicecall profile) if the ringtone fails to stop @the right time. at least it is what's happening with any other sound
<arno11>
uvos: ^
<arno11>
(remixing is activated by default in n900 daemon.conf FYI)
<uvos>
up to the beginning of that branch, but both since audio_stop_pipe ends up sending a message to gsts thread and the call_mode_pipe ends up sending a message to the libpulse thread this only encourages the gst thread to win this race