Buffer

Buffer input sequence to smaller or larger frame size

Library:
DSP System Toolbox / Signal Management / Buffers

Description

The Buffer block always performs frame-based processing. The block redistributes the data in each column of the input to produce an output with a different frame size. Buffering a signal to a larger frame size yields an output with a slower frame rate than the input. For example, consider this illustration for a scalar input.

Buffering a signal to a smaller frame size yields an output with a faster frame rate than the input. For example, consider this illustration of a scalar output.

The block coordinates the output frame size and frame rate of nonoverlapping buffers such that the sample period of the signal is the same at both the input and output: T_so = T_si.

This block supports triggered subsystems when the block input and output rates are the same.

Ports

Input

expand all

`Port_1` — Input signal
scalar | vector | matrix

To buffer single-channel signals, input a scalar or column vector. To buffer multichannel signals, input a row vector or matrix. To buffer single-channel signals, input a scalar or column vector of the size M_i-by-1, where M_i is the input frame size.

Output

expand all

`Port_1` — Output signal
vector | matrix

The buffered input signal returned as a vector or a matrix.

When the input is a single-channel signal:

1-by-1 (scalar) — Output is an M_o-by-1 vector.
M_i-by-1 (column vector) — Output is an M_o-by-1 vector.

where

M_i — Input frame size
M_o — Value of the Output buffer size parameter

The input frame period is M_i · T_si, where T_si is the input sample period. The output frame period is $(M_{o} - L) T_{s i}$ , where L is the value of the Buffer overlap parameter and T_si is the input sample period. When you set the Buffer overlap parameter to M_o – 1, the output frame period equals the input sample period.

When the input is a multichannel signal:

1-by-N — Output is an M_o-by-N matrix.
M_i-by-N — Output is an M_o-by-N matrix.

where

N — Number of channels in the signal
M_i — Input frame period
M_o is the value of the Output buffer size parameter and can be greater or less than the input frame size, M_i. The block buffers each of the N input channels independently.

The input frame period is M_i · T_si. The output frame period is $(M_{o} - L) T_{s i}$ , which equals the sequence sample period when the Buffer overlap is $M_{o} - 1$ . Thus, the output sample period T_so is related to the input sample period T_si by

$T_{s o} = \frac{(M_{o} - L) T_{s i}}{M_{i}}$

The output has the same data type and complexity as the input

Parameters

expand all

`Output buffer size (per channel)` — Buffer size
`64` (default) | positive integer

Specify the number of consecutive samples, M_o, from each channel to buffer into the output frame.

Data Types: double | int8 | int16 | int32 | uint8 | uint16 | uint32

`Buffer overlap` — Buffer overlap
`0` (default) | integer

Specify the number of samples, L, which specifies the amount of overlap or underlap in each successive output frame.

To overlap the data in the buffer, specify a value of L in the range $0 \leq L < M_{o}$ , where M_o is the value of the Output buffer size parameter. The block takes L samples (rows) from the current output and repeats them in the next output. In cases of overlap, the block acquires $M_{o} - L$ new input samples before propagating the buffered data to the output.

When $L < 0$ , you are buffering the signal with underlap. The block discards L input samples after the buffer fills and outputs the buffer with period $(M_{o} - L) T_{s i}$ , which is longer than in the zero-overlap case.

The output frame period is $(M_{o} - L) T_{s i}$ , which equals the input sequence sample period, T_si, when the Buffer overlap is $M_{o} - 1$ .

Data Types: double | int8 | int16 | int32 | uint8 | uint16 | uint32

`Initial conditions` — Initial output
`0` (default) | scalar | vector | matrix

Specify the value of the block's initial output, in cases of nonzero latency, as a scalar, vector, or matrix.

For all cases of single-tasking operation (Simulink Coder) other than those listed in Zero-Tasking Latency, the Buffer block's buffer is initialized to the value(s) specified by the Initial conditions parameter. The block reads from this buffer to generate the first D output samples, where

$D = {\begin{matrix} M_{o} + L & (L \geq 0) \\ M_{o} & (L < 0) \end{matrix}$

The dimensions of the Initial conditions parameter depend on the Buffer overlap, L, and whether the input is single-channel or multichannel:

When $L \neq 0$ , the Initial conditions parameter must be a scalar.
When $L = 0$ , the Initial conditions parameter can be a scalar, or it can be a vector with either of these constraints:
- For single-channel inputs, the Initial conditions parameter can be a vector of length M_o if M_i is 1, or a vector of length M_i if M_o is 1.
- For multichannel inputs, the Initial conditions parameter can be a vector of length M_o * N if M_i is 1, or a vector of length M_i * N if M_o is 1.

For all multitasking operations (Simulink Coder), use the rebuffer_delay function to compute the exact delay in samples that the Buffer block introduces for a given combination of buffer size and buffer overlap.

For general buffering between arbitrary frame sizes, the Initial conditions parameter must be a scalar, which is then repeated across all elements of the initial output(s). However, in the special case where the input is a 1-by-N row vector, and the output of the block is an M_o-by-N matrix, Initial conditions can be:

An M_o-by-N matrix
A length-M_o vector to be repeated across all columns of the initial output(s)
A scalar to be repeated across all elements of the initial output(s)

In the special case where the output is a 1-by-N row vector, which is the result of unbuffering an M_i-by-N matrix, the Initial conditions can be:

A vector containing M_i samples to output sequentially for each channel during the first M_i sample times
A scalar to be repeated across all elements of the initial output(s)

For more information on latency and the Simulink^® tasking modes, see Excess Algorithmic Delay (Tasking Latency) and Time-Based Scheduling and Code Generation (Simulink Coder).

Model Examples

Streaming Power Spectrum Estimation Using Welch's Method

Showcases a block that outputs the streaming power spectrum estimate of a time-domain input via Welch's method of averaged modified periodograms.

Open Model

Buffering Input with Overlap

Buffer a two-channel input using an Output buffer size of three and four and a Buffer overlap of one.

Open Script

Block Characteristics

Data Types	`double` \| `single` \| `Boolean` \| `base integer` \| `fixed point`
Direct Feedthrough	`No`
Multidimensional Signals	`No`
Variable-Size Signals	`No`
Zero-Crossing Detection	`No`

More About

expand all

Zero-Tasking Latency

Zero-tasking latency means that the first input sample, received at t = 0, appears as the first output sample. In the Simulink single-tasking mode (Simulink Coder), the Buffer block has zero-tasking latency for these special cases:

Scalar input and output ( $M_{o} = M_{i} = 1$ ) with zero or negative Buffer overlap ( $L \leq 0$ )
Input frame size is an integer multiple of the output frame size

$M_{i} = k M_{o}$
where k is an integer with zero Buffer overlap ( $L = 0$ ); notable cases of this include:
- Any input frame size M_i with scalar output ( $M_{o} = 1$ ) and zero Buffer overlap ( $L = 0$ )
- Equal input and output frame sizes ( $M_{o} = M_{i}$ ) with zero Buffer overlap ( $L = 0$ )

Overrun and Underrun

The Buffer block cannot be used in an enabled subsystem under the following conditions:

In a multirate, multitasking environment
When the Buffer overlap parameter is set to a negative value

The Buffer block has an internal reservoir that temporarily stores data. When the Buffer block is used in an enabled subsystem, there is the possibility that the reservoir can overrun or underrun. The block implements safeguards against these occurrences.

Overrun occurs when more data enters the buffer than what it can hold. For example, consider buffering a scalar input to a frame of size three with a buffer that accepts an input every second and outputs every three seconds. If you place this buffer inside an enabled subsystem that is disabled every three seconds at t = 3s, t = 6s, and so on, the buffer accumulates data in its internal reservoir without being able to empty it. This condition results in an overrun.

Underrun occurs when the buffer runs out of data to output. For example, again consider buffering a scalar input to a frame size of three with a buffer that accepts an input every second and outputs every three seconds. If you place this buffer inside an enabled subsystem that is disabled at t = 10s, t = 11s, t = 13s, t = 14s, t = 16s, and t = 17s, its internal reservoir becomes drained, and there is no data to output at t = 18s. This condition results in an underrun.

To protect from an overrun or an underrun, the Buffer block keeps a record of the amount of data in its internal reservoir. When the Buffer block reads data, the amount of data in its reservoir goes up. When the Buffer block outputs the data, the amount of data in its reservoir goes down. To protect from overrun, the oldest samples in the reservoir are discarded whenever the amount of data in the reservoir is larger than the actual buffer size. To protect from underrun, the most recent samples are repeated whenever an output is due and there is no data in the reservoir.

Buffer

Description