文件列表:

VDK (0, 2006-09-30)
VDK\PipelinedAudioDriver (0, 2006-09-30)
VDK\PipelinedAudioDriver\AD1885.cpp (8126, 2006-05-26)
VDK\PipelinedAudioDriver\AD1885.h (1708, 2006-05-26)
VDK\PipelinedAudioDriver\AudioMsg.h (336, 2006-05-26)
VDK\PipelinedAudioDriver\Codec.cpp (5910, 2006-05-26)
VDK\PipelinedAudioDriver\Codec.h (1759, 2006-05-26)
VDK\PipelinedAudioDriver\Echo.cpp (3023, 2006-05-26)
VDK\PipelinedAudioDriver\Echo.h (750, 2006-05-26)
VDK\PipelinedAudioDriver\EVT_IVG8.asm (5211, 2006-05-26)
VDK\PipelinedAudioDriver\ExceptionHandler-BF535.asm (1788, 2006-05-26)
VDK\PipelinedAudioDriver\InitCodec.h (1649, 2006-05-26)
VDK\PipelinedAudioDriver\Input.cpp (3618, 2006-05-26)
VDK\PipelinedAudioDriver\Input.h (797, 2006-05-26)
VDK\PipelinedAudioDriver\Output.cpp (3309, 2006-05-26)
VDK\PipelinedAudioDriver\Output.h (764, 2006-05-26)
VDK\PipelinedAudioDriver\PipelinedAudioDriver.dpj (9372, 2006-05-26)
VDK\PipelinedAudioDriver\PipelinedAudioDriver.vdk (3380, 2006-05-26)
VDK\PipelinedAudioDriver\Relay.cpp (5780, 2006-05-26)
VDK\PipelinedAudioDriver\Relay.h (797, 2006-05-26)
VDK\PipelinedAudioDriver\VDK-BF535.ldf (23566, 2006-05-26)
VDK\PipelinedAudioDriver\VDK.cpp (9248, 2006-05-26)
VDK\PipelinedAudioDriver\VDK.h (5983, 2006-05-26)

An Audio Driver Example for the ADSP-BF535 EZ-Kit Lite * A device driver for the AD1885 Audio Codec * Full duplex operation at 48KHz * Supports "split open" behaviour * Simultaneously open by one thread for reading and another for writing * Uses the "pipelined" I/O model * A digital audio feedthrough application * Copies ADC input to DAC output * Exploits the pipelined driver semantics * Uses one thread for input and another for output * Uses the messaging API to pass audio data between threads * Uses a memory pool to store audio data * Each block holds 1 millisecond of audio The Example AD1855 Device Driver * Is intended to illustrate: * The object-based device driver model (introduced in VisualDSP++ 3.0) * Split-open operation * Device activation from an ISR * Use of DeviceFlags for I/O completion * A simple framework for 2-level pipelined I/O * Is not intended to be: * A comprehensive guide to AD1885 operation * The only (or most efficient) solution possible * A typical DMA device * A highly time-critical example * 6250 DSP cycles per sample doesn't present any latency problems The Example Feedthough Application * Is intended to illustrate: * Handling each direction of a full-duplex device by a separate thread * Utilization of pipelined I/O semantics * Use of a memory pool for message payload allocation * Use of message return for flow control and message/buffer recycling * Is not intended to be: * The only possible structure * Output could originate empty messages, as in the Producer-Consumer example provided with VisualDSP++ 3.1 * Messages and buffers could be destroyed and reallocated instead of being recycled The Device Driver Model * Traditional synchronous read/write model has limitations for realtime I/O * Where does the data come from/go to when the thread isn't blocking? * Buffering within the device driver is wasteful of memory space, processing time and bandwidth * Memory-to-memory copying can limit throughput * Fully asynchronous I/O complicates tracking of I/O completion * Would require additional Kernel support * Pipelined Driver semantics permit efficient double (or multi-) buffering without excessive complexity * Well suited to streaming realtime I/O Synchronous I/O Vs. Pipelined I/O of Depth 2 * Synchronous read/write N * Queues buffer N for input/output * Blocks until I/O on buffer N completes * Returns result of op. N * Can only have zero or one buffers queued * No user buffer available while thread is busy * Driver must provide additional buffering * Pipelined read/write 0 * Queues Buffer 0 for input/output * Doesn't block * Returns zero * Pipelined read/write N * Queues buffer N for input/output * Blocks until I/O on buffer N-1 completes * Returns result of op. N-1 * A zero-sized buffer blocks until the pipe is empty Managing Latencies In Device Drivers * Do the minimum necessary in ISR * Dependant on tolerance to service latency * May be as little as calling VDK_ISR_ACTIVATE_DEVICE_() * e.g. if DMA chaining is being used * Time-critical devices may need more work to be done in ISR * i.e. if activation overhead is unacceptable * Do as much as possible in activation handler * C/C++ environment * Access to driver instance variables * But beware of variability in latency * Only PostDeviceFlag() on buffer completion * Avoids extra thread context switches

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：