Okay... now the only thing to explain is: How do you fit 200 hours into 3 full working days :D
On 10 December 2019 21:40:51 CET, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 10.12.2019 um 16:48 schrieb H. Nikolaus Schaller
Am 10.12.2019 um 16:10 schrieb Michael Mrozek
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.
Sorry, that was a wishful miscalculation... 3 full working days with 5-10 such issues is ca. 100 - 200 hours.
Maybe someone raises his/her finger and does fix it in less time?
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel