[linux-audio-dev] Preliminary spec for OpenGraphics soundcard

james at dis-dot-dat.net james at dis-dot-dat.net
Wed May 3 18:35:26 UTC 2006


On Wed, 03 May, 2006 at 03:37AM -0400, spikethehobbitmage at excite.com spake thus:
> 
> I have gained much valuable insight from reading the posts from last month on Linux Audio Dev and OpenGraphics.  I have tried to incorporate what wisdom I could.  Someone wiser than I could greatly improve on this, of course.  Hence this document.

When can you send me one?  I'm excited and I don't like waiting!

:)

This all sounds very very good.
 
> 
> Low to mid-range markets are saturated.  Buildable, but not likely saleable.  Top end market is pretty tight.  R&D budget for that level of gear is probably more than the video card project.  Semi-pro is more doable.
> 
> Best bet is an aggressive design to sell on performance and features.  Most advanced features can be implemented in software, so the hardware should be fairly straight-forward, but it still needs good throughput.
> 
> Target market
>  Semi-pro audio (high end of target)
>  High end gamers (mid range of target)
>  Home theater (low end of target)
>  Hobbyist
>  -Hobbyist add-ons could greatly increase saleability to other markets
>  US$300? price range for baseline system - this needs to be priced out
>  19" rackmount boxes may cost more.  Mainly due to the sheer volume of good stuff that can be packed into them.  see below.
> 
> 
> Features
>  192kHz @ 24bit inputs and outputs (48 bit fixed point internal)
>  on board resampling/mixing
>   sample rate
>   bit depth
> # channels
>   channel swap
>  on board realtime compression/decompression/transcoding
>  all analog I/O is in (shielded) breakout boxes
>   more than one kind of box supported (including custom boxes)
>   more than one box at a time supported
>   breakout boxes may be up to 100m from host system
>  MIDI
>  5.1 optical
>  ADAT
>  sound samples/effects may be preloaded to card and played/mixed on demand
>  full 3D audio processing
>  custom codecs and effects generators may be loaded on demand
>  on board speech synthesis - just another codec :)
>  on board speech recognition - same :)
>  IR remote control?
>  watchdog timer?
> 
> 
> Several people have voiced desire for 192kHz capability and have indicated media at this quality is available from some sources.
> 
> Native sample capabilities
>  192kHz at 24 bit max - more than this would be overkill, and would hurt other capabilities without benefit
>  96kHz, 48kHz, 44100Hz, 22050Hz, 11025Hz for good measure
>  -there is no point resampling to a higher rate unless you are going to mix with a higher rate source. digital resampling does not increase sound quality.
>  -resampling from 44100 (CD audio) and lower to 48k or higher creates artifacts (not an even multiple)
>  -more processing power/bandwidth is available for effects/additional channels at lower sample speeds. halving the sample rate doubles the processing power available per sample.
>  48 bit fixed point internal DSP for best accuracy
>  all samples converted to 48 bit fixed point for internal processing
>  -there should be no data loss from this conversion
>  -if the hardware is efficient:
>   -there should be negligible performance penalty for conversion
>   -there should be no performance penalty for using the higher bit depth
>  -simplified design if all DSP functions and codecs use the same format
>  -downsampling from 48 to 24 bit for output is trivial if implemented in hardware
> 
> 
> World clock
>  world master capable
>  may also use external world clock
>  -card can repeat clock to host system and breakout boxes
>  if no dedicated world clock wiring is desired or possible, soft world clock may be implemented
>  -ie card and each peripheral generate their own clock and a periodic sync signal is provided over data channel. see below.
>  -unit may not be able to run at full speed due to timing constraints/clock skew in this case. not acceptable for live work, but OK for lower markets.
> 
> 
> Virtual back plane for maximum flexibility (any input may be mapped to any output with any filtering/effects)
>  external effects box can therefore be patched in at any location, if desired
>  volume controls are 10-12 bit analog inputs
>   sample at 20Hz?
>   volume control sampling does not need to be synchronized to any world clock
>  mutes are 1 bit input arrays. same sampling as above.
> 
> 
> I/O
>  card is purely digital
>  all analog and most digital I/O is in breakout boxes. see below.
> 
> Analog
>  inputs and outputs are discrete from each other (no dual I/O jacks to toast a mic with)
>  powered outputs are discrete from line outputs
>  1/8", 1/4", RCA, balanced XLR as appropriate
>  inputs
>   digitally controlled analog gain or preamp for each channel
>   analog prefilters to reduce digital aliasing
>   digital post filter? (cropping excess digital bits is trivial)
>  outputs
>   digitally controlled output gain or postamp
>   5th or 7th order Bessel filters standard
> 
> Digital
>  optical S/PDIF in and out (5.1 audio)
>  ADAT (lightpipe) in and out (8 channel, optical)
>   does anybody have specs on this?
>   how hard is it to get interface hardware?
>   cost?
>   licencing? (this is an open design, so this could be an issue)
>  MIDI
>  CD digital audio in/out (2 channel, 16 bit, 44100, twisted pair)
>   this would be on-card, if provided
>   could be used to link to other cards
> 
> 
> Breakout Boxes
>  more than one type of box should be supportable
> 
>   5 1/4" internal/external box?
>    cheapest to build
>    shielded for internal mounting
>    line in/line out/mic/headphone/IR/MIDI
>    5.1 line out?
>    volume control input
>    may only need 100baseT if bandwidth isn't a problem
> 
>   9" (approx) external box
>    home theater/gamer
>    5.1 analog and optical in/out
>    5.1 analog speaker out (power amp)
>    (5.1 analogs can be configured as 3 stereo pairs, or 6 mono)
>    IR/MIDI/mic/headphone
>    software controlled AM/FM radio tuner?
>    LCD display?
>    digital spectrum analyzer display?
> 
>   19" rack mount (someone with experience could probably give better layout)
> 
>    I/O patch board
>     60-80 ports
>      1/4", balanced XLR (with switchable phantom power), headphone
>     1-2 volume controls per column
>     ADAT in/out
>     MIDI
>     world clock in/out
>     1000baseT
> 
>    Control box
>     8-16 ports
>      1/4", XLR (with switchable phantom power), headphone
>     ADAT in/out
>     MIDI
>     world clock in/out
>     32 volume control sliders with mutes (2 banks of 16)
>     4 master volume sliders with mutes (same as above, just labelled differently?)
>     knob switches? (to select option or backplane presets, etc)
>      2 16 pos switches could be encoded in a byte or 4 4 pos switches, etc
>     digital spectrum analyzer display? (also a programmable output)
>     -this would suggest an equalizer somewhere would be in order too :)
>     peak/RMS volume readouts? (which they are is a setting)
>     1000baseT
> 
>  more than one box at a time should be supported
>  master can command boxes to forward streams to each other directly?
>  multi master?
>   ie more than one card connected to a group of breakout boxes and each other
>   more complex design
>   allows cards to talk to each other directly or share I/O resources
>  1000baseT connection
>   NOT TCP/IP or IPv6 - should NOT be WAN routable
>    don't need the extra overhead
>    somebody is going to want to use the same switch their internet connection goes through....
>  all analog audio channels are 24 bit
>  volume control channels are 10-12 bit
>  mute controls are bit arrays
>  requires in-box microcontroller
>   as much work as possible should be done in hardware
>   minimal processing requirements due to simple protocol
>   ECC encode/decode/fixup is a large part of workload
>   no DSP capability, other than perhaps hardware filters
>    any digital filtering should be done by Master unit
>   simple remote commands
>    box detection broadcast (true PnP)
>    per channel input signal forwarding (either to output on same box, output on other box, or to Master)
>    world clock mode selection
>    set gain controls
>    box identification
>     manufacturer
>     model
>     serial number(optional)
>     I/O count/descriptions
>     read current settings
>   main load is data stream
>    latch and marshal input signals for transmit (controlled by world clock)
>    unmarshal packets to output signal latches
>     2 stage latch stepped by world clock
>   lesser load is volume/mute update stream. same profile, just lower bandwidth
> 
> 
> I/O bandwidth
>  192kHz at 24bit is 576000 B/s
>  48kHz at 24bit is 144000 B/s
> 
> max channels for 24 bit audio
>                 192kHz  48kHz
> 10baseT         1       6
> 100baseT        17      69
> Firewire        69      277     (400MHz)
> 1000baseT       173     694
> 
> 100MHz could barely handle 17 channels @ 192kHz
> if you add ECC (usually a good idea) it would be even less
> Firewire can handle up to 69 channels (less for ECC), but protocols/drivers are a mess
> -how much does firewire hardware cost compared to 1000baseT? how to get?
> -Firewire2 at 800MHz might be a possibility, but again, cost/availability?
> 
> 
> Master Unit
>  1/2 height 1/2 length card
>  PCI or PCIe form factor
>   PCIe
>    should be main focus
>     offers higher bandwidth/lower latency than PCI
>     common on newer machines
>     by the time this gets to market, this will be the dominant standard
>    x1 should be fast enough
>   PCI
>    provided for legacy support
>    large current install base
>    limited lifetime
>  1000baseT external connector
>  100 or 1000baseT internal connector (depending on cost and whether the 5 1/4" box needs 1000baseT)
>  world clock in/out (to connect to another card in the same computer)
>  ADAT I/O?
>  5.1 optical out?
>  RAM
>   32-64 MB (128?)
>   DDR
>   dual channel?
>  CPU
>   200MHz minimum
>    can we do 300MHz, or even 400?
>    overclockable with active cooling?
>     3rd party fan/water cooling mounts
>   dual core?
>   RISC like instruction set
>   48 bit fixed point DSP instructions or DSP farm
>   8-32 bit integer math (48 bit integer math?)
>   bitwise functions
>   should be efficient for compression/decompression using various codecs
>   32 bit address path so memory is upgradeable just by modifying the PCB
>    I/O controls/registers should be separate bus, so memory map is linear
>    minimal onboard boot loader, if required. all software is loaded from host system
>   separate data and instruction L1 caches
>   MMU so codecs run in own memory, don't direct have access to hardware
>    necessary for buggy or untrusted codecs
>   DMA to access host computer memory
>   accelerated task switching
>    multiple register files?
>  OS
>   embedded Linux to start with (at least until design is proofed)
>   a true RTOS would be preferable
>    multi-tasking
>    SMP capable if CPU is dual core
>    zero copy IO for performance
>    will take a while to write :P
>     maybe hack Linux? that is what it is for, after all
>  on board watchdog timer?
>   good if she locks up
>   can be used as host computer watchdog timer as well
>  hardware random # generator?
>   can be used for white noise production
> 
> 
> 3 profiles of signal handling
>  Live
>   this is usually going from an analog input to an analog output
>   highest priority in processing
>   minimal buffering to reduce delay
>    needs to be < 20ms, even if signal is passed through card more than once
>     eg input -> card -> external effects box -> card -> output)
>   this puts the highest load on the card
>   critical for audiophiles
>   may be important for gamers and hobbyists
>   minimal importance for home theater
>  Real-time
>   this could be recording or playback
>   precise timing is only necessary at source or output, respectively
>   double buffering to improve efficiency is an asset
>    even 500ms delay playing an MP3 doesn't matter. prebuffering several seconds wouldn't hurt anything either.
>    video sync isn't affected if the timing signal back to the computer is generated AFTER the decompression codec output buffer
>    double (or more) buffering during recording is critical to prevent data loss, especially if the audio is being compressed in real time
>  Transcode
>   lowest priority - this could be done entirely using time left over from the other operations
>   buffering to improve efficiency is an must
>   delay, clock skew, etc don't matter
>   could be used with non-audio data with appropriate codecs (SETI at HOME, anyone?)
> 
> 
> If I have missed or messed up anything, that is just me being me.  Please feel free to correct/mock/browbeat as appropriate. :)
> 
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> 
> 




More information about the Linux-audio-dev mailing list