Related
Just noticed an odd very light whirring noise from my headphones when they are plugged into the Evo 3d and the screen is updating.
For example when i turn the screen on and the weather animation on my lock-screen runs, it makes the whirring noise, but when I am on a static home screen it is quiet, but then if i swipe to move to the next screen i hear the light noise again. Same if click on the launcher button to open the app drawer, or click on the phone button on the screen and it opens the dialer.
Wondering if this is a common issue/bug, or if I have a defective unit i need to exchange.
The headphones work perfectly fine in my old phone so it isn't the headphones.
Deetz307 said:
Just noticed an odd very light whirring noise from my headphones when they are plugged into the Evo 3d and the screen is updating.
For example when i turn the screen on and the weather animation on my lock-screen runs, it makes the whirring noise, but when I am on a static home screen it is quiet, but then if i swipe to move to the next screen i hear the light noise again. Same if click on the launcher button to open the app drawer, or click on the phone button on the screen and it opens the dialer.
Wondering if this is a common issue/bug, or if I have a defective unit i need to exchange.
The headphones work perfectly fine in my old phone so it isn't the headphones.
Click to expand...
Click to collapse
I had headphones on for about 40 minutes yesterday morning and didn't notice anything like that at all. Have you tried a different set of headphones?....just to pinpoint in fact that it's a problem with your phone.
I see what you are talking about. The noise is really faint, but I'd say not to worry about it since it may be software related. When browsing apps and what not the sound is gone.
Sent from my PG86100 using XDA App
Damn......just put my headphones on again and still nothing like that. Either my phone's not afflicted or my ears are worse then I thought after to many years working in a factory.
I can hear it too, when I scroll I can clearly hear it. This isn't anything new, I've noticed this sort of thing from other devices. Certain laptops will make a tiny squeal when rapidly scrolling something on the screen with the volume jacked up. We're probably hearing added EMI from the increase in CPU activity. Not much you can do about it. :/
The original Evo used to always make this annoying warbling noise during silence. At times it honestly sounded like faint music almost, it was that pronounced.
ffolkes said:
I can hear it too, when I scroll I can clearly hear it. This isn't anything new, I've noticed this sort of thing from other devices. Certain laptops will make a tiny squeal when rapidly scrolling something on the screen with the volume jacked up. We're probably hearing added EMI from the increase in CPU activity. Not much you can do about it. :/
The original Evo used to always make this annoying warbling noise during silence. At times it honestly sounded like faint music almost, it was that pronounced.
Click to expand...
Click to collapse
Yep, that's a fact of life, when it comes to electronic devices. When it puts out enough power, it'll interfere with the headphones (Which, if you think about it, headphones are just a giant magnifier for electronic pulses. Makes sense)
If you don't believe me, hook up an aux cable to your car stereo, and pinch the end. It'll make a buzzing noise. You're electrically charged enough to play music!
Same thing for the internals of your phone. Doesn't take much. Heck, you could probably set your phone next to an MP3 player that you have your headphones plugged into, and still get some interference.
Thanks for confirming that you can hear it too.
I know what you all are saying about electronics having some EMI, but i went back and compared it to my original Evo, and a friend's iPhone 3GS, and neither of the two gave any background noise because the screen was changing/scrolling etc.
Gotta decide if I want to return it. I love the phone's speed, features etc., and this is definitely a minor thing I am bringing up, but it just bugs me a little.
I also have this noise problem, noticed it right away. I also have a slight cracking sound from the speaker when a loud sound plays. It's odd because normally other devices are able to be placed at max volume without hearing distortion. I'm not ready to return it yet, my roomate got one this morning, and I want to see if his does the same.
My Evo did the same thing, especially worse when I had it plugged in.
Same effect on my phone. I just noticed
last night and thought I was hearing things.
I noticed this right away on my 3D. I never noticed any similar sound on my EVO 4G.
Thankfully, it seems to disappear when I am not interacting with the phone. Therefore, it's not a huge issue for me.
Unlocked my white 32GB after 300 MB download. No issues.
Installed a few apps, nothing special yet, no system related apps.
This afternoon my N9 started ticking from the bottom speaker each time I touch the glass. Just unlocking via pattern does it also.
About 12-15 very quick clicks like a speaker wire is shortening out.
Any hope before I call in a RMA?
B
Sent from my Nexus 5 using Tapatalk
Hi
benwish said:
Unlocked my white 32GB after 300 MB download. No issues.
Installed a few apps, nothing special yet, no system related apps.
This afternoon my N9 started ticking from the bottom speaker each time I touch the glass. Just unlocking via pattern does it also.
About 12-15 very quick clicks like a speaker wire is shortening out.
Any hope before I call in a RMA?
B
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
How loud are these clicks?
It isn't unusual to get quiet clicks and buzzes when using a device, the Nexus 4 for example is a famous for it, it constantly makes a noise if you put your ear to it even when it is sleeping.
The CPU and other components are awake shy. They spend a large amount of time in sleep mode, perhaps coming on for a millilsecond then going off for several milliseconds, then back on at the next touch where it needs to display a nice graphic or do something, then off again. Everytime the CPU switches on, so does a lot of electrical circuitry to drive the power requirements. Currents switching on and off flowing through wires creates noise, either audible directly, like the hum from a kettle or a buzz from a power supply, or via electrical noise that is picked up by other circuits, for example the amplifier for the sound, which then makes it audible. Almost every electronic device if you put your ear to it makes a noise and buzzes, often changing in tone when you make it do something.
So I would say if it is very quiet, only audible in a quiet room when near to the tablet, it's is probably just normal operating noise. You might find a replacement is quieter, or you may find it is louder. You may find someone else can't hear it at all, if you are young you are more likely to hear these things than someone who is older as we lose high frequency hearing as we get older, and listening to loud music in headphones makes it happen quicker
Of course if it is pretty loud, audible all the time and annoying, certainly go for a replacement.
Regards
Phil
Just wanna make sure, but you are not talking about the button touch sound on Android 5.0 are you? The sound has been changed to a very swooshing sound that almost sounds like static on an audio line.
Thank you guys for your input.
The sounds I observed were loud, not the near silent hum kind. More like a finger nail is hitting a window.
The sound got progressively louder during my trouble shooting.
It ended up in a total distorted, muffled tone coming from the bottom speaker.
Something inside shortened out.
I had a micro-Tesla conductivity meter this morning at my bench and I could see that by touching the screen even at the top it induced a small current directly at the bottom speaker.
I called an RMA and the N9 was declared DOA.
Replacement is in the mail.
B
benwish said:
Thank you guys for your input.
The sounds I observed were loud, not the near silent hum kind. More like a finger nail is hitting a window.
The sound got progressively louder during my trouble shooting.
It ended up in a total distorted, muffled tone coming from the bottom speaker.
Something inside shortened out.
I had a micro-Tesla conductivity meter this morning at my bench and I could see that by touching the screen even at the top it induced a small current directly at the bottom speaker.
I called an RMA and the N9 was declared DOA.
Replacement is in the mail.
B
Click to expand...
Click to collapse
When you called what did you tell them? Where did you get it from? I got mine from best buy, and have this same problem. I think I'm going to wait until its closer to my 14 day period... Maybe I'll get a second batch device.
Sent from my Nexus 9 using XDA Free mobile app
Not me. The ticking sound was the first thing I listened for when was testing out the speakers. I didn't hear anything out of the ordinary.
Took me awhile to be sure though cuz the song i used to test actually did have occasional ticks in it. I had to relisten to it on my headphones and on my home theather system to be sure it was just the song and it was.
eorsini said:
When you called what did you tell them? Where did you get it from? I got mine from best buy, and have this same problem. I think I'm going to wait until its closer to my 14 day period... Maybe I'll get a second batch device.
Click to expand...
Click to collapse
I told them just my findings. Repeated click sounds by touching screen from a single speaker. This was a direct Google order and they sent a replacement within 24 h's. No questions asked.
The new White N9 is perfect. No unusual click sounds. In addition to that, there is a little less light bleed and from the few hours I used it so far I get the feeling that the battery is lasting a good bit longer. The first N9 went from 100% to about 40% within 3 h's of trouble shooting, the replacement is still at 75% after I unlocked & rooted and put back all my files, about 2.5 h#s screen-on-time. Makes sense, since the constant shortening out the speaker uses electricity.
The serial number difference of the last 4 numbers is a 44 higher count number, so I believe its the same batch/lot.
Overall, a quick and painless exchange and Google's RMA process is one of the fastest and easiest I have gone through.
Is anyone else getting a slight "crackle" when doing things with the device?
While my device isn't doing it all of the time, the speaker will occasionally randomly crackle/pop when playing a brief sound (such as the sound made while tapping app icons or adjusting the volume).
Doesn't seem to do it when there's an actual constant sound playing though, which is pretty odd =/
I heard a crackle/pop on a display model at bestbuy. I hope its not a problem on all of them.
Robert542 said:
I heard a crackle/pop on a display model at bestbuy. I hope its not a problem on all of them.
Click to expand...
Click to collapse
I was beginning to wonder if I was the only one haha.
This sort of problem seems more indicative of a voltage issue than an actual speaker issue though at least, which means it could be fixed in an update if it is a widespread problem.
It reminds me of a problem I had with another device that was more or less fixed by either changing the governor or increasing minimum voltage.
Welp, my thread got moved here and this forum is pretty much a graveyard. If anybody else has this issue and happens to figure out how to fix it, please PM me, as I won't be bothering to check this thread.
As near as I can tell, it only ever happens while it's USB-attached to a PC (in my case, a Mac laptop).
Mine crackles for a few seconds every time I open the camera app. Didn't start out that way. Want to say it started about a couple weeks after I got the phone. Maybe after an update but not sure. Everything works so I've just ignored it.
Hi NeoRage. Am getting the same problem (crackling when opening the camera) - did the problem go away?
I have the issue too. S6 Edge I noticed it when editing my contacts, it cant be good that electricity is arcing someplace! but like someone else said, it keeps working so... I don't know if it coincided with Marshmallow but it was right in that same timeframe.
Lately I've been digging into the speaker amps to see if I could resolve some of the complaints I've had with them. These chips don't seem to have any detailed information anywhere so I thought I'd document my findings here in hopes that it may be useful to others and more information might come to light.
NXP has a couple pdfs with a basic overview of the chip here: TFA9890_SDS.pdf, TFA9890A_SDS.pdf
No idea what the difference is between "TFA9890" and "TFA9890A", but the A rev PDF has some more details to it at least.
Kernel drivers for the TFA chips have been hard to find, and there's no "standard" driver.
1. Motorola seems to have written their own in-house kernel driver for it which is in the shamu kernel of course. It appears to have originated from the Moto X ("ghost") kernel, and it is by far the cleanest looking and most legible driver I've found.
2. Sony has a very ugly looking driver. They do have the registers documented the best I've seen so far though.
3. OnePlus has another odd-looking driver, this one has NXP copyright headers on it but seems to be related to the Sony one.
Problem Solving
One issue I had with the amps was how the volume cut way back when the battery voltage dropped below a certain point. I'm not talking just the gradual drop-off that happens as the battery voltage lowers over time (which is understandable), I'm talking the volume all of a sudden being halved. It turns out this is a feature of the amp:
"By limiting the supply current when the battery voltage is low, it prevents the audio system from drawing excessive load currents from the battery, which could cause a system undervoltage."
This happens by default at 3.53V. I was surprised to find that the Nexus 6 pushes the battery voltage enough for 3.53V to not only be reached, but surpassed, to as low as 3.0V. There's no way in hell the amps are powerful enough to cause a half-volt drop.
Adjusting the protection voltage level resolves this annoyance. For details, see register 0x05.
NOTE: With the Marshmallow update, the "Empty Learning Feature" of the MAX17042 battery gauge chip was enabled, and for some reason this isn't letting the battery drop to voltages as low as it previously did. So to users it may now seem like the speaker volume @ low battery issue is improved, but it's really due to what was once "35%" battery now being more like "15%".
Lately I've ran into an issue with the amps being more aggressive than they used to be with limiting the volume output. Not sure what's going on, but it started after missing an alarm for 20 minutes which was eventually interrupted by an incoming phone call. I wonder if something happened with the transition between the equalizer preset things that caused damage to the amp or speaker somehow. For the first day after this started, playing music at anywhere over 45% volume resulted in instant "volume throttling", and the more I turned it up the worse it got, eventually so bad that I couldn't hear a damn thing from the bottom speaker at all and barely heard the top one. A few days later this has greatly improved, but it's still not like it was when I got my N6.
Driver Comparison/Analysis
The Sony and OnePlus drivers disable clock gating when resetting the DSP, Moto's does not;
https://github.com/CyanogenMod/andr...c/sound/soc/codecs/tfa/src/initTfa9890.c#L107
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L289
The Sony and OnePlus drivers set some PLL registers for "optimal amplifier behavior", Moto's doesn't appear to do so;
https://github.com/CyanogenMod/andr...b4cfc/sound/soc/codecs/tfa/src/Tfa98xx.c#L273
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L617
Based on ghost's tfa9890 driver commit history, it seems like this might be taken care of with the firmware patches.
https://github.com/CyanogenMod/andr...mmit/892ac7150aba33e73837e3c713812599ba004355
https://github.com/CyanogenMod/andr...mmit/63fdeaa3c79a765f1c04f4b51c71cbb217db6707
https://github.com/CyanogenMod/andr...mmit/1ac301a19efb69f3d466fc53c6880db886409be3
https://github.com/CyanogenMod/andr...mmit/058e87a8128c233d02dff5290b23f3be0c5e86c9 (Note PLL freq/div info here)
The Sony and OnePlus drivers do some weird stuff with register 0x84 (undocumented, related to "MTP" stuff).
https://github.com/CyanogenMod/andr...fc/sound/soc/codecs/tfa/src/initTfa9890.c#L78
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L276
The OnePlus driver even tries to "recover" if 0x84 is empty. It's quite aggressive about it, you'll find it checked in numerous places.
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L812
The OnePlus driver ignores SWS and SPKS status flags in the monitor function.
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa98xx.c#L284
The main tfa98xx.c file in the OnePlus driver has some minor similarities to the Motorola driver.
Registers
0x00: Status
0x04: I2S Config
0x05: Battery Protection
-- Dropping the ProtectionThreshold (BSST) to 5 (3.23V) is more reasonable for shamu than the default of 8 (3.53V).
0x06: Audio Control
0x07: DCDC Boost
-- Moar voltage, anyone? (DCVO)
0x08: Speaker Calibration
0x09: System Control
0x0A: I2S Select
0x0C: Voltage Sense Config
Few other things that I haven't yet verified if the documentation matches up with the TFA9890:
0x41: PWM Mute Set
0x48: CurrentSense 3
0x49: CurrentSense 4
Note that the Motorola driver does mess with 0x46 through 0x49, but the values don't seem to line up with this file.
TODO
1. Try to dump and document more registers.
2. Figure out how the various eq/config/preset files work.
3. Why does fading sound all the way to one direction still seem to play through both speakers?
4. Can we speed up the channel swapping that occurs upon rotation?
science. This is awesome man.
I wouldn't normally post here but...
It appears that the accelerometer or screen rotation seems to also trigger volume throttling...
And prolonged sound at low battery (racing game) seems to cause problems too...
However... Above 80% battery on the fuel gauge and none of these issues appear
Sent from my Nexus 6 using Tapatalk
rignfool said:
I wouldn't normally post here but...
It appears that the accelerometer or screen rotation seems to also trigger volume throttling...
And prolonged sound at low battery (racing game) seems to cause problems too...
However... Above 80% battery on the fuel gauge and none of these issues appear
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
These are interesting observations, and you're spot on with the screen rotation problem.
Screen rotation basically resets the TFA9890 chips to swap the L&R channels, and as a result the chips lose their state about how they were 'volume throttling' previously. The thing that's supposed to make these chips safe for the speakers is they constantly make sure the volume stays low enough not to damage the speakers, but when the chips are reset like that the volume goes back to full bore momentarily and that could very well damage the speakers and make the amps get overtly protective.
I've been able to get in contact with somebody that has worked on the TFA9890. I'm not sure how much they'll be able to share with me (or how much I'll be able to share here), but from what I'm hearing so far the biggest difficulties with the chip is software.
MWisBest said:
I've been able to get in contact with somebody that has worked on the TFA9890. I'm not sure how much they'll be able to share with me (or how much I'll be able to share here), but from what I'm hearing so far the biggest difficulties with the chip is software.
Click to expand...
Click to collapse
Interestingly enough... After about 12 months with the noticeable volume throttle... I switched to leankernel... And cannot get the volume to throttle... @Imoseyon has no idea what he would/could have done to fix it...
The only difference on my end... Would be that I am back to using mpdecision...
Any thoughts?
rignfool said:
Interestingly enough... After about 12 months with the noticeable volume throttle... I switched to leankernel... And cannot get the volume to throttle... @Imoseyon has no idea what he would/could have done to fix it...
The only difference on my end... Would be that I am back to using mpdecision...
Any thoughts?
Click to expand...
Click to collapse
I'm not at all surprised to hear something like this happen. These chips are THAT weird.
One suggestion for others having issues with volume throttling (sometimes referred to as "automatic gain control" (AGC)): try to force a recalibration of the speaker impedance detection.
To do this, just run the following commands (as root):
Code:
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0034/force_calib
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0035/force_calib
And then reboot.
If the calibration is off for some reason, it can screw up the calculations for AGC.
MWisBest said:
I'm not at all surprised to hear something like this happen. These chips are THAT weird.
One suggestion for others having issues with volume throttling (sometimes referred to as "automatic gain control" (AGC)): try to force a recalibration of the speaker impedance detection.
To do this, just run the following commands (as root):
Code:
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0034/force_calib
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0035/force_calib
And then reboot.
If the calibration is off for some reason, it can screw up the calculations for AGC.
Click to expand...
Click to collapse
So your on the n6 off the gnex. What does the calibration actually do?
Sent from my Nexus 6 using Tapatalk
---------- Post added 17-12-2015 at 12:08 AM ---------- Previous post was 16-12-2015 at 11:55 PM ----------
MWisBest said:
I'm not at all surprised to hear something like this happen. These chips are THAT weird.
One suggestion for others having issues with volume throttling (sometimes referred to as "automatic gain control" (AGC)): try to force a recalibration of the speaker impedance detection.
To do this, just run the following commands (as root):
Code:
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0034/force_calib
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0035/force_calib
And then reboot.
If the calibration is off for some reason, it can screw up the calculations for AGC.
Click to expand...
Click to collapse
Have you seen this
https://youtu.be/oaUtrpALyi8
Sent from my Nexus 6 using Tapatalk
bryantjopplin said:
What does the calibration actually do?
Click to expand...
Click to collapse
The TFA9890 has a DSP on it, which is (at least partially) responsible for the Automatic Gain Control function. The speaker impedance is used as part of the calculations for it. I would assume at the very least it is used for Ohm's law. I find it interesting that the speakers are spec'd at 8Ω, yet the impedance the DSP is reading can be more like 6Ω or 7Ω.
bryantjopplin said:
Have you seen this
https://youtu.be/oaUtrpALyi8
Click to expand...
Click to collapse
No, but it's nothing I'm not already familiar with.
rignfool said:
Interestingly enough... After about 12 months with the noticeable volume throttle... I switched to leankernel... And cannot get the volume to throttle... @Imoseyon has no idea what he would/could have done to fix it...
The only difference on my end... Would be that I am back to using mpdecision...
Any thoughts?
Click to expand...
Click to collapse
Have You noticed anything in the kernel that is preventing volume throttle. I am no expert but based on a previous post and 'software' being the difficult aspect of this chip. Maybe it's code that is causing volume throttling.
Would comparing the lean kernal and stock kernal make a difference.
I am highly interested in this thread. I would like to avoid getting a dac/amp external solution if the internal solution will do
Just a little note, there is definitely something up with Alarms that can cause these chips to basically malfunction (at least with my N6).
Today was the fourth time I have tried using my Nexus 6 as an alarm clock, and three of these four times (including this one) have resulted in the AGC acting incredibly stupid, usually lasting about a week. Any music that has even the slightest amount of bass will trigger AGC at as little as 1/4 volume. Nothing makes it past 1/2.
I have tried dumping every damn register when this happens, and then compared it to a register dump when everything works fine, and there's no discernible difference.
My theory is that it may have something to do with what is played for the alarm, at what volume, and for how long.
The one time when this did not happen after using an Alarm, was when I used one of the default alarm tones. The three times alarms did cause the AGC malfunctions were with a fairly heavy rock song with plenty of drums and stuff in it.
Maxed out Alarm volumes can easily cause the amps to clip, regardless of what tone is played. (This is even before the AGC issues start)
I never hear an alarm right away. It usually takes me at least 15 minutes or so to wake up to an alarm.
The amps have different configs applied depending on what is being played through the speakers: music, ringtone, and voice. If Alarms are played with the "ringtone" configuration somehow, it may very well damage the speakers or amplifiers depending on the three things listed above.
Bottom line: if you're a very heavy sleeper like me, I highly suggest avoiding using the Nexus 6 as an alarm clock.
MWisBest said:
Just a little note, there is definitely something up with Alarms that can cause these chips to basically malfunction (at least with my N6).
Today was the fourth time I have tried using my Nexus 6 as an alarm clock, and three of these four times (including this one) have resulted in the AGC acting incredibly stupid, usually lasting about a week. Any music that has even the slightest amount of bass will trigger AGC at as little as 1/4 volume. Nothing makes it past 1/2.
I have tried dumping every damn register when this happens, and then compared it to a register dump when everything works fine, and there's no discernible difference.
My theory is that it may have something to do with what is played for the alarm, at what volume, and for how long.
The one time when this did not happen after using an Alarm, was when I used one of the default alarm tones. The three times alarms did cause the AGC malfunctions were with a fairly heavy rock song with plenty of drums and stuff in it.
Maxed out Alarm volumes can easily cause the amps to clip, regardless of what tone is played. (This is even before the AGC issues start)
I never hear an alarm right away. It usually takes me at least 15 minutes or so to wake up to an alarm.
The amps have different configs applied depending on what is being played through the speakers: music, ringtone, and voice. If Alarms are played with the "ringtone" configuration somehow, it may very well damage the speakers or amplifiers depending on the three things listed above.
Bottom line: if you're a very heavy sleeper like me, I highly suggest avoiding using the Nexus 6 as an alarm clock.
Click to expand...
Click to collapse
This amplifier is such a pain in the butt. Thanks for letting me know about the alarm. I think my alarm didn't go off once or twice in the past. I wonder if using a regular simple ring tone will offset the issue
I've never had a problem with the alarm...But I do use the default alarm tone.
Bumping this in hopes there's been some sort of fix.
Fuzzy13 said:
Bumping this in hopes there's been some sort of fix.
Click to expand...
Click to collapse
The best that I have come up with...
Is to run as bone stock a kernel as possible...
We are truly looking for one that still has the 3 second boost for mpdecision... Factory stock... Pure Nexus... One of those...
And... For added flavor... ARISE sound mod smooths everything out...
However... There is nothing you can do when BCL hits... Your volume will drop...
I'm currently experimenting with the thermal-engine config file and gonna see if throttling at higher battery stops the acute voltage drops that I guess causes the speakers to go quiet...
If anyone is still working on this, I've found a bit of code that looks interesting.
https://github.com/PureNexusProject...b/android-7.1/sound/soc/codecs/tfa9890.c#L783
I've omitted this bit of code, compiled and sound still seems to be working. Might be placebo, but sound seems *a tad bit* louder, but volume deterioration at certain battery levels still in effect.
Any suggestions? What other files can be looked into?
MWisBest said:
Lately I've been digging into the speaker amps to see if I could resolve some of the complaints I've had with them. These chips don't seem to have any detailed information anywhere so I thought I'd document my findings here in hopes that it may be useful to others and more information might come to light.
NXP has a couple pdfs with a basic overview of the chip here: TFA9890_SDS.pdf, TFA9890A_SDS.pdf
No idea what the difference is between "TFA9890" and "TFA9890A", but the A rev PDF has some more details to it at least.
Kernel drivers for the TFA chips have been hard to find, and there's no "standard" driver.
1. Motorola seems to have written their own in-house kernel driver for it which is in the shamu kernel of course. It appears to have originated from the Moto X ("ghost") kernel, and it is by far the cleanest looking and most legible driver I've found.
2. Sony has a very ugly looking driver. They do have the registers documented the best I've seen so far though.
3. OnePlus has another odd-looking driver, this one has NXP copyright headers on it but seems to be related to the Sony one.
Problem Solving
One issue I had with the amps was how the volume cut way back when the battery voltage dropped below a certain point. I'm not talking just the gradual drop-off that happens as the battery voltage lowers over time (which is understandable), I'm talking the volume all of a sudden being halved. It turns out this is a feature of the amp:
"By limiting the supply current when the battery voltage is low, it prevents the audio system from drawing excessive load currents from the battery, which could cause a system undervoltage."
This happens by default at 3.53V. I was surprised to find that the Nexus 6 pushes the battery voltage enough for 3.53V to not only be reached, but surpassed, to as low as 3.0V. There's no way in hell the amps are powerful enough to cause a half-volt drop.
Adjusting the protection voltage level resolves this annoyance. For details, see register 0x05.
NOTE: With the Marshmallow update, the "Empty Learning Feature" of the MAX17042 battery gauge chip was enabled, and for some reason this isn't letting the battery drop to voltages as low as it previously did. So to users it may now seem like the speaker volume @ low battery issue is improved, but it's really due to what was once "35%" battery now being more like "15%".
Lately I've ran into an issue with the amps being more aggressive than they used to be with limiting the volume output. Not sure what's going on, but it started after missing an alarm for 20 minutes which was eventually interrupted by an incoming phone call. I wonder if something happened with the transition between the equalizer preset things that caused damage to the amp or speaker somehow. For the first day after this started, playing music at anywhere over 45% volume resulted in instant "volume throttling", and the more I turned it up the worse it got, eventually so bad that I couldn't hear a damn thing from the bottom speaker at all and barely heard the top one. A few days later this has greatly improved, but it's still not like it was when I got my N6.
Driver Comparison/Analysis
The Sony and OnePlus drivers disable clock gating when resetting the DSP, Moto's does not;
https://github.com/CyanogenMod/andr...c/sound/soc/codecs/tfa/src/initTfa9890.c#L107
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L289
The Sony and OnePlus drivers set some PLL registers for "optimal amplifier behavior", Moto's doesn't appear to do so;
https://github.com/CyanogenMod/andr...b4cfc/sound/soc/codecs/tfa/src/Tfa98xx.c#L273
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L617
Based on ghost's tfa9890 driver commit history, it seems like this might be taken care of with the firmware patches.
https://github.com/CyanogenMod/andr...mmit/892ac7150aba33e73837e3c713812599ba004355
https://github.com/CyanogenMod/andr...mmit/63fdeaa3c79a765f1c04f4b51c71cbb217db6707
https://github.com/CyanogenMod/andr...mmit/1ac301a19efb69f3d466fc53c6880db886409be3
https://github.com/CyanogenMod/andr...mmit/058e87a8128c233d02dff5290b23f3be0c5e86c9 (Note PLL freq/div info here)
The Sony and OnePlus drivers do some weird stuff with register 0x84 (undocumented, related to "MTP" stuff).
https://github.com/CyanogenMod/andr...fc/sound/soc/codecs/tfa/src/initTfa9890.c#L78
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L276
The OnePlus driver even tries to "recover" if 0x84 is empty. It's quite aggressive about it, you'll find it checked in numerous places.
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa_dsp.c#L812
The OnePlus driver ignores SWS and SPKS status flags in the monitor function.
https://github.com/OnePlusOSS/andro...5.1.1/sound/soc/codecs/tfa9890/tfa98xx.c#L284
The main tfa98xx.c file in the OnePlus driver has some minor similarities to the Motorola driver.
Registers
0x00: Status
0x04: I2S Config
0x05: Battery Protection
-- Dropping the ProtectionThreshold (BSST) to 5 (3.23V) is more reasonable for shamu than the default of 8 (3.53V).
0x06: Audio Control
0x07: DCDC Boost
-- Moar voltage, anyone? (DCVO)
0x08: Speaker Calibration
0x09: System Control
0x0A: I2S Select
0x0C: Voltage Sense Config
Few other things that I haven't yet verified if the documentation matches up with the TFA9890:
0x41: PWM Mute Set
0x48: CurrentSense 3
0x49: CurrentSense 4
Note that the Motorola driver does mess with 0x46 through 0x49, but the values don't seem to line up with this file.
TODO
1. Try to dump and document more registers.
2. Figure out how the various eq/config/preset files work.
3. Why does fading sound all the way to one direction still seem to play through both speakers?
4. Can we speed up the channel swapping that occurs upon rotation?
Click to expand...
Click to collapse
Very interesting documentation, I M a nexus 6 user since yesterday and I noticed this problem since I first tested audio with a song in YouTube , expecting for great udio performance, but let down in the end... Wish there would be some way to bypass this stupid limitation or bug. I'm a technician , so in some way maybe I could help a little bit to test
MWisBest said:
I'm not at all surprised to hear something like this happen. These chips are THAT weird.
One suggestion for others having issues with volume throttling (sometimes referred to as "automatic gain control" (AGC)): try to force a recalibration of the speaker impedance detection.
To do this, just run the following commands (as root):
Code:
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0034/force_calib
echo 1 > /sys/bus/i2c/drivers/tfa9890/8-0035/force_calib
And then reboot.
If the calibration is off for some reason, it can screw up the calculations for AGC.
Click to expand...
Click to collapse
This incredibly improved my nexus 6 audio of at least 50℅ , I couldn't go over half volume that AGC started to cut volume to a stupid low point. Now I can stay at max with no problem
Kinda related. If you build from AOSP right now, it seems that the AGC is extremely strong. Hit about 25% volume and it never gets any louder past that. Same with speakerphone on calls. Been tearing my hair out trying to figure this out since the OTA works fine and other ROMs on 7.1.1 work fine too.
GrayBoltWolf said:
Kinda related. If you build from AOSP right now, it seems that the AGC is extremely strong. Hit about 25% volume and it never gets any louder past that. Same with speakerphone on calls. Been tearing my hair out trying to figure this out since the OTA works fine and other ROMs on 7.1.1 work fine too.
Click to expand...
Click to collapse
agree..
i wish there is some solutions for this problem..
For anyone that can hear white noise when listening to audio through the headphone jack at lower volume levels, there is an easy solution to this.
You must be rooted and have a custom kernel installed (I use ElementalX and this works for me).
In a kernel editor app or the one provided with the kernel, go into sound settings and reduce the gain level of the headphones from the stock level of around 20 to -20, this will reduce the maximum volume a bit, but it gets rid of 100% of the white noise.
Good luck!!!
This worked (so far, at least) on my Nexus 5X, too. Thanks for this! Had been really bothering me.
For me, this changed the sound to just the left headphone. However, I somehow magically fixed it. Maybe the combination of switching kernels or something. But I no longer get the crackling at all.
Sent from my Nexus 6P using Tapatalk
Been looking everywhere for a solution, surprised this post has so few views/replies considering how many people seem to have the same problem.
I was on the verge of doing an RMA when I found this post. This definitely works. The white noise goes away at all levels (even the lowest volume setting, though with the gain set so low you can't even hear certain tracks with it at the lowest setting). The issue of of the audio being super noisy and abruptly cutting in/out during quiet/silent moments in audio when at low volume is fixed too.
I can't say I'm not a little bummed out that the defect is technically still there and this is just a workaround. Not to mention max volume gets lowered by a lot, but I'm a quiet listener anyways.
Sucks to need to go through all this just to have the phone work the way it should.
Thanks for the solution!
Keywords for people searching for a solution since it took me so long to find this post: white noise, static, crackle, low volume, headphone audio