| DSP Blockset | |
Send audio data to a standard audio device in real-time (Windows only).
Library
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 contain audio data from a mono or stereo signal. A mono signal is represented as either a sample-based scalar or frame-based length-M vector, while a stereo signal is represented as a sample-based length-2 vector or frame-based M-by-2 matrix. If the input data type is double, single, or int16, the block conveys the signal samples to the audio device using 16 bits. If the input data type is uint8, the block conveys the signal samples to the audio device using 8 bits.
sound(u,Fs,bits) % Equivalent MATLAB code
Note that the block does not support uint16 or int8 data types. The 16-bit sample width requires more memory but in general yields better fidelity. The amplitude of the input should be in the range ±1. Values outside this range are clipped to the nearest allowable value.
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 Td seconds worth of signal data to the device (hardware) buffer, where Td 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, Tb, 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 (i.e., 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.
where Fs is the sample rate of the signal and Mo 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.
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 the Simulink documentation and Delay and Latency for other ideas on improving simulation performance.
Dialog Box
0 specifies the smallest possible initial delay, a single frame.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.See Also
| From Wave Device |
DSP Blockset |
| To Wave File |
DSP Blockset |
sound |
MATLAB |
See Exporting and Playing WAV Files for related information.
| | Toeplitz | To Wave File | |