PWM whine near earpiece in low signal phone call and loud sound sent to the other end
#11
(05-24-2021, 12:44 AM)vortex Wrote: If the problem is a DC-DC converter inside the modem itself, there might be a hardware mitigation (beyond making the microphone lines more immune to pickup by caging or something similar) depending on how the noise gets into the microphone line (assuming it is that). Something a simple as a filter on the power connection to the modem itself might help. DC-DC converters send a lot of noise backwards to the source in addition to propogating it forward. Essentially, adding a line filter in a potential future 1.2c revision.

Please, keep in mind that introducing such changes to the main board of the PinePhone might pose a problem, unfortunately, because of the already passed CE certification. It costs a lot to have the phone re-certified, and stretching the terms of the CE certification might not be a good idea, especially because the changes would be "touching" the modem. Undecided

If the modem's DC-DC converter noise eventually turns out to be the root cause, it might be possible to have mitigation in software, by limiting the modem's transmit power, if that's possible at all (which probably isn't), and if it's possible to find the "sweet spot" that eliminates the backfeed of the noise while not adversely affecting the operation of the modem in poor-signal conditions.

After a bit of searching, it seems that limiting the transmit power of the modem is actually rather easily doable (woo-hoo!), by (ab)using the vendor-specific AT commands described in this official document.  Those AT commands look very interesting, and are not available in the standard official manual. Smile  Testing out the effects of limiting the transmit power should be worth it, if you agree.

By the way, this document contains, among a lot of other stuff, the reference designs for the modem's power supply circuit.  Those might be usable.

(05-24-2021, 12:44 AM)vortex Wrote:
(05-23-2021, 05:49 PM)dsimic Wrote: As a note, configuring the required audio routing should be possible by using or modifying the audio configuration program that's available on Ondrej's web page.  I haven't researched that in detail, but I think it's rather easily doable once you get a grasp on the entire audio subsystem.  The hard part, dissection of the PinePhone's audio subsystem, has already been done by Ondrej.

That is what made me think it is doable and how to do it. Set things up like there with maybe a tweak or two to insert audio and start the call from mmcli with AT commands (can't use the call program since that would override the audio settings). But there will be quite a bit to learn in order to do it.

I might be wrong, but wouldn't passing "-2" as the only argument to Ondrej's audio setup utility activate the modem's digital audio interface, while keeping all other "usual" audio inputs and outputs disabled?  I might easily be wrong because I havent't researched the A64's built-in audio codec in detail, but the effects of the "-2" parameter might be exactly what you need.
  Reply
#12
I tried recording sound while downloading a large file over 2 G (needed to be slow and bandwidth heavy) and it didn't work. Problem is, when downloading, the transmit power is only very intermittently high and when it pulses high, there is an audible sound (probably from a capacitor charging) that is extremely broadband that limits the ability to pick anything else up.

With the way the sound is configured, I think it should be possible to run the recorder while doing a phone call (which has high upload and high and stable transmit power). I will see how that goes.

(05-24-2021, 02:11 AM)dsimic Wrote:
(05-24-2021, 12:44 AM)vortex Wrote: If the problem is a DC-DC converter inside the modem itself, there might be a hardware mitigation (beyond making the microphone lines more immune to pickup by caging or something similar) depending on how the noise gets into the microphone line (assuming it is that). Something a simple as a filter on the power connection to the modem itself might help. DC-DC converters send a lot of noise backwards to the source in addition to propogating it forward. Essentially, adding a line filter in a potential future 1.2c revision.

Please, keep in mind that introducing such changes to the main board of the PinePhone might pose a problem, unfortunately, because of the already passed CE certification. It costs a lot to have the phone re-certified, and stretching the terms of the CE certification might not be a good idea, especially because the changes would be "touching" the modem. Undecided

I forgot about that. You are right, it is one of the big downsides. Not something to do lightly. If some other reason causes a revision 1.2c, might as well since the board would need recertification anyways. But if there is no other reason to do another board revision, it is probably best to stick to software mitigations. So I guess, once the cause is determined and if it is a hardware problem, it is something to keep on the TODO list if there is ever another board revision.

(05-24-2021, 02:11 AM)dsimic Wrote: If the modem's DC-DC converter noise eventually turns out to be the root cause, it might be possible to have mitigation in software, by limiting the modem's transmit power, if that's possible at all (which probably isn't), and if it's possible to find the "sweet spot" that eliminates the backfeed of the noise while not adversely affecting the operation of the modem in poor-signal conditions.

