Design Criteria

[Alexcount]

Design Criteria for the OpenNGDI Project

The Open NextGen Digital Interface - A GPL 2.0 Open Hardware/Software
Project


- Support up to 400Khz PCM formats I/O via I2S (IIS) (maybe 768Khz or
greater)

- Support Delta Sigma 1-bit up to 12.288Mhz (256fs) I/O via I2S

- Support Delta Sigma 5-bit & 6-bit formats up to 12.288Mhz (256fs) I/
O (needs to support available ADC's eg. TI PCM4222, Arda AT1201, etc.)

- Designed to be expandable. By this I mean a structure which lends
itself to future modifications/branches (eg. SDR might need as high as
1gs/s sample rate, probably worthy of branching project for this goal)

- Support a modern high speed interface, probably USB 3.0. Gigabit
ethernet or fibre would be nice (want suggestions, firewire is dead in
the water, but maybe Thunderbolt?)

- Support Multiple channels, or have ability to gain together to
expand channels (Minimum 2 channels, and ability to lock clocks/
software for 2 or more attached to one computer would be nice, maybe
the multi-bit I/O could be used for multiple channels)

- Preferably 2 clocks, multiples of 44.1Khz and 48Khz, would be
optimal for audio, whether DSD or PCM. (Possibly 1 very nice ultra low
noise SC-cut crystal oscillator like a Wenzel or other astronomy class
oscillator external, but would require DDS like AD9910 or AD9912)

- Independent isolated supplies for all components onboard, DC input
(maybe super-regulators on a daughter-board, allows experimentation/
upgrading) modular

- Overall modular approach (Clock & all supplies by-passable, anything
ancillary onboard can be disabled)

- All analog stages I/O external and off-board, similar to the design
of the Buffalo-II (allows easily customizing output stage to taste for
audio [eg. transformers, discrete, opamps, or tubes] or different
preamps for scientific purposes, such as for a photomultiplier or for
precise measurements)

- Tested and documented specifications of ACTUAL hardware, as simple
as it seems, most open-source or closed-source products lack such
testing in the design process, or provide detailed specifications from
proper test equipment.

- USB will allow using the standard USB Audio 1.0 and 2.0 driver
models, which would simplify use for 192Khz and lower sample rates.
(USB Audio 2.0 might have licensing fees, another good reason to
develop open-drivers.) 400Khz PCM can be supported in windows via an
ASIO 2.1 driver, but will need a driver for unix and OS X. 768Khz and
1.5Mhz PCM will also need a driver solution. DSD will require
developing a driver model for *nix, OS X and Windows. Hopefully a
standard cross-platform opensource driver model can be developed for
DXD, Delta Sigma Single and Multi-bit formats. Just creating a
standard cross-platform driver model for Delta sigma would be very
beneficial to the opensource community.


I need help in this critical stage of planning. Please get involved.


Any Questions or Comments are welcomed.

-Alexander Countey

[Alexcount]

Hello Marco,

Actually, the TentLab style regulators were my inspiration for modular "daughter"-boards. I do understand the need for them to be as close as possible. I was planning to design all PCB's to accept this style of regulator, to ensure the placement of miniature super-regs would not be compromised and as close as possible to the IC supply pins. Some of the supplies might be critical enough to necessitate building them on-board, but another advantage of the modular route like the TentLabs regs is it allows easy replacement for testing / experimentation. Another rationalizing to making all "super-regulator" type supplies in a TentLabs style package is the ability to reuse the same supply for other projects, both sister projects and many unrelated projects can benefit from an Open-Hardware super-regulator alternative. By making it general purpose, through economy of scale cost can be reduced.

I think the super-regulator portion of this project should be developed independently in a child project, currently named the Open-NGSR or Open Next-Gen Super Regulator

I am currently using Super-Regulators developed by Paul Hynes, and one of his larger power supplies, all powered by a set of car batteries in plastic cases. This has given me the last 1% of detail from my current 1-bit 5.6 Mhz DSD recording setup, but I feel a need for more, hence the development of this whole project.

The Design goal of 24.576Mhz (512Fs) is 512 x 44.1, or 64 x 384Khz. The exact reason this was choosen was the reason you describe. This format is the "raw" un-interpreted stream of data coming out of today's highest dynamic range ADC (The Arda at1201) which internally operates at 6-bit 24.576Mhz Sigma-DPCM (A.K.A Multibit Delta-Sigma.) Higher speeds would be ideal for many purposes, but for the sake of reasonable goals for the first prototype, 24.576Mhz is as fast as any commercial high dynamic range ADC provides. For Playback of audio, if that is what is recorded, a custom discrete 6-bit Sigma-DPCM (or Multibit Delta-Sigma, as it is more commonly referred to) will need to be developed, otherwise it will need to be converted for playback. For data other than audio this is not critical immediately.

Indeed, there is a branch of this project oriented for data, dubbed the Open-NGSDR project, or Open Next-Gen Software Defined Radio.

Capturing the "oversampled" raw stream from today's best high dynamic range ADC's is the primary goal of this project.  My interest in such formats started with DSD, but I feel as today's best ADC's do not see the world in a 1-bit 64x oversampled math, the format seemed dated. The more I learned about multi-bit delta-sigma (or Sigma-DPCM) I realized though ADC's such as the PCM4222 and Arda At1201 operate not only oversampled, but a multi-bit oversampled format, I felt a need to hear this format recorded and played back without unnecessary mathematical interpretation or manipulation, or as you say choose the algorithm of your choice. Even though this format is admitably ineffieficent, in my mind there are many instances where this "inefficiency" does not matter at all, such as for archival purposes, or scientific investigation of frequencies beyond audible. I also have a sneaking suspicion that very fine phasing and timing information that might be preserved in these high speed formats is destroyed upon down-conversion to other formats.

Another goal of mine is to test what if any phase information might be retained with these "raw" audio formats, to be tested with binaural audio recordings and playback through headphones. I plan to create headphones and a binaural "dummy head" microphone using a plasma as the diaphragm. Plasma's have effectively zero friction or mass, and can receive frequencies in excess of 5 mhz without resonance issues or phase distortion. They can also be used as effectively "perfect" sound sources, capable of generating very widebands frequencies. My theory is with a "perfect" microphone and speaker, all phase information will be retained creating more vivid and realistic aural "imaging".

I apologize the list here must be updated, as it does not reflect the most recent criteria. Have you seen the main website of this Project? It's on Google Code, at http://code.google.com/p/open-ngdi

Thank you for getting a discussion going.
-Alexander Countey


On Thursday, August 16, 2012 1:52:58 AM UTC-4, Marco ter Bekke wrote:

It`s rather useless to use super regulators on a daughter board, best is to follow a similar solution as this: http://tentlabs.com/Components/Shuntcomp/assets/ShuntAppNoteAN04V02.pdf , no i am not affiliated with tentlabs, but it is an excellent and easy to read explanation why it should be done this way.
Another design goal for the speed of the interface could be: the maximum imaginable sampling frequency, times the oversampling. Arda/TI already have adc`s that sample at 384KHz, many dac`s oversample 8 times, which would imply a minimum datarate of about 3,072 megawords/second/channel. The reason why would be: being able to let a computer do all the math in filtering, oversampling algorithmes etc (also to be able to turn off the dac`s own, hardware coded filters etc.) All in all: for e.g. software audio players like Signalyst and Audirvana, not to forget the whole scientific community..).
It is a very promising project, i`d like to help with, amongst other people and things, the regulators.

Marco

On Thursday, August 16, 2012 1:52:58 AM UTC-4, Marco ter Bekke wrote:

It`s rather useless to use super regulators on a daughter board, best is to follow a similar solution as this: http://tentlabs.com/Components/Shuntcomp/assets/ShuntAppNoteAN04V02.pdf , no i am not affiliated with tentlabs, but it is an excellent and easy to read explanation why it should be done this way.
Another design goal for the speed of the interface could be: the maximum imaginable sampling frequency, times the oversampling. Arda/TI already have adc`s that sample at 384KHz, many dac`s oversample 8 times, which would imply a minimum datarate of about 3,072 megawords/second/channel. The reason why would be: being able to let a computer do all the math in filtering, oversampling algorithmes etc (also to be able to turn off the dac`s own, hardware coded filters etc.) All in all: for e.g. software audio players like Signalyst and Audirvana, not to forget the whole scientific community..).
It is a very promising project, i`d like to help with, amongst other people and things, the regulators.

Marco