pricem/da_platform

DIY digital audio platform

"Samoyed" digital audio platform

Documentation site

What is it?

This is a set of PCB designs, FPGA firmware, and software for a digital audio interface. The designs allow for up to 32 channels of audio I/O from four ADC/DAC modules per chassis. The intent is to provide audio quality suitable for hi-fi systems, and to allow experimentation with ADC/DAC module design, digital filtering, and user interfaces.

More detailed documentation is located in the docs directory. This documentation is in Sphinx format and is synchronized to http://da-platform.readthedocs.io. A PDF version is periodically published to docs/da_platform.pdf.

Work is in progress. If you have any questions, please contact the author by creating an issue, or commenting on a relevant issue if one already exists.

Use cases

The author is using this project as a music streaming server, digital crossover, and measurement device in a DIY audio system. Other uses are possible and are described in more detail in the documentation.

License information

This project is open source and intended for non-commercial use. Intellectual property developed for this project is licensed partly under the Solderpad license (hardware) and partly under the GPL (software). Please see the LICENSE file for more information, and the individual licenses in the docs/licenses directory for the complete terms.

Any other intellectual property included in this repository (whether for users' convenience, or accidentally) is covered by its own original license.

da_platform's Issues

Better measurements

This is a wish list for measurements to be performed on current hardware:

• Harmonics and noise swept against signal level for DAC/ADC loopback. I currently have plots swept against frequency at a fixed level; it would be good to do this for a few other levels (say, 0/-3/-10/-20/-60) and see if anything sticks out.
• Update phase noise measurements in final chassis with module breakout.

To be continued.

Baseline carrier: more digital inputs

The platform can accept analog inputs into ADC modules which send I2S signals to the carrier. But with the baseline carrier (Raspberry Pi and FPGA), the only way to supply digital audio is from software within the Raspberry Pi. It should be possible to add other digital input options that are converted to I2S somewhere and treated as if they are coming from "virtual" ADC modules:

• S/PDIF or Toslink
• Bluetooth

Baseline module improvements

This issue will be used to keep track of desired upgrades for the baseline DAC and ADC modules (which are AKM-based), in case we decide to do any further revisions. Improving other modules (e.g. DSD1792 DAC) or using different converter chips would be a separate issue.

• All: Improve I/O connectors. Each channel on DAC2/ADC2 has a 4-pin header, so it isn't possible to connect an RCA and XLR at the same time. It would also be nice to have higher quality connectors (coaxial?) or at least something that locks. For DAC8/ADC8, ribbon cable to RCA panel mount board works well, but the XLR input option for ADC8 needs more thought.
• DAC2: Figure out the right filter values to get a flat HF response through 20 kHz (before digital filtering).
• ADC2: Reduce distortion at near full scale signal levels. Might have something to do with ADC driver power supplies--should use asymmetrical rails (say, +7.5 and -2.5 V) for best swing with 2.5 V CM output.
• ADC2/ADC8: Consider adding selectable input attenuators to handle more than 2 V RMS if desired (e.g. amplifier measurements, music recording). Or maybe an LNA for less than 2 V.
• ADC8: Reduce distortion at high frequencies (2nd harmonic increases starting at 100 Hz) at high input levels. Might have something to do with ADC driver?
• DAC8: Reduce crosstalk. Worst channel pair is -59 dB at 5 kHz. Probably capacitive coupling related to attenuator routing.
• ADC8: Summing 8 channels down to 2 seems to work, but summing 8 channels down to 1 doesn't. Fix this.

Improve documentation

This issue will serve as a running commentary on documentation tasks:

• Provide an overview of the system with a couple high level diagrams
• Rearrange notes/writeup.txt into something more useful
• Locate photos and link to them appropriately
• Compile assorted plots of measured performance
• Write up detailed description of modular architecture and interfaces
• Write up detailed description of boards (v2 modules, carrier, clock, isolator)
• Write up detailed description of digital logic architecture
• Write up software documentation - how to configure MPD, Python scripts, etc.
• Compile subjective impressions of audio quality from various iterations
• Add Gerber files and organize assembly BOM spreadsheets

Better driver for FPGA carrier

The baseline carrier has a USB interface and defines a protocol for sending commands and audio over that interface. In the repository, there is currently a set of Python scripts building on top of libusb1 to exercise this protocol. This is insufficient for at least two reasons:

1. Only a single process can access the hardware at a time.
2. Performance is somewhat slow; the Python script uses a lot of CPU cycles, and this will be a problem if trying to use high channel counts or sample rates on a Raspberry Pi.

A proper Linux driver could address both of those problems. Addressing this issue should consider what (if anything) needs to be in the kernel vs. user-space, and what the appropriate APIs and command line programs would be.

As an intermediate step, it would make sense to refactor the existing scripts into a single program that could accept different playback and recording options, such as the map of logical channels to physical modules/channels, on the command line.

Clocking improvements

I have tested the D/A and A/D modules at different sample rates, but this is not exposed by the software--everything is 44.1 kHz now. This needs to be fixed.

Tasks:

• Build up a new clock board with the "standard" clock configuration (CLK0 = 22.5792 MHz, CLK1 = 24.576 MHz). My board actually has CLK0 = 24.576 MHz and CLK1 = 11.2896 MHz for historical reasons.
• Make I2S clock divider adjustable in slot_controller and expose this functionality through the host interface.
• Modify Python scripts to accept sample rate as a command line argument and change the clock configuration if necessary before sending audio. (Careful; there might already be samples in the FIFO that need to be played back with the previous sample rate before switching.)
• Evaluate different oscillator types subjectively.