The downside of limiting the max transmit power is that it basically reduces the coverage of the phone to only those locations where the transmit power can be kept lower than a certain amount. But, like you said, there might be a sweat spot close the max that is a local mi

(05-24-2021, 02:11 AM)dsimic Wrote: After a bit of searching, it seems that limiting the transmit power of the modem is actually rather easily doable (woo-hoo!), by (ab)using the vendor-specific AT commands described in this official document.  Those AT commands look very interesting, and are not available in the standard official manual. Smile  Testing out the effects of limiting the transmit power should be worth it, if you agree.

By the way, this document contains, among a lot of other stuff, the reference designs for the modem's power supply circuit.  Those might be usable.

This will be really useful for testing.

(05-24-2021, 02:11 AM)dsimic Wrote:
(05-24-2021, 12:44 AM)vortex Wrote:
(05-23-2021, 05:49 PM)dsimic Wrote: As a note, configuring the required audio routing should be possible by using or modifying the audio configuration program that's available on Ondrej's web page.  I haven't researched that in detail, but I think it's rather easily doable once you get a grasp on the entire audio subsystem.  The hard part, dissection of the PinePhone's audio subsystem, has already been done by Ondrej.

That is what made me think it is doable and how to do it. Set things up like there with maybe a tweak or two to insert audio and start the call from mmcli with AT commands (can't use the call program since that would override the audio settings). But there will be quite a bit to learn in order to do it.

I might be wrong, but wouldn't passing "-2" as the only argument to Ondrej's audio setup utility activate the modem's digital audio interface, while keeping all other "usual" audio inputs and outputs disabled?  I might easily be wrong because I havent't researched the A64's built-in audio codec in detail, but the effects of the "-2" parameter might be exactly what you need.

Looking at the code, you are right, -2 is what to use. Thank you.
  Reply
#13
(05-24-2021, 03:31 AM)vortex Wrote: I tried recording sound while downloading a large file over 2 G (needed to be slow and bandwidth heavy) and it didn't work. Problem is, when downloading, the transmit power is only very intermittently high and when it pulses high, there is an audible sound (probably from a capacitor charging) that is extremely broadband that limits the ability to pick anything else up.

How about trying to upload a large file under the same network circumstances?  A large file upload should crank the modem's transmit power to the max, and keep it at that level for as long as the upload keeps going.  It should even suffice to run "speedtest-cli --no-download --server <id>" (maybe with the "--single" flag as well) on the phone in a simple "for" loop, so you don't have to search for a fast server that accepts large file uploads.

(05-24-2021, 03:31 AM)vortex Wrote: With the way the sound is configured, I think it should be possible to run the recorder while doing a phone call (which has high upload and high and stable transmit power). I will see how that goes.

It should be possible. As far as I can see, you should pass "-2" together with other relevant flags to Ondrej's audio setup utility, to activate the modem's digital audio interface while enabling the "usual" audio input and output as well, i.e. the earpiece and the microphone.  In other words, that should be a pretty much regular phone call, which could also be placed using the regular dialer application.

(05-24-2021, 03:31 AM)vortex Wrote: Looking at the code, you are right, -2 is what to use. Thank you.

You're welcome.  Thank you for doing all this testing in the first place!
  Reply
#14
Was able to successfully record the sound, but it had to be a phone call. It is definitely in the microphone line. The person who I called that first time confirmed this was the sound they had heard when I played the recording to them. It also matches what I heard on the recorder when it had been recorded earlier.

There is good and bad news, which I will get into at the end.

First, methods. I tried your suggestion:

(05-24-2021, 04:04 AM)dsimic Wrote:
(05-24-2021, 03:31 AM)vortex Wrote: I tried recording sound while downloading a large file over 2 G (needed to be slow and bandwidth heavy) and it didn't work. Problem is, when downloading, the transmit power is only very intermittently high and when it pulses high, there is an audible sound (probably from a capacitor charging) that is extremely broadband that limits the ability to pick anything else up.

How about trying to upload a large file under the same network circumstances?  A large file upload should crank the modem's transmit power to the max, and keep it at that level for as long as the upload keeps going.  It should even suffice to run "speedtest-cli --no-download --server <id>" (maybe with the "--single" flag as well) on the phone in a simple "for" loop, so you don't have to search for a fast server that accepts large file uploads.

It did get a more steady transmit power, but not quite enough to be able to reliably get the sound. The resulting sound was similar to the sound that is send over the phone during a call, but not an exact match. So, it can still be used for simple testing, but doesn't quite match the characteristics. Namely, it is very pulsed and has all the spectral properties that entails along with some other differences.



So, I forced the modem into 2G mode (weaker 2G reception where I am at than 4G), took a landline at the same location, setup the call, and recorded the sound with the Sound Recorder app installed by default on Mobian. To make the signal worse and increase the transmit power, I held the phone in a metal enclosure with the door slightly ajar so I could hold it and see it (the kind of metal enclosure circuit breakers are put in).

It recorded the sound like a charm and the recorded sound matched the noise. That is the good news.

I transferred the FLAC file to my computer and converted to WAV.

I then wrote a short python script to open the file, take the spectrogram, export it to a CSV and as a plot. I put the code as well as my CSV file and plot on a public git repository pinephone_call_noise_investigation so others may do the same analysis and look at my data and possibly add their own spectrograms.

The resulting spectrogram, which is where the bad news starts, is

[Image: spectrogram_Freja_Nordsiek_2021_05_24_2G...al_box.png]

What I interpreted that I heard on the recorder is vastly different from what the noise actually is, in a bad way. It is a frequency comb instead of a narrow band sound. Worse yet, the comb starts at 220 Hz which is in the range of where human voice fundamental frequencies lie.

So no simple single notch/band-stop filter would work. Instead a filter that eliminates a frequency comb is needed, and it must be very sharp to eliminate the frequency comb and still preserve enough of the actual audio that a person can be understood. Hopefully such a filter exists.

And then there is an important question. How widespread is this phenomena among PinePhones in low cellular signal conditions? For those that have it, is the frequency the same? This latter one is important for implementing any filter in a widespread fashion. If each phone with the problem has a different frequency, each phone will require tuning of the filter. If it is the same, then the parameters can be found very accurately using one or a handful of phones and used for all with the problem.


EDIT - Adding two things

I despaired a bit too early. Turns out there are IIR comb notch filters (https://docs.scipy.org/doc/scipy/referen...rcomb.html), though the order would be quite high (CPU intensive).

Second, 220 Hz is almost identical to 44 kHz / (2 * 100). The sound appears to be recorded at 44 kHz, and the sound is 1/100 the Nyquist frequency. Could be a coincidence. Might be related.
  Reply
#15
(05-24-2021, 10:21 AM)vortex Wrote: So, I forced the modem into 2G mode (weaker 2G reception where I am at than 4G), took a landline at the same location, setup the call, and recorded the sound with the Sound Recorder app installed by default on Mobian. To make the signal worse and increase the transmit power, I held the phone in a metal enclosure with the door slightly ajar so I could hold it and see it (the kind of metal enclosure circuit breakers are put in).

If possible, it would be interesting to repeat the same experiment once more, now with a wired headset connected to the phone.  That way, the built-in microphone would be left unused, so it would be possible to determine whether the issue stems from the built-in microphone or from the routing of the audio signals.  Maybe it's even up to the A/D conversion performed inside the A64 SoC?

I'll try to reproduce the issue, by placing my PinePhone in a metal enclosure, etc.  By the way, back at the time when the modem calls initially started to work on the PinePhone, the dialer application didn't perform the audio routing.  As a result, there was a loud noise during the call, resemblling some sort of weird, metallic, pulsating noise that made it impossible to hear the other end of the call, or the other end to hear me.  After executing the audio setup utility, during the call, this noise disappeared and the audio quality was rather good afterwards.  I wonder if this is somehow related?

(05-24-2021, 10:21 AM)vortex Wrote: The resulting spectrogram, which is where the bad news starts, is

[Image: spectrogram_Freja_Nordsiek_2021_05_24_2G...al_box.png]

Nice work on creating the analysis and plotting utility!  The first thing that crossed my mind once I saw these spectrograms was "damn! the noise covers nearly the entire audible spectrum!" and it sadly turned out to be true after reading your explanation. Undecided

(05-24-2021, 10:21 AM)vortex Wrote: And then there is an important question. How widespread is this phenomena among PinePhones in low cellular signal conditions? For those that have it, is the frequency the same? This latter one is important for implementing any filter in a widespread fashion. If each phone with the problem has a different frequency, each phone will require tuning of the filter. If it is the same, then the parameters can be found very accurately using one or a handful of phones and used for all with the problem.

I'll try to reproduce the issue on my PinePhone, and hopefully more people would do the same.  That's the only way to know how widespread the issue is, and whether it manifests in the same way on all affected phones.

Edit: I somehow managed to forget mentioning that the proprietary modem firmware can be updated, which you're probably already aware of, so you should check that as well. You can find the instructions, the latest firmware, and the release notes in this repository.  Further information, including the source code of the update utility, can be found in this forum thread

Edit #2: Here's a very good insight from Biktorgj, who is the primary author of the open-source firmware for the PinePhone's Quectel modem. The quotation below comes from an IRC session on #pinedev, in which I asked Biktorgj to have a look at this forum thread.

Quote:Difficult to diagnose without hearing it and finding something to replicate. Smile

I've always heard some noise from the modem during calls that seems to filter to the analog amp in the pinephone but it's never been a static whine, you can hear the "data" being moved between the bts and the modem like when you put a phone near an amplifier, but I'm always on 4G with VoLtE.

That said, the modem does have some gain compensation and white noise generation through the afe loop which can be making the problem worse. First I would try to adjust the output level to the modem, then I'd try without the AFE calibration and that stuff (my firmware doesn't have it).

The modem doesn't have any internal dac/adc for voice (it can be optionally attached to an external codec but the pinephone doesnt have one, so everything that the modem gets is digital).

The other thing that could be tried is setting audio to 16KHz if running stock firmware or to 48k if using the custom one, just in case the resampling is getting artifacts into the audio, but maybe that's useless.
  Reply
#16
(05-24-2021, 01:28 PM)dsimic Wrote:
(05-24-2021, 10:21 AM)vortex Wrote: So, I forced the modem into 2G mode (weaker 2G reception where I am at than 4G), took a landline at the same location, setup the call, and recorded the sound with the Sound Recorder app installed by default on Mobian. To make the signal worse and increase the transmit power, I held the phone in a metal enclosure with the door slightly ajar so I could hold it and see it (the kind of metal enclosure circuit breakers are put in).

If possible, it would be interesting to repeat the same experiment once more, now with a wired headset connected to the phone.  That way, the built-in microphone would be left unused, so it would be possible to determine whether the issue stems from the built-in microphone or from the routing of the audio signals.  Maybe it's even up to the A/D conversion performed inside the A64 SoC?

Sadly, I don't have a wired headset and the store that would have one is hard to go to with the pandemic unless something changed in the last week (not going to try to get a headset online given how hard it is to get headphones that fit and operate well when buying in person).

One thing to note, it seems the issue is worst on 2G and 2.5G. This could be correlation (poor signal and thus drop to lower G) or it could be causation (e.g. for the same transmit power, 2G is worse than higher G).

(05-24-2021, 01:28 PM)dsimic Wrote: I'll try to reproduce the issue, by placing my PinePhone in a metal enclosure, etc.  By the way, back at the time when the modem calls initially started to work on the PinePhone, the dialer application didn't perform the audio routing.  As a result, there was a loud noise during the call, resemblling some sort of weird, metallic, pulsating noise that made it impossible to hear the other end of the call, or the other end to hear me.  After executing the audio setup utility, during the call, this noise disappeared and the audio quality was rather good afterwards.  I wonder if this is somehow related?

It is related to that sound. When I first heard the recorder, I thought it was something very different. But listening to my more recent recording, I think they are related. The pulsating sound has the same spectral characteristics as the more continuous sound, so I think they are the same. Since my Nexus 5 makes similar sounds but doesn't have the issue, I am inclined to think it isn't direct audio coupling from the sound to the microphone. This is why I think it is electronic. I could of course be wrong on this.

So, I think what you just brought up is worth investigating further.

(05-24-2021, 01:28 PM)dsimic Wrote:
(05-24-2021, 10:21 AM)vortex Wrote: The resulting spectrogram, which is where the bad news starts, is

Nice work on creating the analysis and plotting utility!  The first thing that crossed my mind once I saw these spectrograms was "damn! the noise covers nearly the entire audible spectrum!" and it sadly turned out to be true after reading your explanation. Undecided

(05-24-2021, 10:21 AM)vortex Wrote: And then there is an important question. How widespread is this phenomena among PinePhones in low cellular signal conditions? For those that have it, is the frequency the same? This latter one is important for implementing any filter in a widespread fashion. If each phone with the problem has a different frequency, each phone will require tuning of the filter. If it is the same, then the parameters can be found very accurately using one or a handful of phones and used for all with the problem.

I'll try to reproduce the issue on my PinePhone, and hopefully more people would do the same.  That's the only way to know how widespread the issue is, and whether it manifests in the same way on all affected phones.

Yes. With luck, I will be the only one or nearly the only one. Would be really bad if it was pervasive.

(05-24-2021, 01:28 PM)dsimic Wrote: Edit: I somehow managed to forget mentioning that the proprietary modem firmware can be updated, which you're probably already aware of, so you should check that as well. You can find the instructions, the latest firmware, and the release notes in this repository.  Further information, including the source code of the update utility, can be found in this forum thread

I am familiar with it and looking forward to where the firmware will eventually go, but I am not quite ready to dive down that rabbit hole yet. A lot of things I have to get setup before I can go there.

That all said, that firmware might be able to have some effect on the problem (e.g. use settings that reduce it).

(05-24-2021, 01:28 PM)dsimic Wrote: Edit #2: Here's a very good insight from Biktorgj, who is the primary author of the open-source firmware for the PinePhone's Quectel modem. The quotation below comes from an IRC session on #pinedev, in which I asked Biktorgj to have a look at this forum thread.

Quote:Difficult to diagnose without hearing it and finding something to replicate. Smile

I've always heard some noise from the modem during calls that seems to filter to the analog amp in the pinephone but it's never been a static whine, you can hear the "data" being moved between the bts and the modem like when you put a phone near an amplifier, but I'm always on 4G with VoLtE.

That said, the modem does have some gain compensation and white noise generation through the afe loop which can be making the problem worse. First I would try to adjust the output level to the modem, then I'd try without the AFE calibration and that stuff (my firmware doesn't have it).

