From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: PATCH - ESI Juli driver Date: Mon, 17 Mar 2008 16:17:59 +0100 Message-ID: References: <47DD1934.3000003@insite.cz> <47DE328D.1080009@insite.cz> <47DE3BD2.5090007@insite.cz> <47DE7B70.2040407@insite.cz> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 4BF31103889 for ; Mon, 17 Mar 2008 16:18:00 +0100 (CET) In-Reply-To: <47DE7B70.2040407@insite.cz> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Pavel Hofman Cc: ALSA development , Rainer Zimmermann List-Id: alsa-devel@alsa-project.org 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