[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 themerge window of linux kernel tree. I think it'd be safer to put thecode first to alsa-driver tree and fix remaining issues. Then moveto 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 isbetter. > 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 regardingthe coding style. The linux kernel has relatively strict coding stylerules, something is pretty picky. You don't have to followeverything if you have enough reasons, though :) First off, see $LINUX/Documentation/CodingStyle for details. You canrun $LINUX/scripts/checkpatch.pl (feed your code as a patch by diffagainst /dev/null) as an easy test. There are other issues, but let's check them after fixing the codingstyle. > 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 kerneldrivers 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 toinclude files that have no "OSS" license in ALSA packages. It's notnecessarily to be GPL, but at least, some sane license is required forthe main package. The current license looks fairly unclear toredistribute/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 themerge. We'll review and merge patches from you at any time, ofcourse, after merging your driver to the ALSA tree. So, try to keepyour codes in sync with the ALSA upstream tree. Don't keep changeslocally on your SVN tree (if any) for too long time. The frequentsync 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_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