The modem doesn't have any internal dac/adc for voice (it can be optionally attached to an external codec but the pinephone doesnt have one, so everything that the modem gets is digital).

The other thing that could be tried is setting audio to 16KHz if running stock firmware or to 48k if using the custom one, just in case the resampling is getting artifacts into the audio, but maybe that's useless.

As I mentioned earlier, I misinterpreted the sound at first as a static whine from what the recorder was able to get. The sound is closer to the sound one hears when "data" is moving now that I have had a chance to hear a decent recording.

If the CPU is using a fixed gain and the modem is doing an adjustable gain that adjusts to match the sound level, there are some possible mitigations. One would be to have the gain from the modem decrease more rapidly than it can increase.

Also, if a comb filter needs to be implemented, it could be run from the CPU or the modem, whichever is easier and requires less power.

I don't know if the sampling frequency in the modem would have much effect given that the frequency comb is seen at the CPU. But, there is a chance it might due to interactions between the different close components in the CPU's sound unit due to their close proximity electrically.
  Reply
#17
I managed to get a wired headset since the store is open now and do a recording with it. I wasn't able to get a very long recording yet (important for getting very good spectrograms) but was able to some preliminary ones.

The bad news is that the problem is still there. The good news is that it is A LOT quieter with the headset. The spectrogram is below. There are a lot more spikes visible in it because the problem is quieter overall (easier to see other spikes). Also, the recording was shorter and that means a noisier looking spectrogram.

