Am 10.12.2019 um 16:10 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Tue, 10 Dec 2019 10:24:03 +0100 hat H. Nikolaus Schaller hns@goldelico.com geschrieben:
Hi,
I guess AESS couldn't be made to work?
We know it can likely work, but we don't know how to do it. If you want to build a kernel without any AESS contaminations, just replace sound/soc/omap/ and sound/soc/ti by upstream code. That should all be code tested by upstream developers and remove the extra audio devices created by our AESS attempt.
Ah, so those extra audio devices that are segfaulting the kernel are actually the ones that try to make use of AESS?
Yes.
So, if I understand it correctly:
- AESS is supported by TI in older kernel versions.
Yes. At least for OMAP4.
- Newer kernel versions don't support it anymore and work on the driver
has been made to fix this.
Yes. But Kernel APIs have changed over time (functions have been renamed, structs have been reordered, macros and constants changed) and nobody from our team did look to really fix issues. I just did keep the compiler from stopping with errors. So it got more and more broken.
- Right now, the driver loads the firmware
Well it tries, but does not find one. Usually it would then fail completely. I have added a hack that it still continues.
and creates these extra audio devices,
I think they are for intermediate stages of the audio pipeline, similar to the image signal processor (ISP) for the OMAP3 camera.
but accessing the these devices leads to a kernel segfault.
Is that correct so far?
Yes.
So what's left is trying to find out why the segfault happens when we try to use the AESS firmware, correct?
There are likely multiple segfaults or other bugs hidden by it.
Has anyone ever tried to compared how an old kernel with AESS works compared to the latest one with crashing AESS?
Probably no, because there is no known kernel tree with working AESS.
We just tried playing some emulation on the Pyra - and PulseAudio needed a whopping 38% CPU power simply to play the audio. aplay with a 32 bit 4 channel 96000Hz wav takes 0.7-1.0% cpu, so it's pretty clear that audio is TOTALLY unusable without hardware mixing. So we NEED to get that working. Does anybody know someone who would be capable of that? Even if he needs to be hired and paid, but sound is unusable at the moment.
Well, I could offer myself since I already have a basic understanding on what AESS and ALSA is about and the data sheets. But I am not the über-specialist for Linux Audio. Just a specialist for fixing bugs. So it needs some time to fill the knowledge gaps by studying code and more data sheets. I stopped voluntarily looking into the audio driver (and TILER) a while ago since I have much higher priority topics. So we are carrying along code where we know it is broken. How fast I can do something depends on the priority you can give a topic by your budget.
Well, I can't spend thousands of EUR if this doesn't lead to any results. But as mentioned multiple times, I have no problems paying someone to fix the remaining issues we still have open.
So if you think it's possible for reasonable time / money, let me know.
Well, the question is what is reasonable. For each unexpected single bug it takes me usually 3 full working days to identify the reasons and work out and test and debug a fix so that it is acceptable upstream. This may include setting up user space code to be able to test something and as a first step tryng to understand what the code did intend to do with an older kernel and search for the newest APIs doing the same effect with different function calls.
I would estimate that there are ca. 5-10 of this type hidden behind the first one leading to a segfault which makes 15-30 hours full time work.
Maybe someone raises his/her finger and does fix it in less time?
BR, Nikolaus