Notices

No, it won't but afaik the latest version doesn't already. I think you're still having a previous release of 0.3? The most recent one is 0.3-5.

i had build you gave me privately when fixing sources switching and updated to 0.3-5 recently also )

Well, just to make clear we're talking about the same thing...

From what I see and experienced myself, for that delay the main issue was not the switching delay itself but the effect it caused.

I think if you switch while on call you won't suffer anyway, there's time to take the phone off your ear, tap a button, hear that something's changing and so on. You might have heard these switches, but it's natural not to talk until you hear stable sound from headset/loudspeaker/BT/earpiece. I don't know about you or others but I usually warn the other side that I'm going to speaker/headset/BT and check if they hear me after switching I did this all the time, always, even without an application that may break something (fortunately, it doesn't).

So the main concern about the delay in older versions was that this delay occured also at the beginning of conversation, so if you called someone and he or she was quite quick, you might have not heard them saying 'hello'.

With the latest version 0.3-5 this switching delay was reduced to be as minimal as possible, so now it depends only on how quick pulseaudio does the actual switching and propagates the event. From my experience it's quite seamless. None of calls I made this week and a half started without me hearing 'hello', although some of them were on Bluetooth which turned out to be pretty slow in switching.

With Jusa's patch it should take less time and effort to switch the profile (I didn't check yet), but at the end of the day you end up with the same result. I will surely make the change as soon as this code goes public, but Jusa himself told it would be the next OS update after the upcoming one.

Hope this clarifies what I'm trying to say

An interesting observation. Even more interesting that no one has reported it before:

I made a few test calls to the same number (the remainng credit check), then opened Call Recorder and deleted one from the list. I must add that the credit check calls were the only items on the list. The moment I deleted one, a big "No calls recorded yet" appeared in the middle of the screen, even though there were entries still on the list. Taping on one of them did not do anything. Neither did a long tap. Closing and re-opening Call Recorder fixed it.

EDIT: A bit more experimenting. The effect seems quite curious and difficult to describe accurately. An example - I have 2 calls on the list, make a 3rd one (with Call Recorder open) and - "No calls recorded yet" appears. I delete one - so that 2 remain - and the top remaing one reacts to the tap but the bottom one doesn't. Or vice-versa.

@dpurgin my situation is following. i'm talking using loudspeaker and then connecting headphones, and i dont hear this moment of switching. with switching on call start i can live of course, because it usually just a "Hello". Just ping me when you'll have build for new module, i;ll test it. And yes, this will be very useful for me, not just for fun entertainment.

@pichlo, thanks for reporting! It is 100% reproduced whn deleting the recordings one by one in main page and it raises when only one recording is left on the list. It seems to be an issue of having the small number of recordings and likely doesn't affect the storage.

I've added it as issue to github

@coderus no problem, I'll make a branch for you as soon as I have some spare time

@dpurgin i have a bad report for you. After recording a call with callrecorder android apps can't record microphone anymore.

@coderus thanks for the report, can you please tell the exact application which doesn't? As you know, I don't use Android apps, so can't go with 'any' app :-)

Shazam, SoundHound for example

@coderus I checked and it turned out to be not an issue of the call recorder app itself, but the issue of switching to voicecall-record profile. It is reproduced with plain pacmd calls as well: the source.primary gets removed from pulseaudio and is being readded after that, so default source is assigned to source.fake.sco which obviously doesn't contain any data. Android VM doesn't seem to manage PA sources and uses the default one. The dirtiest workaround I came up with is issuing the following command when you need mic recording in android:

$ pacmd set-default-source source.primary

Thanks for digging it out, I'll contact Jusa on that.