Contributing

How to Contribute

Open Apollo is a community-driven project. We need help from Apollo owners to test on different models, capture device data from working systems, and contribute code improvements.


Tier 1: Test on Linux (easiest)

If you have an Apollo connected to a Linux machine, this is the most straightforward way to help.

What to do

  1. Build and load the driver (Installation guide)
  2. Run the device probe script:
    sudo ./tools/contribute/device-probe.sh
    
  3. Test basic functionality:
    • Does aplay -l show your Apollo?
    • Does audio playback work?
    • Does recording work?
    • Do preamp controls respond?
  4. Submit a device report with your probe output and test results

What we learn

Even a simple "driver loaded, audio plays" report on a model we haven't tested is enormously helpful. It lets us mark that model as verified and gives other users confidence.


Tier 2: Capture device data (advanced)

The most valuable contribution is capturing device configuration data from a working system (macOS or Windows). This data tells us exactly how each Apollo model configures its audio routing, which is essential for supporting models we don't have physical access to.

macOS capture

Requires temporarily disabling System Integrity Protection (SIP) to use DTrace. The capture script is read-only — it observes driver behavior without modifying anything.

See the full guide: Device Capture (macOS)

Windows capture

Uses WinRing0, an open-source kernel driver, to read PCIe registers. The capture script only reads status and configuration registers — no writes.

See the full guide: Device Capture (Windows)

After capturing

See Submitting Your Data for how to review and submit your capture.


Tier 3: Code contributions

We welcome pull requests for bug fixes, new features, and documentation improvements.

Getting started

  1. Fork the repository on GitHub
  2. Create a feature branch:
    git checkout -b feat/your-feature-name
    
  3. Make your changes
  4. Test your changes (build the driver, run the daemon)
  5. Commit using conventional commits:
    git commit -m "feat: add support for Apollo Twin X preamp routing"
    
  6. Push and open a pull request

Commit message format

We use conventional commit prefixes:

PrefixUse for
feat:New features
fix:Bug fixes
docs:Documentation changes
refactor:Code restructuring without behavior change
test:Adding or updating tests
chore:Build, CI, or tooling changes

What we need most

  • Device testing — People with non-x4 Apollo models willing to test and report
  • Routing table captures — DTrace or BAR0 captures from untested models
  • Mixer daemon improvements — Protocol edge cases, error handling
  • Documentation — Corrections, clarifications, additional examples

Reporting issues

If something doesn't work, please open an issue with:

  • Your Apollo model
  • Linux distribution and kernel version (uname -r)
  • Output of dmesg | grep ua_apollo
  • What you expected vs. what happened
  • Steps to reproduce

Code of conduct

Be respectful, constructive, and patient. This is a reverse-engineering project — things break, behavior is surprising, and progress is incremental. Every contribution, no matter how small, moves the project forward.

Previous
Configuration