All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Hofman <pavel.hofman@insite.cz>
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA development <alsa-devel@alsa-project.org>,
	Rainer Zimmermann <mail@lightshed.de>
Subject: Re: PATCH - ESI Juli driver
Date: Mon, 17 Mar 2008 16:50:39 +0100	[thread overview]
Message-ID: <47DE934F.3060308@insite.cz> (raw)
In-Reply-To: <s5hd4ptpefs.wl%tiwai@suse.de>

Takashi Iwai wrote:
>> 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.

I am afraid I do not have the insight of what needs to be changed. The
code as is seems fairly OK to me, just a bit underdocumented.

> 
>>
>> 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.

Well, to tell the truth, I do not feel knowledgeable enough of the
alsa infrastructure to implement major changes in ice1724 code.

Actually, what is the deal with maya44? Its detailed image shows it has 
standard clocking scheme (no FPGA, PLL etc.), just a couple of Wolfson 
codecs, connection to MI/ODI/O card (fully supported e.g. by 
Prodigy192), switched I2S input between SPDIF-IN/Analog-IN. I just do 
not see a reason to rewrite ice1724 because of maya44 support.

The limitation of capture rate to 96kHz is present in most other ice1724 
cards (including Juli) and nobody has made a big deal of it. It could be 
perhaps tackled in a similar manner we solved the single SPDIF-input rate.

Plus I will have to return the borrowed Juli soon, and will not be able 
to do some qualified testing.

I have another ice1724 card on the way (SndScape Odeum SPDIF interface) 
and really would love to finish Juli soon.


Thanks a lot,

Pavel.

  reply	other threads:[~2008-03-17 15:50 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
2008-03-17 14:08           ` Pavel Hofman
2008-03-17 15:17             ` Takashi Iwai
2008-03-17 15:50               ` Pavel Hofman [this message]
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=47DE934F.3060308@insite.cz \
    --to=pavel.hofman@insite.cz \
    --cc=alsa-devel@alsa-project.org \
    --cc=mail@lightshed.de \
    --cc=tiwai@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.