Am Fri, 31 Jul 2020 15:38:50 +0100 hat David Shah dave@ds0.me geschrieben:
And now for some more weirdness in this regard: https://www.youtube.com/watch?v=BZcFnunrVGw
This video has been recorded July 2016, using the Letux OS that was available back then.
I know the speakers were physically overdriving when going higher than 75% (no sealing yet), but I can't remember that they ever glitched. And at least on this video, they were running fine on 75% volume...
It COULD be they had the issue back then and I simply forgot - but I think it simply didn't happen back then.
Question is: What kernel version did that use? On the Letux GIT I can see that we had 3.12.x and as next kernel 4.9.x.
I'm not sure if that means Letux didn't have any 4.x kernel before 4.9.x (Nikolaus, that's a question for you to answer :))
4.9 was released December 2016 - so after that video.
That means that the kernel used in this video was most probably a 3.12.x one.
On 3.12, AESS was still supported and working.
It is really looking like the OMAP5, or possibly TWL is _very_ sensitive to noise on the McPDM interface.
- My previous loopback experiment was not correct for some reason (I
think ALSA was recording from the wrong device). I tried again this time looking at the raw data coming back via McPDM and indeed the data coming back is corrupted when the audio output is corrupted.
- I tried deliberately glitching the ABE_CLKS signal (from TWL to
OMAP) on the uEVM deliberately by touching it with some tweezers to inject noise and capacitance - it is easily exposed by the inverter footprint. This causes the audio to fail in exactly the same way as the Pyra. Also identically to the Pyra, disabling uplink in the OMAP fixes the problem.
Checking the signal with an oscilloscope, the clock signal does not change during while the audio is glitching after the tweezers are removed. Sadly there is no easy access to the other McPDM signals.*
The only question now is whether there is a less drastic way to 'desensitize' it other than disabling uplink.