Hi Mark,
Sorry for the delay, I'm traveling.
On 01/19/2012 09:07 PM, Mark Brown wrote:
Please take a step back (I know I'm rather annoyed and am trying to do so myself), none of this is getting us anywhere.
Agreed. This was not entertaining for me at least. I'm sure we just overlook each other's point of view. I had some time to think this over with a 'clean' head. AFAIK we only place this constraint to 32bit samples. I have not encountered any other HW limitation. What if we just simply convert the msbit core support to apply the constraint to 32 bit samples only? With the current code we are not able to apply different constraint to different sample size anyway. Locally I have added the support for this, but it looks like over engineering. I have the patch(s) for both way, but I think we are better off if we support 32 samples only (simple, clean, covers 99% of use case, well as it is now it covers 100%).
We've got real CPU consumption problems in ASoC - the DAPM algorithm is the biggest one, even with the work I did recently to mitigate against it it's still got the ability to explode dramatically to the point where it's user visible as the worst case is well over O(n^2). There's plenty of low hanging fruit that it'd be much better to spend time on here - as a quick example every time we start or stop a stream we do a linear search of all DAPM widgets looking for those that might be affected based on a string match in order to kick DAPM for them. That's O(n) in the number of widgets in the card plus the strcmp() costs.
And things aren't getting any simpler. For sure we need to do something about this.
We'll all get *much* more benefit from working on improvements of things like that (and on the memory consumption which isn't great either and probably manages to burn measurable CPU cycles due to cache misses) than we ever will from anything we do with this code.
You know Mark, I'm an engineer. It bothers me. It bothers me more since I _know_ it is there. I just can not help myself... Sorry about that.