Hi, 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 done. 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 simplified): +----> headphones output | v 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: https://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem 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). Denis.
pgp5IXThKp57h.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant
