PATCH - ESI Juli driver

PATCH - ESI Juli driver

[Pavel Hofman]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hi Takashi,

Juli support required some changes to ice1724.c/ice1712.h. Since Juli 
uses different clock scheme than most other ice1712/24 cards, I had to 
move all clock-specific code to card-specific routines. Most of them are 
redefined in juli.c.

The driver is tested, only analog-in and digital-in monitors are not 
working. I have coded according to manufacturer's documentation, the 
same procedure is in OSS Juli driver. I described the issue in detail in 
the code, perhaps someone will do more research.

The card itself has no HW master volume control. It would have to be 
implemented as a virtual control manipulating internal values of PCM and 
monitor volume controls. I will take a look at it later. For now, 
perhaps we could rename the PCM Volume to Master Volume, as most people 
will not need the monitoring anyway. I will leave it to your decision.

Signed-off-by: Pavel Hofman <dustin@seznam.cz>

* moving all clock-specific code to card-specific routines
* support for ESI Juli
* to-be-researched - monitoring of analog/digital inputs
* missing - master volume control, will have to be implemented as 
virtual, no HW support.


Thanks,

Pavel.

[-- Attachment #2: patch-ice-juli.diff.gz --]
[-- Type: application/x-gzip, Size: 10647 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - ESI Juli driver

[Takashi Iwai]

At Sun, 16 Mar 2008 13:57:24 +0100,
Pavel Hofman wrote:
> 
> Hi Takashi,
> 
> Juli support required some changes to ice1724.c/ice1712.h. Since Juli 
> uses different clock scheme than most other ice1712/24 cards, I had to 
> move all clock-specific code to card-specific routines. Most of them are 
> redefined in juli.c.

I feel there are too many additional callbacks in your patch.
Since we don't need too subtle tuning, can we simplify this?

Regarding the separate rate setting for each stream, we should
consider about Maya44 support, too.

> The driver is tested, only analog-in and digital-in monitors are not 
> working. I have coded according to manufacturer's documentation, the 
> same procedure is in OSS Juli driver. I described the issue in detail in 
> the code, perhaps someone will do more research.
> 
> The card itself has no HW master volume control. It would have to be 
> implemented as a virtual control manipulating internal values of PCM and 
> monitor volume controls. I will take a look at it later. For now, 
> perhaps we could rename the PCM Volume to Master Volume, as most people 
> will not need the monitoring anyway. I will leave it to your decision.
> 
> Signed-off-by: Pavel Hofman <dustin@seznam.cz>
> 
> * moving all clock-specific code to card-specific routines
> * support for ESI Juli
> * to-be-researched - monitoring of analog/digital inputs
> * missing - master volume control, will have to be implemented as 
> virtual, no HW support.

vmaster can be used for this now.  It was moved to core directory
after 1.0.16 release.


thanks,

Takashi

Re: PATCH - ESI Juli driver

[Pavel Hofman]

Takashi Iwai wrote:
> At Sun, 16 Mar 2008 13:57:24 +0100,
> Pavel Hofman wrote:
>> Hi Takashi,
> 
> I feel there are too many additional callbacks in your patch.
> Since we don't need too subtle tuning, can we simplify this?

There are only two callbacks which Juli does not redefine. These could 
be removed. Though I felt it was cleaner to have all the clock-specific 
stuff potentially redefinable for other cards.

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.


> 
> Regarding the separate rate setting for each stream, we should
> consider about Maya44 support, too.

I have been following the discussion. Unfortunately, I did not get to 
see any patch of ice1724.c, iirc the last patch included the whole 
modified ice1724.c copied to alsa-driver.

Rainer, what are the changes?

Now each card can specify its own stream parameters. E.g. Juli has a 
modified list of available frequencies for analog streams.


> 
>> The driver is tested, only analog-in and digital-in monitors are not 
>> working. I have coded according to manufacturer's documentation, the 
>> same procedure is in OSS Juli driver. I described the issue in detail in 
>> the code, perhaps someone will do more research.
>>
>> The card itself has no HW master volume control. It would have to be 
>> implemented as a virtual control manipulating internal values of PCM and 
>> monitor volume controls. I will take a look at it later. For now, 
>> perhaps we could rename the PCM Volume to Master Volume, as most people 
>> will not need the monitoring anyway. I will leave it to your decision.
>>
>> Signed-off-by: Pavel Hofman <dustin@seznam.cz>
>>
>> * moving all clock-specific code to card-specific routines
>> * support for ESI Juli
>> * to-be-researched - monitoring of analog/digital inputs
>> * missing - master volume control, will have to be implemented as 
>> virtual, no HW support.
> 
> vmaster can be used for this now.  It was moved to core directory
> after 1.0.16 release.

Thanks, I did not know about vmaster. I will try to implement it tonight.

The Juli support is one of the very called-for features, I guess it 
would be a pitty to keep a functional patch out of repository.

Thanks,

Pavel.

Re: PATCH - ESI Juli driver

[Takashi Iwai]

At Mon, 17 Mar 2008 09:57:49 +0100,
Pavel Hofman wrote:
> 
> Takashi Iwai wrote:
> > At Sun, 16 Mar 2008 13:57:24 +0100,
> > Pavel Hofman wrote:
> >> Hi Takashi,
> > 
> > I feel there are too many additional callbacks in your patch.
> > Since we don't need too subtle tuning, can we simplify this?
> 
> There are only two callbacks which Juli does not redefine. These could 
> be removed. Though I felt it was cleaner to have all the clock-specific 
> stuff potentially redefinable for other cards.
> 
> 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

Re: PATCH - ESI Juli driver

[Pavel Hofman]

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

Thanks,

Pavel.


> 
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
-----------------

inSITE, s.r.o.

Rubesova 29, 326 00 Plzen
Tel., fax: +420 - 37 - 74 493 58
GSM: +420 - 603 - 163 973
Email: pavel.hofman@insite.cz

www.educity.cz, www.insite.cz
www.meetings.cz, www.hrzive.cz
www.comben.cz, www.hr-online.cz
-------------------------------
Navstivte www.educity.cz, server
s nejvetsi nabidkou profesniho
vzdelavani na ceskem internetu.

Re: PATCH - ESI Juli driver

[Takashi Iwai]

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

Re: PATCH - ESI Juli driver

[Pavel Hofman]

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.

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

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

Thanks a lot,

Pavel.




> 
> 
> thanks,
> 
> Takashi

-- 
-----------------

inSITE, s.r.o.

Rubesova 29, 326 00 Plzen
Tel., fax: +420 - 37 - 74 493 58
GSM: +420 - 603 - 163 973
Email: pavel.hofman@insite.cz

www.educity.cz, www.insite.cz
www.meetings.cz, www.hrzive.cz
www.comben.cz, www.hr-online.cz
-------------------------------
Navstivte www.educity.cz, server
s nejvetsi nabidkou profesniho
vzdelavani na ceskem internetu.

Re: 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

Re: PATCH - ESI Juli driver

[Pavel Hofman]

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.

Re: PATCH - ESI Juli driver

[Takashi Iwai]

At Mon, 17 Mar 2008 16:50:39 +0100,
Pavel Hofman wrote:
> 
> 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.

Exactly.  That's why I suggested here.

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

Well, then we'll need to find some point to compromise.  Could you
repost the patch after reducing the callbacks again?

I'll have also no time from the next week at all -- will be on
vacation for three weeks.  So, let's kick it out soonish :)


thanks,

Takashi

Re: PATCH - ESI Juli driver

[Pavel Hofman]

Takashi Iwai wrote:
> At Mon, 17 Mar 2008 16:50:39 +0100,
> Pavel Hofman wrote:
>> Takashi Iwai wrote:
> 
> Well, then we'll need to find some point to compromise.  Could you
> repost the patch after reducing the callbacks again?
> 
> I'll have also no time from the next week at all -- will be on
> vacation for three weeks.  So, let's kick it out soonish :)
> 
> 
Thanks, I will send the patch tonight.

Pavel.

Re: PATCH - ESI Juli driver

[Demian Martin]

Pavel;

 

I have been following this closely since I have the juli@ card and have been
having problems getting it to work at rates and bit depths other than
44.1/16  and 48/16 on the spdif output. I will be happy to provide a Juli@
card to support the work and keep this going. I’m working with a record
company that is about to start releasing audio at 176.4/24 and the current
playback options are very limited and expensive for that format. The Juli@
can open a lot of new options but it needs proper support. Let me know if
you need it.

 

Demian Martin

Product Design Service

 


No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.21.7/1331 - Release Date: 3/16/2008
10:34 AM
 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - ESI Juli driver

[Pavel Hofman]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

Takashi Iwai wrote:
> At Mon, 17 Mar 2008 16:50:39 +0100,
> Pavel Hofman wrote:
> 
> Well, then we'll need to find some point to compromise.  Could you
> repost the patch after reducing the callbacks again?
> 
> I'll have also no time from the next week at all -- will be on
> vacation for three weeks.  So, let's kick it out soonish :)
> 
Hi,

Here is the patch. I removed several callbacks and changed _rate_code 
callbacks to _rate ones. You were right, the change did clean the code a 
little bit. The vmaster surprisingly works too :)

The compilation writes
In file included from 
/home/pavel/projects/alsa/alsa-driver/pci/ice1712/juli.c:3:
/home/pavel/projects/alsa/alsa-driver/pci/ice1712/../../alsa-kernel/pci/ice1712/juli.c:139: 
warning: function declaration isn’t a prototype

Routine juli_init_gpio_rates() without any parameter starts on that 
line. I do not know how to fix the warning, could you do so, please?

Thanks a lot.

Pavel.


Signed-off-by: Pavel Hofman <dustin at seznam.cz>

* moving most of clock-specific code to card-specific routines
* support for ESI Juli
* to-be-researched - monitoring of analog/digital inputs

[-- Attachment #2: patch-ice-juli-v2.diff.gz --]
[-- Type: application/x-gzip, Size: 11075 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - ESI Juli driver

[Pavel Hofman]

Hello Demian,

Sorry for the late reply.

I have just checked that playing 44.1/24 on Juli's SPDIF-OUT and 
capturing that back using SPDIF-IN of Prodigy192 provides identical 
data. No problem with 24bit resolution.

For you needs Juli is really unique among ice1724 cards, as it can 
output 176.4 SPDIF, unlike cards using ice1724 internal clock scheme.

Regards,

Pavel.

Demian Martin wrote:
> Pavel;
> 
>  
> 
> I have been following this closely since I have the juli@ card and have 
> been having problems getting it to work at rates and bit depths other 
> than 44.1/16  and 48/16 on the spdif output. I will be happy to provide 
> a Juli@ card to support the work and keep this going. I’m working with a 
> record company that is about to start releasing audio at 176.4/24 and 
> the current playback options are very limited and expensive for that 
> format. The Juli@ can open a lot of new options but it needs proper 
> support. Let me know if you need it.
> 
>  
> 
> Demian Martin
> 
> Product Design Service
> 
>  
> 
> 
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.21.7/1331 - Release Date: 
> 3/16/2008 10:34 AM
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PATCH - ESI Juli driver

[Demian Martin]

Pavel:

I want to thank you for getting the Juli@ driver sorted out. Its all working
right and I can play the 176.4 KHz 24 bit files now properly. Along with
96K, 88.2K 48K and 44.1K.  I had to borrow an Apogee 192K mini-dac to test
the system. The inexpensive DAC I got off eBay from China was never tested
properly for high bit rate files and let me off track until I got a known
DAC to test with. 

The unique clocking scheme of the Juli@ card should give lower jitter and
better audio than the other solutions since the clock isn’t generated from a
PLL. It’s a relative bargain compared to a Hammerfall or a Lynx card. And
now with a good Linux driver very useable.

                            -Demian

 

Demian Martin

Product Design Service

784 Cary Drive

San Leandro, CA 94577

209 613 6990

 


No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.21.8/1340 - Release Date: 3/23/2008
6:50 PM
 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel