UniAudio Development

This document is used to collect ideas about what has to change to start with UniAudio development again. This is by no means a complete document, so please help to finish it!

How to improve development

• Always try to make the audio hardware available to the developer or have a tester you can trust
  • Usually, it does not cost that much to purchase a sound card
    • Especially compared to the actual money that was spend on the developer!
  • If the card is not onboard, we should try to make it available to the developer
  • If not, we have to find a tester that helps the developer
  • If there is no tester, and the developer has no hardware, than we should not work on that
• Create a document that describes in full detail what a tester has to do and how
  • There are various ways in which UniAudio outputs usefull information, those have to be listed and explained
• Record user and tester reports in an "experience database" so the developer(s) can relate changes to effects more easily--also at later points for previous versions
• We need clear milestones
• Have a test plan for every major release
  • This can only work if we have a number of testers for UniAudio
  • It would be nice to have a list of "tested" vs. "untested" hardware, not just a list of what should work
    • It would be beneficial to have a database where the hardware can be listed and a set of tests defined, this would help take care of the plan for testing as well as the list of "tested" vs. "untested" hardware. Then the testers can mark the tests they have performed (I have never tried to record on this machine for instance and don't have a mic but could sign off on other tests).
• Standardize the build environment with the help of Christian Langanke
• Make it easier for testers and users to find appropriate versions
  • Follow a strict version numbering scheme
  • Record changes, preferably in "non-developer speak"
• Document the Uniaud API so other developers can put it to use
• have more then one developer on the project (less dependency, multiple eyes on the same problems, fall back, knowledge exchange)

Suggestions for Milestones

• building a new release from the current svn repository
• closing all old bugreports (no-one knows the status of the old bugs)
• applying ALSA patches to be in sync
• test HDA support
• test APM support (including APM in ACPI)
• create an easy to use PM mixer, maybe based on LBMix
• create an up-to-date list of supported chips

How to raise money

• from the os2world.com thread
  • Collect up front $5000 to $6000 by $20 per subscription for 1 year. This means 200 to 300 people must subscribe to this project.

Make 5 milestones. Subscribers vote as to whether the milestone has been reached and the programmer is paid $1000 per milestone.