<dsc_>
this removes AccountChannelPtr too, which is suppose to linger around
<dsc_>
I can get rid of AccountChannelPtr but it requires some changes to Tp
<dsc_>
and possibly affects other parts of conversations too
<dsc_>
the reason AccountChannelPtr stays around is to represent a persistent channel that you have not yet joined
<dsc_>
I talked about this earlier how architecturally the config stuff should be removed from lib/tp.cpp, I was talking about this
<dsc_>
I think 0.7.15 will segfault due to this commit
<dsc_>
yes, after leaving a groupchat it will segfault
<dsc_>
so I will work on tp for the next few days and untangle some stuff
<freemangordon>
dsc_: ok, great, just keep in mind I am MIA for 2 weeks starting Friday. Please do not break conversations too much while I am on holiday :p
<dsc_>
the changes required to make lib/tp.cpp more self-contained will be large and breakage might be present
<dsc_>
we can choose to keep the current arch for now and I do an easy fix
<freemangordon>
yeah, I understand
<freemangordon>
I was kidding anyways
<dsc_>
ok :)
<dsc_>
yes ill do my best ^^
<freemangordon>
but won;t be able to either test or make fixes
<dsc_>
unsure if I should look because ill probably be removing AccountChannel today
<freemangordon>
ok
<freemangordon>
still, I'll push the logger changes
<dsc_>
is the issue its not being saved to cfg?
<freemangordon>
rather it is not read back
<freemangordon>
test case is:
<freemangordon>
receive remote message, but not read it (so it is not marked as read on the server)
<freemangordon>
reconnect the account (so unread messages are delivered as scrollback)
n900 has quit [Ping timeout: 255 seconds]
<freemangordon>
that unread message is duplicated, because timestamp check fails, as date_last_message is 0 (as seen oin the lofs)
<freemangordon>
*logs
<dsc_>
right
<freemangordon>
I suspect channel settings are not re-read on logon
<dsc_>
yes
<dsc_>
AccountChannelPtr(new AccountChannel);
<dsc_>
look for this one
<freemangordon>
yeah, I understand
<dsc_>
right
<freemangordon>
but now you're going to remove that, I see no reason to fix it
<dsc_>
and configRead() is only in the constructor
<dsc_>
of TelepathyAccount
<freemangordon>
mhm
<freemangordon>
I saw that
<dsc_>
will fix :)
<freemangordon>
great! ok, lets push few fixes to haze and purple-fb
ceene has quit [Remote host closed the connection]
fab_ has quit [Quit: fab_]
xmn has joined #maemo-leste
<Wizzup>
so from my pov apart from the random audio issues where the kernel doesn't set what it should set in calls, the voicecall mgr stuff is working well on my d4
<Wizzup>
I'll make a PR with the various fixes
<Wizzup>
but we still need to figure out the kernel audio issues and then we could move a conversations release to stable too
<Wizzup>
(and then we can more easily break -devel)
<Wizzup>
I just don't know how to go around debugging this kernel issue
<Wizzup>
uvos: would you agree that switching PA UCM profiles back to HiFi and back to Phone Call should ideally set the regs up properly again?
<freemangordon>
Wizzup: If we are to release conversations to stable, the bug I reported ^^^ shall be fixed
<freemangordon>
but it is up to you and dsc_ to decide
<Wizzup>
ok, I don't know what the bug is that you mean, but keep in mind that current conversations stable is like months behind devel
<Wizzup>
like it'll probably segfault when going online/offline or something
<Wizzup>
(in some edge case)
<Wizzup>
in any case it's all moot until we figure out the kernel audio issue
<Wizzup>
I suppose we could decide to debug this, or we can go straight to 6.6 and try to figure out why it doesn't work there
<freemangordon>
no, it will not update last message received timestgamp going offline->online, leading to duplicated scrollback of the unread messages
<dsc_>
i can aim for a stable next week
<dsc_>
if needed
<dsc_>
wait, what day is it even...
<freemangordon>
wednesday
<dsc_>
thanks ;x
<freemangordon>
:)
<Wizzup>
ok
<Wizzup>
well, any suggestions on how to try to debug the call issues I would appreciate
<dsc_>
yes I think we can do a stable soon
<Wizzup>
since it's also (a similar bug) the only blocker for 6.6 or 6.8 (i forget) kernel
<freemangordon>
Wizzup: I guess tmlind is to the rescue :)
<Wizzup>
I am not sure if he has a lot of time recently
<Wizzup>
also for 6.1 (which is not pretty old) it might not be that worth it
<Wizzup>
which is now*
n900 has joined #maemo-leste
<Wizzup>
I guess we would need some trace of all alsa state changes or something
<Wizzup>
maybe cpcap_input_*_mux_set_enum or something will override what's currently set during voice call
<Wizzup>
must be some race with userspace somehow
fab_ has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
Livio has joined #maemo-leste
<Wizzup>
uvos: should I not see 'VOICE CALL' in dmesg whenever I switch ucm in pavucontrol?
<freemangordon>
AFAIK this is logged by the modem driver when modem reports incoming call
<Wizzup>
no this happens in cpcap_voice_call
<freemangordon>
but don;t quote me on that one
<freemangordon>
lemme grep
<Wizzup>
sound/soc/codecs/cpcap.c
<Wizzup>
no need to grep
<Wizzup>
the problem is that bits CPCAP_BIT_MB_ON1R and CPCAP_BIT_MB_ON1L are somehow unset when we are in the actual call
<Wizzup>
and from my understanding
<Wizzup>
modem -> ofono -> sphone acts on voice call -> starts ringing -> when picked up -> sphone tells PA to switch to voice call UCM
<Wizzup>
and this switch I believe is what should trigger all the right settings to be set, including the DAPM hack for which we print 'VOICE CALL"
<Wizzup>
but apparently switching UCM *does not* trigger cpcap_voice_call
<freemangordon>
maybe put printk in cpcap_voice_set_tdm_slot
<Wizzup>
cpcap_voice_set_tdm_slot is what calls cpcap_voice_call
<freemangordon>
mhm
<Wizzup>
yeah so you think this prevents this from being set when we're not in a call?
<Wizzup>
there's so much jargin in alsa kernel land it's mind boggling :(
<Wizzup>
jargon
<freemangordon>
but cpcap_voice_set_tdm_slot can return before calling cpcap_voice_call
<Wizzup>
yes exactly
<Wizzup>
but what is tdm slot even
<freemangordon>
TDM is time division multiplexing, but what it means in this context I have NFC
<Wizzup>
well I guess the function makes it pretty clear
<Wizzup>
so somehow in the timeslot setting we also actually set up the call regs
<Wizzup>
I am not sure why cpcap_voice_set_tdm_slot even needs to check if we are in a call, I guess because it needs to be able to unset somehow?
<freemangordon>
I would trace if cpcap_voice_set_tdm_slot() gets called at all
<Wizzup>
because us switching UCM from voice call to HiFi or vice versa isn't related to this level
<Wizzup>
well I know that during calls I typically see 'VOICE CALL'
<freemangordon>
so, if it is called but returns early, then yo should check why
<Wizzup>
I was just hoping I wouldn't have to keep calling myself just to see how some of this works
<freemangordon>
just put printk() every other source line
<Wizzup>
also I wonder if those errors are actually logged
<Wizzup>
or if some alsa debug value is missing
<freemangordon>
dev_err() is logged
<freemangordon>
but I don;t see error printed on calls to regmap
<freemangordon>
not sure if regmap will print error
<Wizzup>
well this is called from alsa code
<Wizzup>
see static const struct snd_soc_dai_ops cpcap_dai_voice_ops
<freemangordon>
yes, I know
<freemangordon>
thats why I said to check if it is called at all when voice fails
<Wizzup>
and yes it is
<Wizzup>
since 'VOICE CALL' is always printed
<freemangordon>
ah
<Wizzup>
and there's some race going on
<freemangordon>
sorry, my bad
<Wizzup>
so I think sound/soc/codecs/motmdm.c calls snd_soc_dai_set_tdm_slot
<Wizzup>
so maybe this has a better clue
<freemangordon>
I was left with the impression that sometimes there is no "VOICE CALL" message
<Wizzup>
ha the return value of motmdm_enable_primary_dai is ignored
<Wizzup>
freemangordon: I will have to triple check, but I am pretty sure that is always set
<freemangordon>
ok, ok
<Wizzup>
in codecs/motmdm.c see:
<Wizzup>
if (enable) motmdm_enable_primary_dai(ddata->component);
<Wizzup>
so it ignores the error tha we bubble up all the way from regmap sets
n900 has quit [Ping timeout: 256 seconds]
<Wizzup>
I think we should fix that regardless
<freemangordon>
why it is called at all from motmdm? isn;t ALSA supposed to call it
<Wizzup>
motmdm is the codec, so I guess that is part of alsa
<Wizzup>
I don't know what the graph of what uses what is here
<freemangordon>
but it shoudl not call that function directly, no?
<freemangordon>
I am as lost as you are perhaps
<Wizzup>
the codec seems to find ngsm serdev and see what the call state is
<Wizzup>
this is managed from /* Read the voice status from dlci1 and let user space handle rest */
<Wizzup>
static int motmdm_init_voice_dlci(struct motmdm_driver_data *ddata)
<Wizzup>
it seems
<Wizzup>
well and of course motmdm_soc_probe
<freemangordon>
well, I remember motmdm handling calls state
<freemangordon>
motmdm_enable_primary_dai() is called on incoming call, IIRC
<Wizzup>
the motmdm codec also registers dtmf/call noise cancel and call volume
<freemangordon>
see motmdm_voice_get_state
<Wizzup>
yes, this is what enables or disables the dai
<Wizzup>
so I guess there is no way to trigger it from userspace then
<freemangordon>
mhm
<Wizzup>
or perhaps there is, just not with our ucm
<Wizzup>
I suspect there is some race not that voicecall-manager is in play, and somehow the delay makes it worse
<Wizzup>
like if the ucm is set before or after the kernel performs all of this
<freemangordon>
sounds plausible
<freemangordon>
I wonder if we shall remove the call to snd_soc_dai_set_tdm_slot() and somehow tie it to UCM
<Wizzup>
we'd need some mixer/control in alsa to toggle this
<freemangordon>
yes, I know
<Wizzup>
there's also the whole DAPM hack that we have to do anything, which I still don't really understand, but I think the point is that because the audio does not go through userspace routing, alsa decides that we don't actually use/need it
<Wizzup>
and we haven't found a way to tell alsa not to do it other than force-enable dapm pins/paths
<freemangordon>
which obviously does not work properly
<Wizzup>
well it works ok for us now
<Wizzup>
but yes it's not ideal
<freemangordon>
as voice calls are not the only issue we have
<freemangordon>
no, mafw suffers as well
<Wizzup>
mafw suffers a lot more than other HiFi though
<Wizzup>
so maybe best to not conflate the issues
<Wizzup>
also killing mafw-renderer makes it work again when it's restarted, so there's other stuff going on there
<freemangordon>
I doubt mafw does something bad, as it uses PA
<Wizzup>
fine, but mpv with pa usually works fine after audio call
<Wizzup>
and this is not the result of DAPM I am quite sure
<freemangordon>
ok
<Wizzup>
it could be however that the tdm from before the call is not saved
<Wizzup>
and this might throw off PA and then everything else
<freemangordon>
but commenting out line 549 in motmdm makes it working properly
<Wizzup>
I can't believe this worked in sphone every time, hrm
<Wizzup>
tmlind: uvos: freemangordon: here are some dmesg logs from my droid 4 when I get called, I called myself three times and made three different logs of the relevant parts: https://wizzup.org/dirlist/maemo-leste/call-dmesg-logs/