05-23-2021, 02:54 PM
(This post was last modified: 05-23-2021, 03:00 PM by dsimic.
Edit Reason: Wording improvements
)
You've performed a very good analysis. Thumbs up!
Based on the way audio is routed, wouldn't it be expected to make the issue reproducible with no actual call in place, if the root cause is the microphone or something along the microphone-to-SoC path? If that ends up as not reproducible, something must be wrong either along the CPU-to-modem path, which is probably unlikely, or within the modem itself. It could also be something up to the way power is supplied to the modem, but it's highly unlikely because the modem is pretty much directly connected to the battery.
If the root cause turns out to be the modem itself, the microphone could be placed out of the picture entirely, by having the CPU play a .wav file or something else containing a "test pattern" for the call, so to speak. Playing a "test pattern" instead of speaking into the microphone would also make it possible to perform precise and repeatable analysis of the audio received on the other end of the call.
Based on the way audio is routed, wouldn't it be expected to make the issue reproducible with no actual call in place, if the root cause is the microphone or something along the microphone-to-SoC path? If that ends up as not reproducible, something must be wrong either along the CPU-to-modem path, which is probably unlikely, or within the modem itself. It could also be something up to the way power is supplied to the modem, but it's highly unlikely because the modem is pretty much directly connected to the battery.
If the root cause turns out to be the modem itself, the microphone could be placed out of the picture entirely, by having the CPU play a .wav file or something else containing a "test pattern" for the call, so to speak. Playing a "test pattern" instead of speaking into the microphone would also make it possible to perform precise and repeatable analysis of the audio received on the other end of the call.
