Talk:FGCOM Testing

Improved Readability

I have spent an amount of time reformatting this page for readability.

Some of the mistakes were due to the the use of <small> html tag and then wasn't closed. Please see mw:Help:Formatting and experiment in the sandbox.--Gorilla 10:59, 31 May 2010 (UTC)

I'm also pulling my hair-out over the unstructured data on some of these FGCom Wiki's. I can see some additional problems with the FGCom Testing page:

• According to the first chapter title, '1 The Initial test of the standalone FGCOM Installation --> the so called "-f910 Test"', this page relates to the initial previous stand alone version of FGCom. If this Wiki page is no longer relevant to the integrated FGCom-3.0, it should say so within the title of the "FGCom Testing" page? (ie. "FGCom Testing & Debugging (Stand Alone, FGCom < Version 3.0)" ) This way, users can more quickly discern whether they the article relates to their situation?
• The "4 Appendix" has too many subsections and is unbalanced! (Tips & Tricks subsection/chapter should be prior to an Appendix, and not contain USB head-set Ubuntu problems?)
• The Linux ALSA Sound section under Appendix should likely be within the Installation and Configuration section of the main FGCom Wiki and not within the FGCom Testing/Debugging Wiki?

From what I see, it's considered an art form to grammatically structure a (Wiki) page. It's never going to be perfect (and somebody is always going to complain about their perception being better), but it should not get this bad. (Not to bad mouth people, but reminds me of my writing prior to rereading more than five times. ;-) I think the original author's idea of an Appendix was good intentioned (to separate unrelated data), but I've rarely seen appendixes used within Wiki pages nowadays. Usually Tips & Tricks, Reference, Problems/FAQ sections are more often utilized. This Appendix has basically become a page within this page. Likely an attempt by users trying to get their important facts down on paper (or on the Internet) without interfering with others FGCom Wiki pages. Like I said previously, confining FGCom to one Wiki page, would have mitigated much of this confusion of users not knowing where to publish their data. Not to further mention, the more Wiki pages, the more a person has to remember to tick the tick box to "Watch this page" box. ;-)

--Rogerx (talk) 20:33, 22 April 2014 (UTC)

I have an idea! Maybe I can merge all the Linux ALSA related material into the main "Linux software audio mixing with FlightGear" FlightGear Wiki? This would remove a large amount of Linux related material from the FGCom Testing Wiki. (Albeit, that likely needs to be retitled or shortened from "Linux software audio mixing with FlightGear" to "FlightGear Linux ALSA", or just "Linux ALSA" as FlightGear can be assumed from the domain name. --Rogerx (talk) 20:47, 22 April 2014 (UTC)

Appendix, Special for Linux (.alsoftrc)

I do not believe the $HOME/.alsoftrc requires the following lines:

format = AL_FORMAT_STEREO16
cf_level = 1

cf_level seems to be for customizing crossfeed, or for headphones? And specifying the sb16/sb24 bitrates seems to be now as "sample-type = uint16" Of which, these two lines seem not needed for typical users.

Only the following lines are required:

drivers = alsa
[alsa]
device = plug:dmix
capture = plug:dsnoop

It should also be briefly mentioned that the "plug:dsnoop" is equivelent to "plug:dmix", or specifying dmix for the capture card. Linux ALSA audiophile users will commonly prevent ALSA from using DMix, and these asoundrc customizations preventing DMix usage will also unknowingly effect the capture card as well! Hence, users need to have "capture = plug:dsnoop" too, or FGCom will fail to record, inhibiting only silence on playback if "device = plug:dmix" is only used! --Rogerx (talk) 22:40, 21 April 2014 (UTC)