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..
Related
Up until now I'd always been puzzled by people saying how quiet they found the headphone output of the SGSII and they they wished it was a more normal volume level. Mine had always been plenty loud enough to drown out my Metro ride to work in the morning, even dropped down a notch or two. Yesterday I discovered a possible reason to fit both findings.
I'd been messing with my phone before heading out to work, put in the headphones, sparked up some music and.....quiet. The max volume I could crank out of it with the headphones in must have been about 60% of the normal. Whatever I did, wherever I went in the phone to alter settings and whatever values were showing made no change to push it back up again.
Today I turned the phone on, unlocked it, dropped the headphones in and played the same album and it was the usual 'loud' volume again.
This convinces me that there is a set sequence of actions that causes one quieter volume level to be set as headphone maximum and another that allows a more decent top end. Both findings on volume to this point by others seem to be right.
I'm trying to reproduce the steps (nothing outlandish) which led to my temporary trip to ear-protecting quiet land but have been unable to so far. I'm putting headphones in before and after pushing the volume to max, trying this before or after going into the music app and/or starting the music playing but obviously there are quite a few permutations - all of which are quite normal usage and liable to be done by many people.
I'm posting this so anybody else can also have a mess around and maybe find it before me, helping a few others in the process.
Did you ever find the solution to this?
In addition to the first post I think it is remarkable that you can get different levels of audio output by using different headphones or speakers. Sure all the models available differ a bit but never had such a difference.
settings->sound->volume: 4 sliders there. I once read that sometimes "media" and "incoming call" get mixed up. I sometimes have a really hard time to hear people on the phone using headphones.
I have some problems with my audio in general.
1. In-call volume is very low for me, but it is fine on the other end. I have my volume setting all the way up.
2. When watching videos or listening to music, it will lag very badly and make a weird clicking sound on both speaker and headphones.
Any help is appreciated, thanks.
I have viperXL+ on AT&T
Sent from my HTC One X+ using Tapatalk
Those two issues are unrelated.
The first with the in-call volume has to do with your speaker grill being clogged with dust. It's supposed to be able to be cleaned with a toothbrush. I've also read that wet wipes or some type of tacky silly putty works too. Nothing I do really works perfectly. I took my phone to the store and got a refurb to find the same thing happened a month or two later. Ugh.
Your second issue has to do with the processor not being able to handle the audio processing properly. The clockspeed of the CPU is constantly truing to "step-down" or lower it's frequency to save battery. The CPU's clockspeed is also linked to the GPU. There's something terribly wrong with the way that the processor and it's software are designed. All I can really say to fix that issue is to deal with it. Make sure your OS is stock because it doesn't really happen all that often.
Also, I'm not 100% sure about my second theory, but there isn't really a solution to it right now and I think that's a pretty good reason why.
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.
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
Hello. Picked up an Xperia X a couple months ago and have been generally happy with it, though I'm having some bluetooth issues ranging from annoying to infuriating that are preventing me from really enjoying this phone. Hope some of the gurus here can provide a some guidance on what I can do to fix or workaround these issues.
1. After some period of time listening to music/podcasts/whatever, the phone will automatically drop the volume by half and display the message:
Listening to sounds above the current volume level may permanently damage your hearing.
That's fine and dandy, but I'm controlling the volume through the bluetooth device, and the result is that it drops to a volume so low I can no longer hear it, and while it's a simple thing, it's infuriating every time it happens. Based on prior searches, I know this is a built-in "feature" and I know it's been part of the Xperia phones for a while, but is there any way to disable this behavior? I have my phone rooted, so root-level apps, Xposed modules, etc. are all on the table. This is my number one complaint with the phone, so would really appreciate any help here. Note: to clarify, I want to stop this *behavior*. I've found other discussions about killing similar warning messages, but nothing about how to prevent it from actually lowering the volume.
2. When connected to my car through bluetooth, I don't get metadata from the phone (AVRCP?). Bluetooth problems in general appear to be widely reported for Android 7.1.x on this phone, but most people seem to complain about being unable to pair their device at all. I can pair it fine, but I don't get metadata. However, prior to upgrading to 7.1 (while still on 6.0) metadata worked, and when running OmniROM 7.1.2 on this phone metadata also worked. So, it seems to be a problem with this particular version of the stock ROM for this phone.
Any ideas on how I can fix that? Again, maybe an xposed module or something that I've overlooked? or could I maybe swap out the bluetooth stack from OmniROM, which works fine? This is a much lesser annoyance than the above, but still interested in any suggestions.
3. Finally, this is a more subjective issue, but does anyone else have problems with bluetooth performance in general with this phone? On my last two phones, I kept my phone in my left pocket and played through a bluetooth headphones with the receiver on my right ear with generally no problems, other than the occasional hiccups that seem to affect every android device (at least every one I've used). With the Xperia X, however, trying to play with the phone in my left pocket skips so horribly that it's completely unlistenable. Moving it to my right pocket helps somewhat, but it's still flaky - turning my head sideways such that the receiver is over my shoulder causes skipping. I have to move my phone up into my jacket pocket in order for it to play (mostly) reliably.
Does anyone else have problems like this? Again, I never hard this problem with either of my two previous phones on the same set of headphones (have similar, but not as severe, issues in my car as well). I *did* have this same problem with OmniROM as well, and I have the problem with and without a case, so it seems hardware related, but if the bluetooth hardware was truly this bad I would expect to have seen more discussion about it. So, just wondering - is this just me, or do other people have this problem as well? I know it's unlikely, but any suggestions to improve this? Ie., possible to increase the bluetooth transmitter power or something like that?
Thanks, all. Sorry this turns out a little long, just wanted to properly explain. Looking forward to any suggestions.
I can confirm that on my XX Bluetooth signal is also weak, I have same issues at least with two Sony headsets (SBH60 and SBH80). Also with Bluetooth AptX receiver for my (home) audio it is quite similar, just walking behind corner from direct visibility and audio is choppy...
1. This error message appears very rarely, for me, not every 30 minutes. I have this phone for 1 year now and I encountered the warning 5-6 times.
2. Idk
3. True, Im pretty dissapointed by the bluetooth strenght. Also, the WiFi is super weak too. Very dissapointing.
This also happens on the Tablet Z, where I have external speakers connected. Nannytech run amok.
Replying to old thread, but got just new bluetooth headset and noticed also very poor bluetooth performance on my xperia x. Distance between phone and headset cant exceed half a meter, or music starts stopping and skipping. Even with my ancient backup phone, Iphone 4s, distance can be meters... Very poor desing from Sony.
Bluetooth in general eventually drove me away. Only got midling performance at best, but whatever chip or driver or whatever they were using also had performance issues with custom ROMs. Never found a single ROM not based on stock that worked 100% correctly with bluetooth, and given podcasts and music is probably about 90% of what I use my phone for (combined with Sony ending even security updates long ago at this point), that was a pretty big problem for me.
Ended up buying a Pixel 3a to replace it. My main concern about the 3a is that I wish it was a little bit smaller (really my concern with almost every well-spec'ed phone these days), but the bluetooth in that phone is solid. Longer range and better strength than any other bluetooth device I've ever used. Extremely happy with it.