vStream C Implementation.

vStream C Implementation.

The vStream C implementation provides the CMSIS-Driver vStream interface for the AVH FVPs. The C driver communicates with the FVP simulation layer by reading and writing VSI peripheral registers, which the corresponding Python scripts interpret and forward to the Audio or Video Server.

The following files implement the vStream C driver:

Driver configuration

The vStream driver behavior is controlled at compile-time through configuration header files located in ./interface/vstream/config/. These files are copied to the project and can be modified to adapt the stream parameters to the application requirements.

Audio stream configuration

Configuration options for the audio vStream drivers are:

When AUDIO_IN_FILENAME / AUDIO_OUT_FILENAME is set to a non-empty string, the driver streams audio data from or to the specified WAV file. When left empty, the streaming device index (AUDIO_IN_DEVICE / AUDIO_OUT_DEVICE) is used to select an audio hardware device, where -1 selects the system default device.

Video stream configuration

Configuration options for the video vStream drivers are:

When VIDEO_IN_FILENAME is set to a non-empty string, the VideoIn driver reads frames from the specified video or image file. When left empty, the device index (VIDEO_IN_DEVICE) selects the camera to use, where -1 selects the system default device.

For VideoOut, when VIDEO_OUT_FILENAME is set to a non-empty string, frames are written to the specified video file. When left empty, frames are displayed in an OpenCV window on the host.

Audio streaming operation

The audio streaming flow for input and output follows a common pattern based on the CMSIS-Driver vStream API:

1. At FVP model start or reset, the VSI peripheral calls init() in the relevant Python scripts. For AudioIn this is arm_vsi0.py, for AudioOut arm_vsi1.py. Each script starts the Audio Server (vsi_audio_server.py) in the background and establishes a TCP connection to it.
2. The application calls Driver_vStreamAudioIn.Initialize() or Driver_vStreamAudioOut.Initialize(), registering an optional callback function for stream events. The driver writes the audio configuration (channels, sample bits, sample rate, device or filename) to the VSI peripheral registers, which the Python script forwards to the Audio Server.
3. The application calls SetBuf() to assign a circular DMA buffer divided into fixed-size blocks. The VSI DMA is configured to transfer one block at a time, synchronized by the VSI Timer.
4. The application calls Start() with VSTREAM_MODE_CONTINUOUS or VSTREAM_MODE_SINGLE to begin streaming. The VSI Timer is programmed with an interval derived from the configured sample rate and block size to deliver one audio block per timer period.
5. While streaming, the VSTREAM_EVENT_DATA callback event signals that a completed block is available. The application calls GetBlock() to obtain a pointer to the block and processes the data, then calls ReleaseBlock() to return the block to the driver for reuse. If the application does not release blocks fast enough, a VSTREAM_EVENT_OVERFLOW event is generated.
6. When the end of the audio file is reached, the VSTREAM_EVENT_EOS event is generated.
7. The application calls Stop() to halt streaming and Uninitialize() to release resources.

Video streaming operation

The video streaming flow for input and output follows the same pattern as audio streaming, adapted for frame-based data:

1. At FVP model start or reset, the VSI peripheral calls init() in the relevant Python scripts. For VideoIn channel 0 this is arm_vsi4.py, for VideoOut channel 0 arm_vsi5.py. Each script starts the Video Server (vsi_video_server.py) in the background and establishes a TCP connection to it.
2. The application calls Driver_vStreamVideoIn.Initialize() or Driver_vStreamVideoOut.Initialize(), registering an optional callback function for stream events. The driver writes the video configuration (frame width, height, frame rate, color format, device or filename) to the VSI peripheral registers, which the Python script forwards to the Video Server. The Video Server performs any required color space conversion and frame resizing.
3. The application calls SetBuf() to assign a circular DMA buffer sized to hold one or more video frames.
4. The application calls Start() with VSTREAM_MODE_CONTINUOUS or VSTREAM_MODE_SINGLE to begin streaming. The VSI Timer is programmed with an interval derived from the configured frame rate.
5. While streaming, the VSTREAM_EVENT_DATA callback event signals that a complete frame is available. The application calls GetBlock() to obtain a pointer to the frame buffer and passes it to the processing algorithm, then calls ReleaseBlock() to return the buffer to the driver for reuse. If the application does not release frames fast enough, a VSTREAM_EVENT_OVERFLOW event is generated.
6. When the end of the video file or image sequence is reached, the VSTREAM_EVENT_EOS event is generated.
7. The application calls Stop() to halt streaming and Uninitialize() to release resources.