To Wave Device (DSP Blockset)

Send audio data to a standard audio device in real-time (Windows 95/98/NT only).

Library

DSP Sinks

Description

The To Wave Device block sends audio data to a standard Windows audio device in real-time. It is compatible with most popular Windows hardware, including Sound Blaster^® cards. (Models that contain both this block and the From Wave Device block require a duplex-capable sound card.) The data is sent to the hardware in uncompressed PCM (pulse code modulation) format, and should typically be sampled at one of the standard Windows audio device rates: 8000, 11025, 22050, or 44100 Hz. Some hardware may support other rates in addition to these.

The Use default audio device parameter allows the block to detect and use the system's default audio hardware. This option should be selected on systems that have a single sound device installed, or when the default sound device on a multiple-device system is the desired target. In cases when the default sound device is not the desired output device, deselect Use default audio device, and enter the desired device identification number in the Audio device ID parameter. The device ID is an integer value that the block associates with the sound device. A 3-device system, for example, has device ID numbers of 1, 2, and 3.

The input to the block, u, can be a vector containing a frame of audio data from a mono signal, or a 2-column matrix containing one frame of audio data from each channel of a stereo signal. (The Stereo check box should be selected in this case.)

sound(u,Fs,bits)         % equivalent MATLAB code

The amplitude of the input should be in the range ±1. Values outside this range are clipped to the nearest allowable value.

The Sample Width (bits) parameter specifies the number of bits used to represent the signal samples sent to the audio device. Two settings are available:

8 - allocates 8 bits to each sample, allowing a resolution of 256 levels
16 - allocates 16 bits to each sample, allowing a resolution of 65536 levels

The 16-bit sample width setting requires more memory but yields better fidelity for double-precision inputs.

Buffering

Because the audio device generates real-time audio output, Simulink must maintain a continuous flow of data to the device throughout the simulation. Delays in passing data to the audio hardware can result in hardware errors or distortion of the output. This means that the To Wave Device block must in principle supply data to the audio hardware as quickly as the hardware reads the data. However, the To Wave Device block often cannot match the throughput rate of the audio hardware, especially when the simulation is running from within Simulink rather than as generated code. (Simulink execution speed routinely varies during the simulation as the host operating system services other processes.) The block must therefore rely on a buffering strategy to ensure that signal data is accessible to the hardware on demand.

At the start of the simulation, the To Wave Device block writes T_d seconds worth of signal data to the device (hardware) buffer, where T_d is specified by the Initial output delay parameter. When this initial data is loaded into the buffer, the audio device begins processing the buffered data, and continues at a constant rate until the buffer empties. The size of the buffer, T_b, is specified by the Queue duration parameter. As the audio device reads data from the front of the buffer, the To Wave Device block continues appending inputs to the back of the buffer at the rate they are received.

The following figure shows an audio signal with 8 samples per frame. The buffer of the sound board has a five-frame capacity, not fully used at the instant shown. (If the signal sample rate was 8kHz, for instance, this small buffer could hold approximately 0.005 seconds of data.)

If the simulation throughput rate is higher than the hardware throughput rate, the buffer remains at a constant level throughout the simulation. If necessary, the To Wave Device block buffers inputs until space becomes available in the hardware buffer (data is not thrown away). More typically, the hardware throughput rate is higher than the simulation throughput rate, and the buffer tends to empty over the duration of the simulation.

Under normal operation, an empty buffer indicates that the simulation is finished, and the entire length of the audio signal has been processed. However, if the buffer size is too small in relation to the simulation throughput rate, the buffer may also empty before the entire length of signal is processed. This usually results in a device error or undesired device output.

When the device fails to process the entire signal length because the buffer prematurely empties, you can choose to either increase the buffer size or the simulation throughput rate.

Increase the buffer size. The Queue duration parameter specifies the length of signal, T_b (in real-time seconds), to buffer to the audio device during the simulation. The number of frames buffered is approximately

where F_s is the sample rate of the signal and N is the number of samples per frame. The optimal buffer size for a given signal depends on the signal length, the frame size, and the speed of the simulation. The maximum number of frames that can be buffered is 1024.

Increase the simulation throughput rate. Two useful methods for improving simulation throughput rates are increasing the signal frame size and compiling the simulation into native code.
- Increase frame sizes (and convert scalar signals to frame-based signals) throughout the model to reduce the amount of block-to-block communication overhead. This can drastically increase throughput rates in many cases. However, larger frame sizes generally result in greater model latency due to initial buffering operations. (Note that increasing the audio signal frame size does not affect the number of samples buffered to the hardware since the Queue duration is specified in seconds.)
- Generate executable code with RTW. Native code runs much faster than Simulink, and should provide rates adequate for real-time audio processing.

Audio problems at startup can often be corrected by entering a larger value for the Initial output delay parameter, which allows a greater portion of the signal to be preloaded into the hardware buffer. A value of 0 for the Initial output delay parameter specifies the smallest possible initial delay, which is one frame.

More general ways to improve throughput rates include simplifying the model, and running the simulation on a faster PC processor. See Using Simulink and "Increasing Performance" in Chapter 2 of this book for other ideas on improving simulation performance.

Dialog Box

Sample width (bits): The number of bits used to represent each signal sample.
Stereo: Specifies stereo (two-channel) inputs when checked, mono (one-channel) inputs when unchecked.
Queue duration (seconds): The length of signal (in seconds) to buffer to the hardware at the start of the simulation.
Initial output delay (seconds): The amount of time by which to delay the initial output to the audio device. A value of 0 specifies the smallest possible initial delay, a single frame.
Use default audio device: Directs audio output to the system's default audio device when selected. Deselect to enable the Audio device ID parameter and manually enter a device ID number.
Audio device ID: The number of the audio device to receive the audio output. In a system with several audio devices installed, a value of 1 selects the first audio card, a value of 2 selects the second audio card, and so on. Select Use default audio device if the system has only a single audio card installed.