Re: [Alsa-devel] ALSA docs
i would personally work from a complete set of snd-* modules, and use modinfo(1) + perl to get the information Isn't that what happens in the INSTALL file anyway? it doesn't look like it. there are several cards missing there, and it looks hand-written rather then fetched from the source. and put that into the temp file that is inserted into the template, or if possible, put it straight into the template. IIRC doing the above would need access to a set of modules online. Seems unneccesary when the INSTALL file is already available. But I'm willing to be told otherwise if it makes the info more reliable. it would be much more reliable if you got the options from the modules themselves. even just running grep for MOD_PARM etc. would be better than using the INSTALL file. --p --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
Do you mean that I should be parsing each driver file seperately?
not really, just do a single pass over each one of them at some point
in time. store the results, and use them. this should get you started
(its not perfect, but it doesn't do a bad job.
#!/usr/local/bin/perl
while() {
if (/MODULE_PARM_DESC/) {
@foo = split /[()]/;
@bar = split (/,/, $foo[1], 2);
$bar[1] =~ s///g;
printf (%-32s %s\n, $bar[0], $bar[1]);
}
}
add something to recurse through the source tree, and include the
module name and card name info, and you're pretty much done ...
--p
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
Paul Davis wrote:
Do you mean that I should be parsing each driver file seperately?
not really, just do a single pass over each one of them at some point
in time. store the results, and use them. this should get you started
(its not perfect, but it doesn't do a bad job.
#!/usr/local/bin/perl
while() {
if (/MODULE_PARM_DESC/) {
@foo = split /[()]/;
@bar = split (/,/, $foo[1], 2);
$bar[1] =~ s///g;
printf (%-32s %s\n, $bar[0], $bar[1]);
}
}
add something to recurse through the source tree, and include the
module name and card name info, and you're pretty much done ...
Now that I think about it I could probably get away with doing this on
my computer everytime that a new driver is added. We have to add the
info manually for the soundcard matrix anyway.
Although If I don't have access to a working Linux computer in the
future this will cause problems. Ideally I would like a way to do this
all from online preferably automagically.
I'm loathe to admit but I am very new to perl so I don't even know how
to call the above code from a webpage. Is it possible to get the perl
script to parse the files and then use php to parse the output of the
perl script? I have various variables from a form which php can
understand and use to create the correct output in the template.
Unless Dan Hollis speaks up soon (I tried to contact him last Friday)
I'm officially commandeering the Soundcard matrix from his dir and
putting it in the alsa-docs dir. Where it will become the opening page
to the driver docs. He will need to get cvs access for the www dir from
Jaroslav to edit the new version of the matrix.
You can see what I'm trying to do here:
http://www.alsa-project.org/alsa-doc/ALSA_Soundcard_Matrix.php3
That is unless other people have a better idea for how to make the docs
more user friendly (and competitive ;] ).
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
Paul Davis wrote:
#!/usr/local/bin/perl
while() {
if (/MODULE_PARM_DESC/) {
@foo = split /[()]/;
@bar = split (/,/, $foo[1], 2);
$bar[1] =~ s///g;
printf (%-32s %s\n, $bar[0], $bar[1]);
}
}
add something to recurse through the source tree, and include the
module name and card name info, and you're pretty much done ...
I tried the above but it didn't work for me by itself and I don't have
the insight at the moment to get it to. Thanks anyway because you jogged
my memory.
I remembered that Jaroslav had given me a command a while ago (last
year) to get the module options for each module.
modinfo $(modprobe -l snd-*) | cat /art/code/alsa/modinfo
This returns a reasonably readable file. If I make a perl script to
parse that and print a more readable version then I have what I need for
now.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
---
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
Paul Davis wrote: I'm looking into ways to automate the modules options component file for the docs. At the moment I am considering using perl or mysql. Does anyone know which is easier to setup to do the following. Parse the INSTALL file for a module name. Return the info for that module. Then either Write the module info to a temp file which is inserted into the template or insert the module info into the template. i would personally work from a complete set of snd-* modules, and use modinfo(1) + perl to get the information Isn't that what happens in the INSTALL file anyway? and put that into the temp file that is inserted into the template, or if possible, put it straight into the template. IIRC doing the above would need access to a set of modules online. Seems unneccesary when the INSTALL file is already available. But I'm willing to be told otherwise if it makes the info more reliable. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/guide/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
there also needs to be a place for information about card-specific control switches too. Are there many cards that have controls switches? If there are not then I can see a reason to make that component optional to the template. How should I describe them? I have never used a card that has them before. every card with s/pdif i/o has them, just as a start. this is a bad example, since the format of this switch is supposed to be standard, but thats true of many module options too. --p --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
I have the working version of the template for the new improved docs. Can people who have a spare moment have a look through it for obvious mistakes. Any additions to the text will also be appreciated. I've looked at it so many times now I need a fresh eye to spot my mistakes. http://www.alsa-project.org/alsa-doc/doc-php/cmipci.php3 no mistakes, but i still think it very, very important that the link to the section on card-specific options be clear and distinct from everything else. new users may want to see the rest, but in a relatively short time, most of the views of this page will be by people who are looking up specific information. there is a link to this already, but its not obvious enough for my taste. put it as the first element in the table of contents, and use a couple of br elements to make it stand apart from the rest. there also needs to be a place for information about card-specific control switches too. --p --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA docs
I'm looking into ways to automate the modules options component file for the docs. At the moment I am considering using perl or mysql. Does anyone know which is easier to setup to do the following. Parse the INSTALL file for a module name. Return the info for that module. Then either Write the module info to a temp file which is inserted into the template or insert the module info into the template. The problem with mysql is that I would need access to the database. The good thing is that it wouldn't have to get the info everytime a webpage was accessed only when the info changed. (I think) -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.boosthardware.com/LAU/guide/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
