Implement voicecall record support.

[jusa]

No description provided.

[thp]

Can't comment much on the PulseAudio API usage, but other than the two comments I made above, looks good.

[jusa]

Agree on do..while, it was written that way already elsewhere in anticipation of profiles which would have more than one sink or source. But probably everything needs to be restructured again when we cross that bridge anyway. So I'll remove the do..while.

Not having braces on single statement if-else-blocks is PulseAudio way, so won't touch that.

I'll need to do some changes still so that this code compiles with other than Qualcomm adaptation, AUDIO_CHANNEL_IN_VOICE_CALL_MONO is actually added by Qualcomm. With others it's AUDIO_CHANNEL_IN_VOICE_UPLINK etc.

[thp]

What happens here if $droiddevice contains characters outside of the [A-Za-z0-9] range? Can/should we have a check for that? (something like (echo $droiddevice | grep '[^A-Za-z0-9]') && exit 1 or so)

Also, this doesn't define DROID_DEVICE_GENERIC anymore if an unknown device is found.

[jusa]

Refactored virtual profile handling a bit and added hint when failing to get ANDROID_VERSION.

[CODeRUS]

Hello. For some reason when using headphones incoming voice not recorded.

[sledges]

Have you checked it with the call recorder app? https://openrepos.net/content/dpurgin/call-recorder

[CODeRUS]

@sledges yes, using this app for recording.

[sledges]

@dpurgin ^

[dpurgin]

@CODeRUS @sledges direct reason for this is harbour-callrecorder itself. To get the voice call data, one needs to switch card profile from 'voicecall' to 'voicecall-record'. harbour-callrecorder doesn't do this when any other port except 'earpiece' is active. If it did, you'd be unable to reroute a call from earpiece to other ports: when the call is rerouted, voicecall profile gets reactivated and the voice call recording data is lost. If we set the active profile back to voicecall-record, earpiece gets reactivated. I'll make a minimal working example soon and take it back here.

Thanks for mentioning, I completely forgot. Added this to known issues of harbour-callrecorder

[CODeRUS]

@dpurgin wow, that's ... sad.

[dpurgin]

@CODeRUS @sledges Seems like I was wrong. It still switches active port after rerouting but I went further and forced BOTH "voicecall-record" and active port after reroute is notified. It seems to be working with pacmd, now implementing it into harbour-callrecorder and will see what happens.

[jusa]

Looked into this now and filed a bug https://bugs.nemomobile.org/show_bug.cgi?id=778
Already figured out a fix as well, so will merge soon I hope after some more testing.

[dpurgin]

@jusa btw I've worked around this in the new release of harbour-callrecorder. IIRC, we talked about this on IRC, switching active port after switching to voicecall-record worked. If this helps, profile/port change flow is like this:

In case of earpiece call only:

1. Active port goes to output-earpiece
2. Active profile goes to voicecall
3. Set active profile to voicecall-record
4. Active profile goes to voicecall-record, sound is on earpiece

In case of switching to other devices during the call:

1. Active port goes to output-earpiece
2. Active profile goes to voicecall
3. Set active profile to voicecall-record
4. Active profile goes to voicecall-record, sound is on earpiece
5. User connects headset
6. Active profile goes to voicecall
7. Active port goes to output-wired_headset
8. Set active profile to voicecall-record
9. Active profile goes to voicecall-record, active port is shown as output-wired_headset, but sound is on earpiece.
10. Set active port to output-parking
11. Active port goes to output-parking
12. Set active port to output-wired_headset
13. Active port goes to output-wired_headset, sound is on headset.

Please see my application.cpp, lines 209-227, 169-207.

Hope this helps

[jusa]

@dpurgin There was a bug in the source input routing, so with this fix when routing changes no need to do anything else but switch again to voicecall-record profile.