Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • [PENDING]  For sensors that need to virtualized the SCMI protocol SHALL be used to expose sensor data from a sensor subsystem to the virtual machines.


5.x Audio


Notes:

Proposal made to VIRTIO, waiting for comments.
Spec says how the HV can report audio capabilities to the guest.  Input/output   (microphone/speaker) what format the stream support.

Formats - sample format, it must be PCM, how many bits, and num channels,  sampling rate (frame rate).

These capabilities are defined for each stream.  One VM can open multiple streams towards the HV.  A stream can include more than one channel (interleaved, according to previous agreement of format)

Virtual audio card does not support any controls (yet).   Either guest does nothing with volume - mixing/priority is somehow implemented by HV (or companion VM, or external amplifier, or...)

There is no volume control in the VIRTIO interface .   Software control (scaling) of volume can of course be done in guest through user-space code doing this.  
Or you can process/adjust volume on the host side (it unspecified here how to do that).

Control API to set volume/mixing/other on the hypervisor side. In an ECU, the volume mixing/control might be implemented on a separate chip, and the details of that control interface is not specified here.

Challenges include the real-time behavior, keeping low latency in the transfer, avoiding buffer underruns, etc.

Consequences of ASIL encumbered features?  → typically this is done separately by preloading chimes/sounds into some media hardware and triggered through another event interface.

Some VIRTIO feature flags.


Requirements:

  • Implement feature flag foo
  • Implement feature flag bar


5.x Media codec 

TODO Hardware-assisted codecs

...