Request; help me fix Call Recorder t work on Nexus5 (Hammerhead)

[juiceme]

I recently made my own port of SFOS 2.0.2.48 on CM12.1/Hammerhead.

Most of the things that I need work on my port but Call Recorder is one of the things that doesen't; not a surprise since I expect the HW differs somewhat from what we have on sbj-1

I would like your help in fixing this so that it works also on ported devices (at least Hammerhead)

Symptoms;

• the UI works as expected
• the callrecorderd daemon runs without apparent problems
• when a call is made/received, a FLAC file is created, however it does not contain any sound or the sound data is almost nonexistent. The file is extremely short; couple of minutes of call creates just a second's worth of data.
• for example, a call that lasted 3m16s only created a file 8,1kB long. The file is "FLAC audio bitstream data, 16 bit, mono, 32 kHz, 35840 samples" and as played with 32kHz only lasts just over a second.

What I have checked already;

• the daemon is running
• pulseaudio has been connected (this is same on both Jolla-sbj1 and Nexus5:

[nemo@Sailfish ~]$ [nemo@Sailfish ~]$ pacmd info | grep record application.process.binary = "harbour-callrecorderd" application.process.arg0 = "/usr/bin/harbour-callrecorderd" application.name = "harbour-callrecorder" application.process.binary = "harbour-callrecorderd" application.process.arg0 = "/usr/bin/harbour-callrecorderd" application.process.binary = "harbour-callrecorder" application.icon_name = "harbour-callrecorder" application.process.arg0 = "harbour-callrecorder" voicecall-record: Call mode record (priority 0, available: no) [nemo@Sailfish ~]$

[dpurgin]

Hi!

In order to record calls there is a PulseAudio profile called voicecall-record which is available during an established voice call only. As soon as the sound card is in this profile, you can read downmixed voice call data from both parties from the primary sink. Basically that's what the Call Recorder does.

Can you please check if you can write a voice call audio using PA commands? As soon as the call is established. the card must be in voicecall profile:

$ pactl list cards | grep 'Active profile' Active Profile: voicecall

Then put the card to voicecall-record profile:

$ pactl set-card-profile 0 voicecall-record

Then check if the card is in the voicecall-record profile using the first command. Then try playing with this command that writes data from the active sink:

$ parec --record --device=sink.primary --channels=1 --file-format=wav output.wav

If the output.wav contains feasible audio, then we'll look into Call Recorder itself, there might be some initialisation order to be changed or something.

Can you please also attach the full output of pacmd list-cards and pacmd list-sinks?

[juiceme]

Thanks tor your quick reply!

First I stopped the Call Recorder daemon. Then I checked the active profile, with no call it is "Active Profile: primary-primary" and with voicecall going, it is "Active Profile: voicecall"

With call ongoing, I give the command "pactl set-card-profile 0 voicecall-record" After that, the profile is "Active Profile: voicecall-record"

When I give the parec command, it fails with error message "Stream error: No such entity"

Here are the cards and sinks: http://www.swagman.org/juice/list_cards.txt http://www.swagman.org/juice/list_sinks.txt

[dpurgin]

Sorry, I should have tested the command myself before posting!

The exact command I've just used to record in voicecall-record mode is the following:

$ parec --record --device=sink.primary.monitor --file-format=wav --verbose output.wav

Can you please try this one out? You should be able to play the captured audio using

$ paplay output.wav

[juiceme]

Thanks!

It indeed seems there is some glitch ongoing; I tried that and the parec command produced just a fairly small file. (2868 bytes for few minutes of call)

When the call ended, maybe 10 seconds after that the parec command timeouted.

Also, after the call was finished I checked "pactl list cards | grep 'Active'" and that command hung. When I interrupted that and checked "top", it shows pulseaudio taking about 20% of CPU time...

This time the pulseaudio seems to be in busyloop, still taking 20% CPU after 10 minutes.

## Before voicecall

[nemo@Sailfish ~]$ 
[nemo@Sailfish ~]$ pactl list cards | grep 'Active'
    Active Profile: primary-primary

## Now started voicecall

[nemo@Sailfish ~]$ 
[nemo@Sailfish ~]$ pactl list cards | grep 'Active'
    Active Profile: voicecall
[nemo@Sailfish ~]$ pactl set-card-profile 0 voicecall-record
[nemo@Sailfish ~]$ 
[nemo@Sailfish ~]$ parec --record --device=sink.primary.monitor --file-format=wav --verbose output.wav
Opening a recording stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'.
Connection established.
Stream successfully created.
Buffer metrics: maxlength=4194304, fragsize=352800
Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'.
Connected to device source.primary (index: 5, suspended: no).
Failed to get latency: Timeout
[nemo@Sailfish ~]$ 

## command timeouted maybe 10 seconds after finishing call, and the next command hung.

[nemo@Sailfish ~]$ pactl list cards | grep 'Active'

^CGot SIGINT, exiting.

[nemo@Sailfish ~]$ 
[nemo@Sailfish ~]$ ls -latr *wav
-rw-rw-r-- 1 nemo nemo 2868 Aug 16 23:42 output.wav
[nemo@Sailfish ~]$ 

[dpurgin]

I can't really help you then, it seems to be a PulseAudio problem,..

@jusa , can you please take a look?

[juiceme]

Thanks for looking into this anyway.

The fact that both devices work similarily up to the point of actually recording the audio, so that call establishing uses same method in pulseaudio leads me to believe that it is possible to get Call Recorder working for Hammerhead too, provided that this issue is fixed.

Most probably this is a bug in pulseaudio setup/environment rather than in the actual code. I will have to try looking into it, though it is fairly complicated as I understand.