[alsa-devel] It's time to discuss how to get a Gadget Labs driver into the Alsa tree...

[Takashi Iwai]

[Below is my follow-up via PM, resent to ML]

Hi Mike,

At Tue, 11 Mar 2008 00:03:50 -0400,
Mike Mazarick wrote:
> 
> This message is ‘off list’.   If you feel that it is better for it to be posted
> to the Alsa mailing list, there is no problem with doing so.

Yeah, I prefer this being discussed on alsa-devel ML.
I don't put Cc yet, but please add it in replies if you don't mind.

> As discussed and posted to the Alsa Devel and Planet CCRMA lists back in
> December when this was ‘a dream’, we currently have a working Gadget Labs Alsa
> driver.   There are a few more ‘features’ that are being considered for
> development (multi card support, a control panel, etc) and more extensive
> testing and verification by novice users is desired.    The main idea is that
> we intend to ask the main Alsa developers for information twice;  first when we
> have a functional driver and second when we have one that is ‘user tested’ and
> is ready to go (ie. when there is a high degree of certainty that all the
> features are finished and it’s use won’t cause any major problems).   We are
> now at the first crossroads.  

Great, nice to hear you reached there.

(snip)
> part of Alsa.   The key ‘next’ questions are:
> 
> 1.        When are the next couple of releases of Alsa planned?   How much time
> before the release date should all drivers be ‘in the Hg tree’?

Well, we haven't had no real schedule.  What we care is rather the
merge window of linux kernel tree.  I think it'd be safer to put the
code  first to alsa-driver tree and fix remaining issues.  Then move
to alsa-kernel tree to push to the standard linux kernel tree.

Regarding the merge to HG tree - if your code is mature enough
(e.g. no hourly changes), we can put it at any time.  Sooner is
better.

> 2.       Does the code that is currently in the Gadget Labs SVN repository meet
> the coding and syntax standards of Alsa?   We’ve tried to make it meet the
> standards, and it is fairly easy to change at this stage if you happen to spot
> something that is inconsistent with what you’d recommend.

Just looking at your codes, I found many issues, especially regarding
the coding style.  The linux kernel has relatively strict coding style
rules, something is pretty picky.  You don't have to follow
everything if you have enough reasons, though :)

First off, see $LINUX/Documentation/CodingStyle for details.  You can
run $LINUX/scripts/checkpatch.pl (feed your code as a patch by diff
against /dev/null) as an easy test.

There are other issues, but let's check them after fixing the coding
style.

> 3.       We have not modified Alsa to make this driver automatically;  there is
> a ‘Makefile’ included currently.   We currently ‘modprobe snd_rawmidi’ and
> ‘modproble snd_pcm’ and then ‘insmod gl824.ko’ to get it installed.  The
> required changes to Alsa are fairly trivial and would be the same for every
> other sound card.    Please let us know if there is something that should
> happen besides what is in the GL repository.

Once after the codes get merged to ALSA tree, this won't be a problem.
There won't be anything special about that.

> 4.       One of the key reasons that this driver was able to be developed and
> tested in 2-3 months of part time effort is because there is already complete
> source available for a Windows driver, complete with new firmware and vhdl
> source (see ‘External’ in the repository).   The Windows developer is a member
> of our mailing list and has been encouraging/helping our effort.   However, he
> didn’t bother with GPL licensing (it’s a ‘Mostek/Waldemar’ license instead, but
> the source is readily available).   There may be a few header files that he
> wrote and the PLD firmware is definitely from his development.   Will
> everything (including the firmware) need to be GPLv2  before it can be included
> in the alsa tree?    

Hm, this is a BIG problem.  At least, all source codes of kernel
drivers have to be GPLv2-compatible.  So, please rewrite them if it's 
not.

Firmware files are a bit different.  But, in general, we don't want to
include files that have no "OSS" license in ALSA packages.  It's not
necessarily to be GPL, but at least, some sane license is required for
the main package.  The current license looks fairly unclear to
redistribute/use in the public.


> 5.       What is needed for support?  What would you like us to be available to
> do going forward?

The question is rather how you would work on the driver after the
merge.  We'll review and merge patches from you at any time, of
course, after merging your driver to the ALSA tree.  So, try to keep
your codes in sync with the ALSA upstream tree.  Don't keep changes
locally on your SVN tree (if any) for too long time.  The frequent
sync is very important for collaborative works.

Also, the help on bug tracking system would be greatly appreciated,
too.


> 6.       How can we make your life a little easier by modifying our software?  
> What would you like to see that you don’t see?

See above.


Thanks,

Takashi