Sorry for the delay I've a big mail backlog.

On Mon, 24 Jul 2023 23:07:01 +0100
J05HYYY via Replicant <replicant@osuosl.org> wrote:

> I traced the error about dbus not finding
> org.ofono.QualcommCoreSoundDriver_Beta1 to the file:
> https://git.replicant.us/contrib/scintill/frameworks_opt_telephony_ril_ofono/tree/src/c/libcsd-client.c?h=replicant-6.0
I don't know about this error, I'd need more background to understand
the issue.

> As ofono does not have that interface, it looks to me like we have to
> hook up audio routing judging by the arguments in
>       csd_client_start_voice(int rx_dev_id, int tx_dev_id, int
> keep_previous_handles) function
> typically when we route audio, we hook up input to output, source to
> sync, mic to speaker by the looks of things there is a tx device id
> and an rx device id
> I'm guessing the device ids refer to audio lines on the modem

On the GT-I9300, we need 2 things for audio:
- We need to send a command to the modem to tell it to enable audio
- We then need to change some alsa controls to enable the routing
  between the modem and the sound chip.

So for instance with GNU/Linux, ipc-modem and a script to route the
audio it's possible to ear calls.

So it's likely to be somewhat similar for the GT-I9305. I'm unsure if
we need the GT-I9305 to tell the modem to enable the audio, but at
least we need the alsa controls routing.

Finding the right set of ALSA control is not very hard. You could look
if there is a free software library that takes care of it in
older versions of LineageOS or CyanogenMod. 

If there is none the easiest way would be to install LineageOS /
CyanogenMod on the phone and then capture the ALSA controls state before
the call and inside the call. 

To make things easier you could call your voicemail so that the audio
codec (like 8khz GSM, AMR, 16khz wideband GSM, etc) is always the same.

Then you could install your Replicant build again and restore the alsa
controls state exactly like they were during the call and try to get
sound working. 

If things are almost the same you might still need to find the command
to send the modem to enable audio during calls if that's not already

I'm unsure exactly what is the best way to do that. The ideal situation
would be to be able to decode the QMI protocol in Wireshark as the USB
traffic can easily be captured with tcpdump (it is usually included in
Android distributions, and traffic can be captured with tcpdump -i
usbmon0 -w /sdcard/capture.pcap, tcpdump -i usbmon1 [...], etc as
root). This way you could even compare between Replicant and LineageOS.

I've done that already with samsung-ipc but my dissector is a work in
progress so it's not in Wireshark yet (it's in Replicant git in
/contrib/GNUtoo/tools/wireshark though).

Though here I'm unsure what tools are available for QMI.

Maybe the command is already sent by scintill's code or maybe the modem
doesn't need a command to enable audio.

PS: Note that recording a call through software would be way more
complicated. Usually smartphones have something like that (very

                +----> headphones output
Modem <---> CODEC (sound chip) <---> SOC
              +----> Speakers         

And usually it only routes the audio in an analog way between the modem
and the speakers or headphones through the sound chip only.

So if you want to record it, you either plug a recorder inside the jack
connector, or you would need a very different routing as the audio
would have to reach the SOC.

The connection between the SOC and the CODEC is usually in an audio
bus called I2S and it's a digital connection.

Here's an example of documentation for another phone:

Many CODEC chips also have public documentation, though I'm unsure if
there is documentation for the one for the GT-I9300/GT-I9305.

> I had hoped to use a library like libcmtspeechdata to route the audio
> for the modem as this would have been a good candidate.
Note that this library is for very different hardware: Usually phones
have a setup like the one I described above. But the Nokia N900/N9 and
probably (very few) similar phones don't have any dedicated hardware
routing for the sound between the modem and the SOC.

So this makes it complicated to get things working well because the
sound from the modem goes from the modem to the SOC, and then from the
SOC to the sound card. 

And so the routing needs to be done in software, and that's complicated
to do because it needs to be done in an efficient way that also has
very low latency. So the pulseaudio plugin for cmtspeech uses
scheduling tricks to make it work (when I looked at it many many years
ago it used some realtime scheduling priority).

Hardware routing like the GT-I9300 is much much easier to deal with and
once implemented the result is often very robust (you can't have part
of the audio missing because of scheduling issues since it's all done
in hardware).


Attachment: pgp5IXThKp57h.pgp
Description: OpenPGP digital signature

Replicant mailing list

Reply via email to