[RFC] Echoaudio driver

[RFC] Echoaudio driver

[Giuliano Pochini]

I'm developing the driver for Echoaudio cards for more
than a year and it is stable and it supports almost all
features of eight different soundcards. I think it's
near ready for inclusion in the official ALSA distro. Is
there someone who has time to have a look at the code ?

There are some known issues, though:

- Licence. Part of the driver is based on the reference
code released by the manufacturer with a BSD-like licence:
http://www.echoaudio.com/Downloads/license_agreement.php
and I'm not sure if it's fully GPL-compatible. (Firmwares
and headers are mostly unchanged. *_Dsp.c are 70% a direct
translation from C++ and the rest is all mine)

- Userspace firmware loading is still missing.

- Coding style: yes, I'll replace all C++ comments :)


The code is here: http://xoomer.virgilio.it/g_pochini/ea.html

Comments, suggestions, new hardware, are welcome.



--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] Echoaudio driver

[Takashi Iwai]

Hi,

sorry I've overseen this post.

At Tue, 31 Aug 2004 11:17:10 +0200 (CEST),
Giuliano Pochini wrote:
> 
> 
> I'm developing the driver for Echoaudio cards for more
> than a year and it is stable and it supports almost all
> features of eight different soundcards. I think it's
> near ready for inclusion in the official ALSA distro. Is
> there someone who has time to have a look at the code ?

It looks fine except for exactly the below:


> There are some known issues, though:
> 
> - Licence. Part of the driver is based on the reference
> code released by the manufacturer with a BSD-like licence:
> http://www.echoaudio.com/Downloads/license_agreement.php
> and I'm not sure if it's fully GPL-compatible. (Firmwares
> and headers are mostly unchanged. *_Dsp.c are 70% a direct
> translation from C++ and the rest is all mine)

This is a problem.  BSD isn't GPL-compatible, of course :)
Usually the author provides BSD/GPL dual license to put into the
kernel tree.

I'd suggest either to ask Echo about the permission for BSD/GPL dual
license or to rewrite the BSD part.  Above all, the generic wrapper is
hated by kernel developers, so we'll need to rewrite them later
anyway.  So, I'd prefer rewriting them.


> - Userspace firmware loading is still missing.

The problem is similar, the license of this firmware is unclear.
Let's push it to user-space.  You can replace it easily with
request_firmware() (although it's for 2.6 kernels only).


> - Coding style: yes, I'll replace all C++ comments :)

Comments are relatively accepted, but the C++ style variables and
functions are disliked by many people...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On 22-Sep-2004 Takashi Iwai wrote:
> Hi,
>
> sorry I've overseen this post.

No problems, it's not urgent... and I was busy debugging
that sync-drain problem.


> I'd suggest either to ask Echo about the permission for BSD/GPL dual
> license or to rewrite the BSD part.  Above all, the generic wrapper
> is hated by kernel developers, so we'll need to rewrite them later
> anyway.  So, I'd prefer rewriting them.

The overall structure of the driver is about the same of the
au88x0 driver (I took it as model). Some functions are indeed
too ugly (eg. the enumerated controls) and I already planned to
change them. But I don't like the idea of including lowlevel
functions inside the control and pcm functions because they
would become overly big and ugly. If you're talking about the
*eg thing, well, it's not a problem at all moving the EchoGals
structure inside chip_t and passing it to the lowlevel
functions in place of &eg just like au88x0 does. That would
also allow some cleanup and maybe tighter locking.


>> - Userspace firmware loading is still missing.
>
> The problem is similar, the license of this firmware is unclear.
> Let's push it to user-space.  You can replace it easily with
> request_firmware() (although it's for 2.6 kernels only).

I don't thing the licence is a big problem: the people at
Echoaudio are very friendly. I'll contact them.


>> - Coding style: yes, I'll replace all C++ comments :)
>
> Comments are relatively accepted, but the C++ style variables
> and functions are disliked by many people...

Ok.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [RFC] Echoaudio driver

[Takashi Iwai]

At Thu, 23 Sep 2004 10:22:31 +0200 (CEST),
Giuliano Pochini wrote:
> 
> > I'd suggest either to ask Echo about the permission for BSD/GPL dual
> > license or to rewrite the BSD part.  Above all, the generic wrapper
> > is hated by kernel developers, so we'll need to rewrite them later
> > anyway.  So, I'd prefer rewriting them.
> 
> The overall structure of the driver is about the same of the
> au88x0 driver (I took it as model).

Well, I don't like the current implementation of au88x0 drivers, too
;)  As a result, you got bunch of ifdefs in the code.

In the case of au88x0, it was hard to merge because they use different
addresses in each chip, while echo boards seem to have the same
register offsets, right?
But I don't insist on this rewrite if you prefer keeping this, of
course.

BTW, let's kill SWAP32/SWAP16 macro.  They are always le16_to_cpu()
and le32_to_cpu() regardless of endianness.

Also, checking of sizeof(dma_addr_t) is not correct.  You should check
that the value itself is in 32bit, not the variable type.


>  Some functions are indeed
> too ugly (eg. the enumerated controls) and I already planned to
> change them. But I don't like the idea of including lowlevel
> functions inside the control and pcm functions because they
> would become overly big and ugly.

At least, all functions and variables should have the same style.
The combination of HowLooksThis and how_looks_that is ugly, IMO.


>  If you're talking about the
> *eg thing, well, it's not a problem at all moving the EchoGals
> structure inside chip_t and passing it to the lowlevel
> functions in place of &eg just like au88x0 does. That would
> also allow some cleanup and maybe tighter locking.

Having a common struct as a super calss is ok.


> >> - Userspace firmware loading is still missing.
> >
> > The problem is similar, the license of this firmware is unclear.
> > Let's push it to user-space.  You can replace it easily with
> > request_firmware() (although it's for 2.6 kernels only).
> 
> I don't thing the licence is a big problem: the people at
> Echoaudio are very friendly. I'll contact them.

That's really appreciated.  To be noted, it's not recommended to
include such binary data into the kernel tree, especially if it's
avoidable easily.  (I see you already started coding
request_firmware().)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Thu, 23 Sep 2004 12:52:42 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> > The overall structure of the driver is about the same of the
> > au88x0 driver (I took it as model).
>
> Well, I don't like the current implementation of au88x0 drivers, too
> ;)  As a result, you got bunch of ifdefs in the code.

Yep. Some of them are unavoidable because the cards have very different
capabilities.


> In the case of au88x0, it was hard to merge because they use different
> addresses in each chip, while echo boards seem to have the same
> register offsets, right?

They have only 4 registers and most of the data is passed through a "comm
page", which is a single page in system ram that the DSP accesses via bus
mastering. Both the real registers and the stuff in the comm page have fixed
offsets, but a lot of constants are different and each cards requires its
own functions to do a lot of things (the code is in Echo_<card>Dsp files).


> But I don't insist on this rewrite if you prefer keeping this, of course.

I'm undecided yet on how to rearrange it.


> BTW, let's kill SWAP32/SWAP16 macro.  They are always le16_to_cpu()
> and le32_to_cpu() regardless of endianness.

I did it to translate the code quickly. It's already gone.


> Also, checking of sizeof(dma_addr_t) is not correct.  You should check
> that the value itself is in 32bit, not the variable type.

Ah, it's another peice of code. The PCI is limited at 32bits anyway. The
kernel should not return out of range addresses, unless there is an IOMMU
that remaps them AFAIK. I'll remove that check.


> At least, all functions and variables should have the same style.
> The combination of HowLooksThis and how_looks_that is ugly, IMO.

I'm changing everything to the alsa style, because changing the whole alsa
to ThisStyle is a way too long work :))
(almost done btw)


> >  If you're talking about the
> > *eg thing, well, it's not a problem at all moving the EchoGals
> > structure inside chip_t and passing it to the lowlevel
> > functions in place of &eg just like au88x0 does. That would
> > also allow some cleanup and maybe tighter locking.
>
> Having a common struct as a super calss is ok.

Done.


> To be noted, it's not recommended to
> include such binary data into the kernel tree, especially if it's
> avoidable easily.  (I see you already started coding
> request_firmware().)

The firmware is also quite big...


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Thu, 23 Sep 2004 12:52:42 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> > The overall structure of the driver is about the same of the
> > au88x0 driver (I took it as model).
>
> Well, I don't like the current implementation of au88x0 drivers, too
> ;)  As a result, you got bunch of ifdefs in the code.
>
> In the case of au88x0, it was hard to merge because they use different
> addresses in each chip, while echo boards seem to have the same
> register offsets, right?
> But I don't insist on this rewrite if you prefer keeping this, of
> course.

Most of the #ifdef's are used to exclude unused controls. Those parts can be
moved into separate files and included from <card>.c just like the other
parts. snd_ctl_add() calls will remain inside conditionals anyway.


> At least, all functions and variables should have the same style.
> The combination of HowLooksThis and how_looks_that is ugly, IMO.

I have changed everything to the alsa style.


> > > The problem is similar, the license of this firmware is unclear.
> > > Let's push it to user-space.  You can replace it easily with
> > > request_firmware() (although it's for 2.6 kernels only).
> >
> > I don't thing the licence is a big problem: the people at
> > Echoaudio are very friendly. I'll contact them.
>
> That's really appreciated.  To be noted, it's not recommended to
> include such binary data into the kernel tree, especially if it's
> avoidable easily.  (I see you already started coding
> request_firmware().)

They agreed to release their code under dual Echo/GPL licence. It's not
available on the echoaudio site yet... actually they gave me the permission
to re-release that code. The firmware may be used inside a GPL project, but
its sources are not available. Here is the message. I removed the email, but
it's possible to contact Echoaudio at this public address:
devsupport@echoaudio.com


--------------------------------------------------------------------------
From: xxx <xxx@echoaudio.com>
To: Giuliano Pochini <pochini@shiny.it>
Subject: Re: Linux driver
Date: Tue, 28 Sep 2004 14:41:03 -0700
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

Sounds fine.   Echo hereby grants permission for you to release the generic driver source code for our PCI hardware under the GNU General Public License.

Did you ever resolve your Cardbus issue?

xxx.


Giuliano Pochini wrote:
Ok, thank you very much, I misunderstood your message.
Yes, all license notes on top of each file have to be changed. I already did
the work and I put the file here:

http://xoomer.virgilio.it/g_pochini/EchoGenericDriverA0.tar.gz


I did the following changes:

- I added this note in each file, between the license and the disclaimer:

"Alternatively, this software may be distributed under the terms of the
GNU General Public License ("GPL") version 2 as published by the Free
Software Foundation, in which case the provisions of the GPL apply
instead of those given above."


- I added to the license.txt file the same thing above plus this:

"The firmware code is also subject to one of the two license agreements
stated above, with the exception that Echo Digital Audio does not disclose
the source code from which these firmware images are derived. Permission
is hereby granted for the distribution of these firmware images as part of
the Linux kernel or other GPL project in text or binary form as required."

I wrote that because anyone who releases some software under GPL is supposed
to provide their sources upon request, but they're not available. At the
same time it allows the firmware (which is not strictly GPL-compatible for
that reason) to be included inside ALSA and Linux. Other binary-only
firmwares distributed with the kernel have a similar notice (feel free to
fix my bad english).


- I appended a copy of the GPL to license.txt.


- CLayla24.h didn't have the copyright note at all and I copied it from
CLayla.h, except the (c) line which have a different interval (I left the
original one, that is 1998-2000).


--
Giuliano.
--------------------------------------------------------------------------



--
Giuliano.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Takashi Iwai]

At Thu, 7 Oct 2004 22:01:54 +0200,
Giuliano Pochini wrote:
> 
> On Thu, 23 Sep 2004 12:52:42 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > > The overall structure of the driver is about the same of the
> > > au88x0 driver (I took it as model).
> >
> > Well, I don't like the current implementation of au88x0 drivers, too
> > ;)  As a result, you got bunch of ifdefs in the code.
> >
> > In the case of au88x0, it was hard to merge because they use different
> > addresses in each chip, while echo boards seem to have the same
> > register offsets, right?
> > But I don't insist on this rewrite if you prefer keeping this, of
> > course.
> 
> Most of the #ifdef's are used to exclude unused controls. Those parts can be
> moved into separate files and included from <card>.c just like the other
> parts. snd_ctl_add() calls will remain inside conditionals anyway.

Sounds better (unless this results in too many files :)


> > At least, all functions and variables should have the same style.
> > The combination of HowLooksThis and how_looks_that is ugly, IMO.
> 
> I have changed everything to the alsa style.

Fine, thanks.


> > > > The problem is similar, the license of this firmware is unclear.
> > > > Let's push it to user-space.  You can replace it easily with
> > > > request_firmware() (although it's for 2.6 kernels only).
> > >
> > > I don't thing the licence is a big problem: the people at
> > > Echoaudio are very friendly. I'll contact them.
> >
> > That's really appreciated.  To be noted, it's not recommended to
> > include such binary data into the kernel tree, especially if it's
> > avoidable easily.  (I see you already started coding
> > request_firmware().)
> 
> They agreed to release their code under dual Echo/GPL licence. It's not
> available on the echoaudio site yet... actually they gave me the permission
> to re-release that code. The firmware may be used inside a GPL project, but
> its sources are not available. Here is the message. I removed the email, but
> it's possible to contact Echoaudio at this public address:
> devsupport@echoaudio.com

That's great.

About the firmware: since the recent 2.4 kernel also includes
request_firmware(), it's the easiest way to go, I believe.

I'll rewrite the firmware code later for other drivers.  I'll likely
keep the old implementation of ALSA firmware loader for the cases that
no kernel fw-loader is configured or the driver is built in kernel.


If you finish them, please send me the patch.


thanks,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Fri, 08 Oct 2004 16:47:52 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> > > In the case of au88x0, it was hard to merge because they use different
> > > addresses in each chip, while echo boards seem to have the same
> > > register offsets, right?
> > > But I don't insist on this rewrite if you prefer keeping this, of
> > > course.
> >
> > Most of the #ifdef's are used to exclude unused controls. Those parts can be
> > moved into separate files and included from <card>.c just like the other
> > parts. snd_ctl_add() calls will remain inside conditionals anyway.
>
> Sounds better (unless this results in too many files :)

8 new files... And I'm not sure it looks better than before.

http://xoomer.virgilio.it/g_pochini/ea-0.9.0.tar.bz2


> About the firmware: since the recent 2.4 kernel also includes
> request_firmware(), it's the easiest way to go, I believe.
>
> I'll rewrite the firmware code later for other drivers.  I'll likely
> keep the old implementation of ALSA firmware loader for the cases that
> no kernel fw-loader is configured or the driver is built in kernel.
>
> If you finish them, please send me the patch.

I've not written the firmware loader yet. I'll do it during the week end.


--
Giuliano.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Takashi Iwai]

At Sat, 9 Oct 2004 00:04:45 +0200,
Giuliano Pochini wrote:
> 
> On Fri, 08 Oct 2004 16:47:52 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > > > In the case of au88x0, it was hard to merge because they use different
> > > > addresses in each chip, while echo boards seem to have the same
> > > > register offsets, right?
> > > > But I don't insist on this rewrite if you prefer keeping this, of
> > > > course.
> > >
> > > Most of the #ifdef's are used to exclude unused controls. Those parts can be
> > > moved into separate files and included from <card>.c just like the other
> > > parts. snd_ctl_add() calls will remain inside conditionals anyway.
> >
> > Sounds better (unless this results in too many files :)
> 
> 8 new files... And I'm not sure it looks better than before.
> 
> http://xoomer.virgilio.it/g_pochini/ea-0.9.0.tar.bz2

Well, I'm also not sure :)
Choose as you like for the initial release.  We can clean up later
on.


> > About the firmware: since the recent 2.4 kernel also includes
> > request_firmware(), it's the easiest way to go, I believe.
> >
> > I'll rewrite the firmware code later for other drivers.  I'll likely
> > keep the old implementation of ALSA firmware loader for the cases that
> > no kernel fw-loader is configured or the driver is built in kernel.
> >
> > If you finish them, please send me the patch.
> 
> I've not written the firmware loader yet. I'll do it during the week end.

Thanks.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On 11-Oct-2004 Takashi Iwai wrote:

>> 8 new files... And I'm not sure it looks better than before.
>>
>> http://xoomer.virgilio.it/g_pochini/ea-0.9.0.tar.bz2
>
> Well, I'm also not sure :)
> Choose as you like for the initial release.  We can clean up later
> on.

Hm, I reverted them excepted the _gml one because it avoid
duplicated code.


>> > About the firmware: since the recent 2.4 kernel also includes
>> > request_firmware(), it's the easiest way to go, I believe.
>> >
>> > I'll rewrite the firmware code later for other drivers.  I'll likely
>> > keep the old implementation of ALSA firmware loader for the cases that
>> > no kernel fw-loader is configured or the driver is built in kernel.
>> >
>> > If you finish them, please send me the patch.
>>
>> I've not written the firmware loader yet. I'll do it during the week end.

I wrote the fw loader stuff, but I kept the possibility to compile
the driver with embedded fw because Mona and Laya24 need it. I'll
change it later. The code is here as usual:

http://xoomer.virgilio.it/g_pochini/ea.html

It has been tested on my Gin24 only.


--
Giuliano.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Tue, 12 Oct 2004 11:25:21 +0200 (CEST)
Giuliano Pochini <pochini@shiny.it> wrote:

> I wrote the fw loader stuff, but I kept the possibility to compile
> the driver with embedded fw because Mona and Laya24 need it. I'll
> change it later. The code is here as usual:
>
> http://xoomer.virgilio.it/g_pochini/ea.html
>
> It has been tested on my Gin24 only.

Ok, external firmware should work for all cards. Expecially the Mona driver
was tricky because it needs to reload the firmware when switching between
single and double speed mode. This and the fact that request_firmware() can
sleep creates races conditions in the set_sample_rate, set_input_clock and
set_digital_mode pcm_digital_open functions. I had to add a mutex and to
reorder some code. I hope I didn't introduce new bugs...


--
Giuliano.


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Sat, 23 Oct 2004 16:15:30 +0200
Giuliano Pochini <pochini@shiny.it> wrote:

> Ok, external firmware should work for all cards. [...]

0.9.4- Two busy loops were been replaced with something more
system-friendly (the machine does not freeze anymore while loading the
firmware, expecially if something goes wrong). Some more coding style
changes were done (c++ comments).


There are two semi-issues left.

1- All levels are exported to userspace in 24.8 fixed point format. This is
done by the driver, because the hw currently only have 1 or 0.5 dB
resolution. I'm not sure if exporting gains in native resolution is better.

2- There is that ugly hack to make the sample rate selection work fine in
the most common cases. I already talked about that. The problem is that the
sample clock is shared by all channels. The current implementation allows an
app to change che clock freely as far as there is only one pcm device open.
When there are >1 it allows one app to set the clock only once. This method
prevents an app to kick in and screw up an already running recording or
playback. It's a hack, but it worked fine so far. I think it's about ok :-/


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On Tue, 26 Oct 2004 23:18:54 +0200
Giuliano Pochini <pochini@shiny.it> wrote:

> 1- All levels are exported to userspace in 24.8 fixed point format. This is
> done by the driver, because the hw currently only have 1 or 0.5 dB
> resolution.

I removed that crap. Ctl interface now uses raw values.

I don't see anything obviously wrong in the driver now. What have I to do to
include it in alsa-driver yet ?

(the code is here as usual: http://xoomer.virgilio.it/g_pochini/ea.html)

Perhaps I'll put the driver in bugfixes-only state because it's very stable
and ready for production for a long time now and because Echoaudio has just
released a new version of their generic code that support all cards and I
want to start working of it ASAP. There are several changes to the DSP
firmware that may cause incompatibilities with the current driver (maybe
not, I only had a look at the notes).


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: [RFC] Echoaudio driver

[Clemens Ladisch]

Giuliano Pochini wrote:
> I don't see anything obviously wrong in the driver now.

AFAICS the MODULE_LICENSE is really "Dual BSD/GPL", apart from the
non-GPL (?) firmware which would belong into the alsa-firmware
package.

Does it compile on 2.4.x kernels?  On 2.2.x kernels?  >;-)
(I guess we can deactivate it if it's compiled on kernels without
request_firmware().)

> What have I to do to include it in alsa-driver yet ?

Make a big patch, then yell loudly until somebody includes it.


Clemens



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: [RFC] Echoaudio driver

[Takashi Iwai]

At Mon, 8 Nov 2004 19:16:21 +0100 (MET),
Clemens Ladisch wrote:
> 
> Giuliano Pochini wrote:
> > I don't see anything obviously wrong in the driver now.
> 
> AFAICS the MODULE_LICENSE is really "Dual BSD/GPL", apart from the
> non-GPL (?) firmware which would belong into the alsa-firmware
> package.
> 
> Does it compile on 2.4.x kernels?  On 2.2.x kernels?  >;-)
> (I guess we can deactivate it if it's compiled on kernels without
> request_firmware().)

The code with request_firmware() needs a patch for 2.4 kernels since
2.4 kernels don't have struct device.  The argument takes a different
thing.

Maybe we'll need a check in configure script for CONFIG_FW_LOADER
to select this driver.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: [RFC] Echoaudio driver

[Giuliano Pochini]

On 08-Nov-2004 Clemens Ladisch wrote:
> Giuliano Pochini wrote:
>> I don't see anything obviously wrong in the driver now.
>
> AFAICS the MODULE_LICENSE is really "Dual BSD/GPL", apart from the
> non-GPL (?) firmware which would belong into the alsa-firmware
> package.

Ah, no, the new code from Echoaudio is now fully GPL'd, except
the firmware. I've not updated the licence notice at the beginning
of each file yet. Furthermore, I'll not freeze the dev status
because I have to do far less changes than I though at first
glance. Darla20, Gina20 and Gina24 are already supported with
the new firmware (tested only on the Gina24) and the other cards
will be supported in a few days.


> Does it compile on 2.4.x kernels?  On 2.2.x kernels?  >;-)

It does on 2.4 (but I don't test it for a long time). I don't
think it compiles on 2.2... never tried anyway.


> (I guess we can deactivate it if it's compiled on kernels without
> request_firmware().)

I kept the possibility to use compiled-in firmware.


>> What have I to do to include it in alsa-driver yet ?
>
> Make a big patch, then yell loudly until somebody includes it.

The tarball has a small patch (Kconfig and Makefile) and all
the code is in /pci/echoaudio/


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click