On Fr, 2017-11-24 at 14:22 +0200, Peter Ujfalusi wrote:
Hi,
as this is a critical issue (unless we want to burn a lot of CPU power just for the audio mixing):
Is this still being worked on?
We've got a few more devs interested in helping out now, is there something they can help here with?
Thanks!
Andrey,
On 2017-11-24 01:14, Andrey Utkin wrote:
On Wed, Oct 25, 2017 at 02:03:30PM +0300, Peter Ujfalusi wrote:
On 2017-10-08 16:35, Andrey Utkin wrote:
It seems that successful compilation is quite close, I have just one fatal compilation issue currently:
snd_soc_platform_driver from AESS sources has .read, .write callbacks pointing to omap_aess_oppwidget_{read,write}(), but in current sound drivers structure, these callbacks are defined only for snd_soc_codec_driver. Then, I can't make sense of "oppwidget" as codec. So, please help me to resolve my confusion.
As far as I can see they serve the same purpose, to configure the firmware (widgets, features, controls in the firmware). All of these need to be mostly rewritten to soc-topology, the thing asoc-fw did need to be done with the new soc-topology tools to create the new firmware.
Peter,
I tried many times to think of any plan to tackle this, but the best plan so far is "make Peter to do as much as possible".
;)
It is obvious that there's a lot to know about this hardware and existing firmware. What I've done here so far is a coding monkey job, and I really don't possess a fraction of knowledge you have.
What about, say, arbitrary amount of beer to motivate you to help with the rest of this task? Please let me know what you would accept.
Beer is good :D If we bump to each other we could have few for sure...
What would be great is to have a clear framework to proceed. With hints being that high-level as what you've suggested above, I feel lost. I would need to spend a lot of time before I make sense of how to proceed, and this causes me to procrastinate on this every time.
I should not have given up after 3.16, back then I was overwhelmed with other stuff and never got the time to move things forward. There are several things I did not liked about the code, that's why I went to try to clean it up a bit and re-arrange it for the better. We would be in better shape with smaller steps than the state we are where we need to make big change.
But the good thing is that we can as well start from a blank page, don't we? Or do we want backwards compatibility for Android, ubunutu or some other distro which had AESS/ABE support?
If we try to make everything working I'm sure it will fail in unpredictable ways, so I would scrap things a bit and go step by step. First get HS playback working, then HS low power, then add HF playback followed by LP mode. After that work our way top get capture working. One feature after another.
The main issue is that we need to develop the firmware wrapper and the driver at the same time.
I also think that we might not need to roll the current complexity of the driver as the core evolved a lot and it might take some of the burden from the low level.
The first ting is for sure is to work on the firmware itself to wrap it in a soc-topology compatible manner. When that is done we can see what needs to be done on the kernel side.
Need to think about this and study the changes myself also ;)
Please don't take this message as a rant or dissatisfaction with your help - I realize that you are giving your helpful hints for Pyra project out of good will. I just really want to push this task forward, but I find it not practically feasible to succeed on my own.
None taken.
It is great that someone is pushing for this.
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki