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

[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