[alsa-devel] PATCH - ESI Juli driver

[Takashi Iwai]

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