Am 31.07.2020 um 18:28 schrieb Michael Mrozek EvilDragon@openpandora.org:
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.
These are only the longterm / stable kernels. There have been many versions in between.
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.
There is an archive of all (well almost all) versions that did exist:
letux-4.8.11/ 2016-11-28 10:01 - letux-4.9-rc6-lpae/ 2016-11-22 07:55 - letux-4.9-rc6/ 2016-11-21 19:52 - letux-4.9-rc5-lpae/ 2016-11-14 17:27 - letux-4.9-rc5/ 2016-11-14 14:45 - letux-4.9-rc4/ 2016-11-07 10:41 - letux-4.9-rc3/ 2016-10-30 17:26 - letux-4.9-rc2/ 2016-10-24 10:31 - letux-4.8.4/ 2016-10-22 15:57 - letux-4.8.3/ 2016-10-21 12:46 - letux-4.9-rc1/ 2016-10-16 23:08 - letux-4.8.1/ 2016-10-08 10:12 - letux-4.8/ 2016-10-03 10:45 - letux-4.8-rc8/ 2016-09-26 10:17 - letux-4.8-rc7/ 2016-09-21 12:46 - letux-4.8-rc6/ 2016-09-12 11:33 - letux-4.8-rc1/ 2016-08-11 15:03 - letux-4.7/ 2016-07-27 16:46 - letux-4.7-rc7/ 2016-07-11 10:47 - letux-4.7-rc6/ 2016-07-06 14:07 - letux-4.7-rc5/ 2016-06-27 15:35 - letux-4.7-rc4/ 2016-06-20 15:08 - letux-4.7-rc3/ 2016-06-13 09:23 - letux-4.7-rc2/ 2016-06-08 10:21 - letux-4.7-rc1/ 2016-06-01 01:02 - letux-4.6/ 2016-05-31 23:05 - letux-4.6-rc6/ 2016-05-02 12:35 - letux-4.6-rc5/ 2016-04-25 16:44 - letux-4.6-rc4/ 2016-04-18 19:04 - letux-4.6-rc3/ 2016-04-13 22:41 - letux-4.6-rc2/ 2016-04-08 00:50 - letux-4.5/ 2016-03-30 20:59 - letux-4.5-rc2/ 2016-02-02 12:12 - letux-4.4/ 2016-01-11 11:53 - letux-4.4-rc8/ 2016-01-04 11:28 - letux-4.4-rc5/ 2015-12-21 10:16 -
So most likely it could have been letux-4.7 since it has the same date as the video.
Well, we have to check if that old kernel is still running with user-space or has some dependencies.
The kernel tree is here:
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux-...
There seems to be a device tree for the pyra - but that is for one of the first prototypes (V5.0) only:
https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=arch/arm/boot/dts/oma...
What is quite sure is that it was a 2GB RAM processor and not built as LPAE (that started with 4.9 builds).
Making this setup work again on modern hardware is a quite big task.
It would also be good to backport some recent findings (like making "reboot" work). And the most challenging part is to backport the device tree to support the mass production hardware.
Another issue is that I do not know what u-boot we did use.
That means that the kernel used in this video was most probably a 3.12.x one.
No, I think we never had a 3.12 working on the Pyra. The first V5.0 boards were produced end of 2015. And V5.1 boards were ordered in July 2016.
On 3.12, AESS was still supported and working.
But we never had AESS working. AESS probably will not help since it is more a sound signal processor, mixer, equalizer, echo canceller. It can't solve PCM communication issues and relies on stable McPDM communication. Unless it works around a hardware bug in the omap5 by good luck.
But generally you are right, I also remember that there were kernels without this scratchy effect and it creeped in sometimes (and disappeared in later kernels until David tried to run the rumble in parallel).
Ah, I also had once connected a "big" 8 Ohm speaker to the handsfree output and there, sound was perfect. Which we took as indication that the speakers or how they are mounted is not perfect.
So it still might be a software issue (but AESS is IMHO not part of the solution).
Or we were simply lucky with those first V5.0 prototypes.
BR, Nikolaus
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.
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org