Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Pavel Hofman <pavel.hofman@insite.cz>
Cc: ALSA development <alsa-devel@alsa-project.org>,
	Rainer Zimmermann <mail@lightshed.de>
Subject: Re: PATCH - ESI Juli driver
Date: Mon, 17 Mar 2008 14:04:11 +0100	[thread overview]
Message-ID: <s5hwso1pkms.wl%tiwai@suse.de> (raw)
In-Reply-To: <47DE3BD2.5090007@insite.cz>

At Mon, 17 Mar 2008 10:37:22 +0100,
Pavel Hofman wrote:
> 
> >>
> >> I did not want to copy/paste any algorithmical code from ice1724.c to 
> >> juli.c as it complicates future maintenance. Now, the vt1724 code in 
> >> ice1724.c is pretty much about general algorhitms, specific routines are 
> >> in stdclock_... I tested the original clock with Prodigy192 which 
> >> provided testing analog/SPDIF signals. There are no functional changes.
> > 
> > I see the point that you want to make it generic.  But, too many
> > callbacks, in other words, too many tuning parameters make the code
> > difficult to follow.  It's a question of balance.
> 
> Takashi, I understand your concern. On the other hand, if the callbacks 
> are well documented, it actually makes the code easier to follow, as it 
> separates general algorithms from detailed HW implementation. I can 
> certainly add more comments to the callback functions.
> 
> Honestly, I do not know which callbacks to remove (apart of those two 
> not redefined in Juli). Otherwise I will have to copy/paste serious 
> portions of code to juli.c which I would really want to avoid.
>
> As I see it, the clocking code in ice1724 was written for one specific 
> implementation. There was no need to do so in a general way and I 
> completely understand that. Nevertheless, juli uses a different clock 
> implementation and I believe the time has come to make the code in 
> ice1724 more general. Unfortunately, I do not know of any other 
> technology but callbacks.
> 
> 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.
And, the texts inf rates_info can be generated dynamically.

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.

How to set stream-specific hw_params is another question.  But surely
we can cut off a bit more.


thanks,

Takashi

  reply	other threads:[~2008-03-17 13:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-16 12:57 PATCH - ESI Juli driver Pavel Hofman
2008-03-17  7:59 ` Takashi Iwai
2008-03-17  8:57   ` Pavel Hofman
2008-03-17  9:24     ` Takashi Iwai
2008-03-17  9:37       ` Pavel Hofman
2008-03-17 13:04         ` Takashi Iwai [this message]
2008-03-17 14:08           ` Pavel Hofman
2008-03-17 15:17             ` Takashi Iwai
2008-03-17 15:50               ` Pavel Hofman
2008-03-17 15:59                 ` Takashi Iwai
2008-03-17 16:39                   ` Pavel Hofman
2008-03-17 23:28                   ` Pavel Hofman
2008-03-18  6:56                   ` PATCH - ESI Juli driver - removed debugs Pavel Hofman
2008-03-18 14:59                     ` Takashi Iwai
2008-03-18 15:59                       ` Pavel Hofman
2008-03-20 14:20                         ` Pavel Hofman
2008-03-20 21:49                           ` PATCH - ESI Juli driver - OK Pavel Hofman
2008-03-18 19:24                       ` PATCH - ESI Juli driver - works OK Pavel Hofman
2008-03-20 11:37                         ` Takashi Iwai
  -- strict thread matches above, loose matches on Subject: below --
2008-03-17 17:08 PATCH - ESI Juli driver Demian Martin
2008-03-21 16:02 ` Pavel Hofman
2008-03-25  6:30 Demian Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hwso1pkms.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=mail@lightshed.de \
    --cc=pavel.hofman@insite.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox