On 05/11/2016 07:03 PM, H. Nikolaus Schaller wrote:
The handsfree speakers have big distortion (scrachy, clipped). It did have this before as well but I have the impression that it even got worse. I remember our first experiments with the Pandaboard where it did work (I have to set it up again for comparisons).
Hrm, but this is unrelated to this series, right?
Probably yes. I just noticed that it got even worse with the new patches compared to my patch.
So I wonder what else they are doing except enabling the ckobuffer (which my patch also did).
You have distortion when using HPPLL or LPPLL? In both case or only with the HPPLL?
If only with HPPLL, can you try to clk_prepare_enable(twl6040->mclk_clk); right when we get the clock at probe time? Can it be that the HPPLL is not locking because the clock from ckobuffer is not stable yet? If enabling the clock at module probe time helps, then we can try to add delay after enabling the mclk_clk. Optionally we can read the OMAP5 TRM/DM on the ckobuffer timing ;) as last resort, obviously, hehe. I'll check it tomorrow, but it is strange that I don't hear the distortion on the headset or AUX output (omap5-uevm)...
Too high gain for the HF path?
Well, I notice it audibly at any handsfree level above ca. 20% ().
Only handsfree, not on headset?
I can not test HF on OMAP5,
yes, HF it is not available on the omap5evm interface connectors.
But I have built an adapter and speaker setup today for the PandaBoard which has one of the HF channels on a jumper. So I can at least check mono HF.
I remember that, I have omap4-blaze, which have speakers. I might be able to check if it still boots, but again, it is OMAP4.
only the line-out and that sounds OK. Since the Line-out is the same audio signal w/o going through the HF drivers it might be a good idea to see if that also have distortion. If not than the path from HF drivers to the speaker is the one which adds the distortion. Most likely.
The result on the Pandaboard is that it is also distorted, but much less. And it appears that it the scrachy effect is partially coming from the speakers driven to the end of the membrane. I can really see the membrane go in and out at very low frequencies.
Well, this is an effect of the capless Class D amplifier... Other amplifiers would have capacitors with some high-pass effect so that there is no high amplitude at lowest frequencies or DC at all.
On Galaxy Nexus there is zero distortion on the handsfree, so the HW is capable, not sure what we are missing. Galaxy Nexus uses AESS/ABE for audio, but can not recall if this has anything to do with distortion free HF.
But there is still a big difference between PandaBoard and our OMAP5 board. Maybe we really have a HW problem with the twl6040 hookup. There was already one pcb layout bug which was fixed - but either the twl6040 was damaged (and not replaced) or there is another issue (e.g. not enough decoupling capacitor near the twl6040 power rails).
But I can also compare with the PandaBoard schematics.
Probably the omap4-evm (Blaze) schematics will give some hints on how the HF is connected there.
Sometimes I get a data block of random noise... But that might be DMA/interrupt related buffer-underrun, although I do not see any significant messages. Or sox/play has a bug.
Have been playing 4 channel wav with aplay for about an hour and I have not experienced any noise (via line-out + headset), so not sure what could cause it.
Could be the potential hardware problem I mentioned. For example at high energy situations the twl6040 could draw too much current and the DPLL is thrown out of sync. Or something like that.
Or it is a bug in sox. But unlikely because excactly the same mp3 file plays well on the PandaBoard.
sox is good, I was playing mp3 with it for another hour, but did not noticed any noise, distortion. One thing I noticed is that if I give the 'repeat -' parameter to it to loop the song, I will have underruns in ALSA, without the repeat no underruns :o
In my experiments, playing music is done by sox/play:
play somefile.mp3 remix 1 1 2 2
Let me try this.
It is just a trick to get two-channel sound played. I think it would be possible to store the remix result in another file and then simply aplay it.
And I have:
root@letux:~# amixer get "Headset Power Mode" Simple mixer control 'Headset Power Mode',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~# amixer get "PLL Selection" Simple mixer control 'PLL Selection',0 Capabilities: enum Items: 'Low-Power' 'High-Performance' Item0: 'High-Performance' root@letux:~#
Is this ok?
Anyways, setting both to low power/performance has no audible effect.
The HPPLL will give more accurate internal clocks so audio will be more precise and the headset High performance mode gives better dynamic range, it might or might not audible, but I believe with the correct material - not mp3 ;) - there is a difference.
Ok, something for the audiophiles to evaluate :) My job is to make it work at all...
BR and thanks, Nikolaus
BR and thanks, Nikolaus
Regards, Peter ---- Peter Ujfalusi (3): mfd: twl6040: Handle mclk (for HPPLL) via clock API ASoC: twl6040: Select LPPLL during standby ARM: dts: omap5-board-common: Add phandle for mclk clock for twl6040
Tero Kristo (1): ARM: omap5: add support for fref_xtal_ck
Documentation/devicetree/bindings/mfd/twl6040.txt | 4 ++-- arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 10 ++++++++ arch/arm/mach-omap2/control.c | 20 ++++++++++++---- drivers/clk/ti/clk-54xx.c | 1 + drivers/mfd/twl6040.c | 28 ++++++++++++++++++----- include/linux/clk/ti.h | 1 + include/linux/mfd/twl6040.h | 3 ++- sound/soc/codecs/twl6040.c | 12 ++++++---- 10 files changed, 86 insertions(+), 19 deletions(-)
-- 2.8.2
-- Péter