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

On Wed, 03 May, 2006 at 03:37AM -0400, spikethehobbitmage@email-addr-hidden 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!
>
>
>
Received on Thu May 4 00:15:04 2006