You ask for tiny appliance that have very good D/A and A/D. You could take what ever cheap ARM processor that run linux, use the AC97 output of some SoC based on the ARM cpu with very good analog convertor. Then you could run VLC on it, control by a remote control or an other computer. But you will have some problem for latency but that could be controled by using the less costly protocol.
That could cost around 200. It could be also used to listen to internet radio. Nicolas Boulay > On Wed, Apr 05, 2006 at 04:47:07PM +0100, Dieter wrote: >> In message >> <[EMAIL PROTECTED]>, "Timothy >> Miller" writes: >> > > and list; I see a lot of legacy slots being discussed. PCI ect, is a >> thin= >> > g >> > > of the past. I am dead serious. IMHO you really *NEED* to be >> thinking >> > > PCI-Express x1 if that will handle your bandwidth, or possibly x4, >> or eve= >> > n >> > >> > We're not targetting anything at all. Sometimes I use "PCI" in the >> > abstract to refer to any peripheral bus. >> >> With an external box, consider Ethernet, Firewire, maybe USB. >> Avoid the PCI vs PCIe vs whatever problem. Leave the computer >> with its accustic and electrical noise in the next room. > > This idea seems to me to be the key concept. The "sound card" idea > is OK for consumer-level stereo audio, gaming, and so on. For truly > high-end professional recording hardware, the sound equipment doesn't > belong > in the computer, and the acoustically noisy computer doesn't belong in the > studio control room -- unless you want to design a specialized one, with > big > heat sink assemblies outside the case, cooled by natural convection. > High speed Ethernet, or one of the other high-speed serial links, > breaks the dependencies between the expensive audio hardware and the > computer's interface standards. Besides getting the low-level analog > hardware out of the electrically noisy computer environment, it > future-proofs it. It cuts it loose from the constant standards churn in > PCs. > Also, it would get rid of an expensive and bulky piece of field > recording equipment: the snake. Instead of a passive connector box on the > stage, connected to the recording engineer's station by hundreds of feet > of > large, heavy, and expensive custom multichannel shielded cable, there > would > be a little Cat 6 Ethernet cable running from the engineer's console to an > active A/D conversion unit on stage. Even better, a media converter box > to > change between UTP and free-space optical communication would get rid of > the > whole hassle of laying a cable the length of the auditorium and having the > audience walk on it or trip over it. I envision a box with some 1/4" > jacks > for direct mike input, and some digital input jacks for digitized stage > mikes. Input boxes should be chainable through the Ethernet interface, so > that channel expansion is just a matter of plugging more audio input boxes > into the hub. > This piece of gear could outlive many generations of computer > technology. It wouldn't need drivers as such; just a set of standards for > the protocols to be used over Ethernet. This makes it a lot easier to > support as a cross-platform peripheral. Since multichannel audio > recording > is fundamentally time-division multiplex, TCP/IP doesn't really belong in > the system. ATM over Ethernet might be a better fit. Running multiple > digitizer boxes over a single subnet would be basically a problem in time > slot assignment. > Back-of-the-envelope numbers: if a single audio sample is encoded as > a 32-bit data word, and the sample rate is 192K/S, then the data rate per > channel is around 7.68Mb/s with ECC overhead. Throw in another 20% for > packet overhead, and the rate is maybe 9.6Mb/S. So a 100Mb/S Ethernet > cable > would max out at 10 channels, while a 1Gb/S path could carry 104 channels. > Another necessary piece of hardware is an Ethernet-connected control > console. The mouse-keyboard-monitor concept is just too clumsy for > anything > as interaction-heavy as sound mixing. A recording engineer needs a real > mixing board, with real knobs on a per-channel basis. > The next thing to figure out is partitioning the functions between > the A/D box, the engineer's console, and the computer. Many setups might > not need the computer at all. After all, big disks are cheap enough now > to > pop into the engineer's console. > Now: what's going to sit between the raw serial data stream from the > A/Ds and the Ethernet interface? Maybe a power-efficient laptop CPU and a > big EEPROM to hold the firmware? Maybe a mostly-hardware implementation > in > an FPGA, to do simultaneous sample-and-hold? It's gotta be done with no > moving parts and a light power drain, because it's lying on the floor > right > under the mikes. > What I really don't see is where there's a place in any of this for > an open design hardware project. What isn't off-the-shelf generic parts > is > really painstaking system design, involving knowing high-end audio design > practice in detail, chasing down a lot of second and third order errors > and > noise sources, and getting the ergonomics and packaging right. This > favors > career specialists. > > On the other hand, we understand very well what a computer graphics > card is supposed to do. We don't need to do a lot of market research > before > we can even begin to propose realistic concepts. > > > BTW, there's no such thing as a 32-bit DAC or A/D. With > thermodynamic noise in the range of a microvolt for a low-impedance mike, > that would require a full-scale signal level of +/-2148 volts. Aside from > that, physical components aren't stable enough for much over 20-bit > accuracy. What might make sense is floating poing with a 24-bit mantissa > and an 8-bit exponent; that would avoid the need to adjust levels during > mike check; it would facilitate automatic level control without > sacrificing > dynamics. > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