[Image: spectrogram_Freja_Nordsiek_2021_05_29_2G...eadset.png]


Going to do a test call in the location with the very bad signal that had the problem the worst later this week. Also going to try to get some very long recordings to really narrow in on the exact frequency of the frequency comb.

Later, I need to try the code at https://xnux.eu/devices/feature/audio-pp.html and start tweaking the audio settings.
  Reply
#18
Hi again, I'm not sure if i understand the exact layout of the pinephone audio! On phosh (manjaro-arm beta 10) audio test it sounds like there are 2 speakers on each side, left/right!? Why would there be a speaker on the bottom near the mic? Doesn't this create the echo as the bottom speakers are beside the mic?

Anyhow, when I make a call on phosh I get a pop-up with some options, speakers on/off, mic on/off. I could hardly hear the other person when making a call so I logically turned the speaker on which in turn, I surmise, created the echo effect. I decided to not turn the speakers on and try small earbud headphones and this seems to have worked. So an interim solution for me right now. The pinephone is supposed to be my main phone and I need a reliable cellular, Phone, SMS, and data download to start with. AFter hearing about the SIM card slot malfunctions/breakages, I really don't want to be swapping out the SIM card on a regular basis. Thanks for effort by many to move this project forward.
  Reply
#19
(05-25-2021, 11:57 AM)vortex Wrote:
(05-24-2021, 01:28 PM)dsimic Wrote: By the way, back at the time when the modem calls initially started to work on the PinePhone, the dialer application didn't perform the audio routing.  As a result, there was a loud noise during the call, resemblling some sort of weird, metallic, pulsating noise that made it impossible to hear the other end of the call, or the other end to hear me.  After executing the audio setup utility, during the call, this noise disappeared and the audio quality was rather good afterwards.  I wonder if this is somehow related?

It is related to that sound. When I first heard the recorder, I thought it was something very different. But listening to my more recent recording, I think they are related. The pulsating sound has the same spectral characteristics as the more continuous sound, so I think they are the same. Since my Nexus 5 makes similar sounds but doesn't have the issue, I am inclined to think it isn't direct audio coupling from the sound to the microphone. This is why I think it is electronic. I could of course be wrong on this.

So, I think what you just brought up is worth investigating further.

I might be wrong, bit I think that at least some of the weird noises I've described above were caused by the voice of the called party being played through the PinePhone's built-in speaker.  That surely created an audio spill, which at least contributed to those weird pulsating noises.

Could an audio spill be one of the reasons for the original problem you're experiencing?  If so, something inside the phone could be picking up the audio output signal and emitting it, in some way or form, through the built-in speaker.  The microphone could be picking that, creating a spill.

(05-25-2021, 11:57 AM)vortex Wrote:
(05-24-2021, 01:28 PM)dsimic Wrote: Edit: I somehow managed to forget mentioning that the proprietary modem firmware can be updated, which you're probably already aware of, so you should check that as well. You can find the instructions, the latest firmware, and the release notes in this repository.  Further information, including the source code of the update utility, can be found in this forum thread

I am familiar with it and looking forward to where the firmware will eventually go, but I am not quite ready to dive down that rabbit hole yet. A lot of things I have to get setup before I can go there.

