At Mon, 17 Mar 2008 15:08:48 +0100, Pavel Hofman wrote:
Takashi Iwai wrote:
At Mon, 17 Mar 2008 10:37:22 +0100, Pavel Hofman wrote:
What would you recommend?
IMO, rate_code can be avoided. Instead of exposing the encoded value, better to use the raw rate value as parameters.
No problem. I just wanted to avoid the repeated conversion from the numerical rate to the card specific representation which is input information for all the rate-related code. ice1724 cards utilize MT_RATE, juli makes use of GPIO.
If you are OK with the repeated conversion, I will remove this. I tried to keep the methods inline if possible.
Usually you don't have to specify inline expclitily unless it's really the time-critical code path. And the code path of the rate setting is certainly no such a thing.
And, the texts inf rates_info can be generated dynamically.
For obvious reasons I tried changing ice1724 as little as possible. That is why I kept the original code, only rearranged it.
I can change the way texts in rates_info are generated. Still there will have to be some callback as juli has a different list of rates.
So, what we need primarily are callbacks to get and set the current rate setting. Suppose rate=0 as SPDIF-in, we can pass the raw rate value. Then snd_vt1724_pro_internal_clock_get() would just a function to get the current rate and compares it with the given rate_info[] value, returns the index.
I am afraid I do not understand what to change in snd_vt1724_pro_internal_clock_get(). It seems fairly logical, I made only minor changes - is_spdif_master used in other parts of the code, get_rate_index with a simple meaning.
Yeah, your change is logical -- simply convert some code snippets to callbacks. But, this isn't really good for maintenance for a long term. I prefer a bit more straight way if we really change something. And, indeed we do need to change the stuff for rate settings.
How to set stream-specific hw_params is another question. But surely we can cut off a bit more.
We probably can, by rewriting portions of the original well-tested ice1724 code. I really wanted to avoid that and changed by callbacks only the card-specific portions.
OK, I will remove the rate_code conversions, the new overhead will be low and one abstraction will be removed.
For the rest, please state you objectives. Either cutting a few of the callbacks by non-trivial rewrite of the original ice1724 code, or keeping the remaining callbacks and the well-tested code.
Don't be too nervous about changing the ice1724 code right now :) We would need the rewrite of core codes anyway because of other problems in Maya44. And, I believe we can fix more than we might break by such a restructuring in the end. The current ice1724.c is way too complex due to its history, derived from ice1712.c.
Thanks,
Takashi