That all said, that firmware might be able to have some effect on the problem (e.g. use settings that reduce it).

Sorry, I wasn't clear enough...  The above-linked repository contains the latest version of the official, proprietary modem firmware, which is provided by Quectel.  It would be advisable to update the modem firmware to the latest available official version; just have a look at the mile-long update release notes.

(05-25-2021, 11:57 AM)vortex Wrote: I don't know if the sampling frequency in the modem would have much effect given that the frequency comb is seen at the CPU. But, there is a chance it might due to interactions between the different close components in the CPU's sound unit due to their close proximity electrically.

If everything else fails, it might be worth trying to change the sampling frequency.

(05-29-2021, 10:44 AM)vortex Wrote: I managed to get a wired headset since the store is open now and do a recording with it. I wasn't able to get a very long recording yet (important for getting very good spectrograms) but was able to some preliminary ones.

The bad news is that the problem is still there. The good news is that it is A LOT quieter with the headset. The spectrogram is below. There are a lot more spikes visible in it because the problem is quieter overall (easier to see other spikes). Also, the recording was shorter and that means a noisier looking spectrogram.

This might support my above-described "theory" that an audio spill might be contributing to the issues you're experiencing, because an increased distance between the phone's built-in speaker and the headset's microphone would decrease the spill.  This "theory" could be easily verified by taping up the built-in speaker and using a wired headset to make a test call...  It might be worth trying, if you agree.

(06-04-2021, 08:27 AM)Rainer Wrote: I'm not sure if i understand the exact layout of the pinephone audio! On phosh (manjaro-arm beta 10) audio test it sounds like there are 2 speakers on each side, left/right!? Why would there be a speaker on the bottom near the mic? Doesn't this create the echo as the bottom speakers are beside the mic?

There's a single speaker in the PinePhone, as visible in the daughterboard schematic, but for some reason the audio test in Phosh shows the left and right channels.  Actually, the two channels should be mixed into a mono output by the audio codec, and fed to the mono speaker.

The built-in speaker is disabled during phone calls, and the earpiece is enabled.  When the speaker is not disabled, it surely creates an audio spill, as I've described it above.  What happens when the speaker(phone) is activated during a call?  I'm not sure, I haven't tried that. Smile
  Reply
#20
(06-04-2021, 08:27 AM)Rainer Wrote: Hi again, I'm not sure if i understand the exact layout of the pinephone audio! On phosh (manjaro-arm beta 10) audio test it sounds like there are 2 speakers on each side, left/right!? Why would there be a speaker on the bottom near the mic? Doesn't this create the echo as the bottom speakers are beside the mic?

That lower speaker is the powerful speaker for playing sounds when not in a phone call. It is quite powerful. It is disabled by default during phone calls at least on Mobian for exactly that reason.

(06-04-2021, 08:27 AM)Rainer Wrote: Anyhow, when I make a call on phosh I get a pop-up with some options, speakers on/off, mic on/off. I could hardly hear the other person when making a call so I logically turned the speaker on which in turn, I surmise, created the echo effect. I decided to not turn the speakers on and try small earbud headphones and this seems to have worked. So an interim solution for me right now. The pinephone is supposed to be my main phone and I need a reliable cellular, Phone, SMS, and data download to start with. AFter hearing about the SIM card slot malfunctions/breakages, I really don't want to be swapping out the SIM card on a regular basis. Thanks for effort by many to move this project forward.

(06-04-2021, 09:26 AM)dsimic Wrote:
(05-25-2021, 11:57 AM)vortex Wrote:
(05-24-2021, 01:28 PM)dsimic Wrote: By the way, back at the time when the modem calls initially started to work on the PinePhone, the dialer application didn't perform the audio routing.  As a result, there was a loud noise during the call, resemblling some sort of weird, metallic, pulsating noise that made it impossible to hear the other end of the call, or the other end to hear me.  After executing the audio setup utility, during the call, this noise disappeared and the audio quality was rather good afterwards.  I wonder if this is somehow related?

It is related to that sound. When I first heard the recorder, I thought it was something very different. But listening to my more recent recording, I think they are related. The pulsating sound has the same spectral characteristics as the more continuous sound, so I think they are the same. Since my Nexus 5 makes similar sounds but doesn't have the issue, I am inclined to think it isn't direct audio coupling from the sound to the microphone. This is why I think it is electronic. I could of course be wrong on this.

So, I think what you just brought up is worth investigating further.

I might be wrong, bit I think that at least some of the weird noises I've described above were caused by the voice of the called party being played through the PinePhone's built-in speaker.  That surely created an audio spill, which at least contributed to those weird pulsating noises.

Could an audio spill be one of the reasons for the original problem you're experiencing?  If so, something inside the phone could be picking up the audio output signal and emitting it, in some way or form, through the built-in speaker.  The microphone could be picking that, creating a spill.

I had originally dismissed this possibility, but the two of you convinced me I had prematurely dismissed it and should actually test it. So I did two phone calls where I turned the earpiece speaker volume all the way to zero so that there would be no audio spill except via RF pickup in the earpiece speaker and then producing sound.

On a 4G call (I think it was 4G, but it might have been 3G), there were no problems. The recording was nice and quiet and the frequency comb was not there as seen in the spectrogram below.

[Image: spectrogram_Freja_Nordsiek_2021_06_05_4G...er_off.png]

However, in a call with a worse signal and on 2G, the frequency comb is still there as seen by the spectrogram below.

[Image: spectrogram_Freja_Nordsiek_2021_06_05_2G...er_off.png]

From this, I think there is an issue independent of audio spill. Now, that isn't to say that audio spill couldn't also be a problem with a similar fequency comb and just adding more noise on top. But, there is definitely at least something there that isn't audio spill.

(06-04-2021, 09:26 AM)dsimic Wrote:
(05-25-2021, 11:57 AM)vortex Wrote:
(05-24-2021, 01:28 PM)dsimic Wrote: Edit: I somehow managed to forget mentioning that the proprietary modem firmware can be updated, which you're probably already aware of, so you should check that as well. You can find the instructions, the latest firmware, and the release notes in this repository.  Further information, including the source code of the update utility, can be found in this forum thread

I am familiar with it and looking forward to where the firmware will eventually go, but I am not quite ready to dive down that rabbit hole yet. A lot of things I have to get setup before I can go there.

That all said, that firmware might be able to have some effect on the problem (e.g. use settings that reduce it).

Sorry, I wasn't clear enough...  The above-linked repository contains the latest version of the official, proprietary modem firmware, which is provided by Quectel.  It would be advisable to update the modem firmware to the latest available official version; just have a look at the mile-long update release notes.

I see I misunderstood you. I probed the modem and I am definitely running some version of the EG25GGBR07A08M2G firmware, but it is possible I am not running the very latest version of it. I am going to try to update it to this version for some next tests and see if that does anything. Hopefully I can do this soon, but I have been a bit busy lately.

(06-04-2021, 09:26 AM)dsimic Wrote:
(05-25-2021, 11:57 AM)vortex Wrote: I don't know if the sampling frequency in the modem would have much effect given that the frequency comb is seen at the CPU. But, there is a chance it might due to interactions between the different close components in the CPU's sound unit due to their close proximity electrically.

If everything else fails, it might be worth trying to change the sampling frequency.

Definitely going to try this.

(06-04-2021, 09:26 AM)dsimic Wrote:
(05-29-2021, 10:44 AM)vortex Wrote: I managed to get a wired headset since the store is open now and do a recording with it. I wasn't able to get a very long recording yet (important for getting very good spectrograms) but was able to some preliminary ones.

The bad news is that the problem is still there. The good news is that it is A LOT quieter with the headset. The spectrogram is below. There are a lot more spikes visible in it because the problem is quieter overall (easier to see other spikes). Also, the recording was shorter and that means a noisier looking spectrogram.

This might support my above-described "theory" that an audio spill might be contributing to the issues you're experiencing, because an increased distance between the phone's built-in speaker and the headset's microphone would decrease the spill.  This "theory" could be easily verified by taping up the built-in speaker and using a wired headset to make a test call...  It might be worth trying, if you agree.

When I was doing the headset, it was pretty far away most of the time but was occasionally close. As the spectrograms above show, audio spill can't explain all of the problem. But it could still explain part of it.

(06-04-2021, 09:26 AM)dsimic Wrote:
(06-04-2021, 08:27 AM)Rainer Wrote: I'm not sure if i understand the exact layout of the pinephone audio! On phosh (manjaro-arm beta 10) audio test it sounds like there are 2 speakers on each side, left/right!? Why would there be a speaker on the bottom near the mic? Doesn't this create the echo as the bottom speakers are beside the mic?

There's a single speaker in the PinePhone, as visible in the daughterboard schematic, but for some reason the audio test in Phosh shows the left and right channels.  Actually, the two channels should be mixed into a mono output by the audio codec, and fed to the mono speaker.

The built-in speaker is disabled during phone calls, and the earpiece is enabled.  When the speaker is not disabled, it surely creates an audio spill, as I've described it above.  What happens when the speaker(phone) is activated during a call?  I'm not sure, I haven't tried that. Smile

Putting it in speaker phone mode. Another thing to test.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Phone will not turn on (but sometimes will) insidetrip101 10 4,381 08-18-2023, 04:28 AM
Last Post: spha
  Pine phone main board part Generaltuxenburg 1 918 07-31-2023, 07:50 PM
Last Post: tllim
  No calls on Pine Phone Beta convergence edition polypode 1 1,108 03-06-2023, 08:04 PM
Last Post: rocket2nfinity
  Pine phone USB keyboard connection CleanEnergyCleanEnvironment 1 1,052 02-20-2023, 12:14 AM
Last Post: Kevin Kofler
  I cannot call or receive calls aka0kuro 6 2,902 01-13-2023, 05:31 PM
Last Post: alaraajavamma
Thumbs Down Phone is unresponsive theneedful 14 7,203 08-12-2022, 08:18 AM
Last Post: theneedful
  Phone Dead Already? MarsColonist 4 2,549 08-11-2022, 11:52 AM
Last Post: auanta
  PPKB with phone; phone dies while charging SwordfishII 1 1,293 06-08-2022, 04:14 AM
Last Post: SwordfishII
  Lost internal earpiece Veraendert 3 2,248 02-14-2022, 07:51 AM
Last Post: Veraendert
Shocked Pine phone caught on fire after inserting SDcard majikbear 6 3,476 12-01-2021, 01:34 AM
Last Post: ryo

Forum Jump:


Users browsing this thread: 1 Guest(s)