The endianness field used an int to represent a boolean concept, with
0 meaning little-endian and 1 meaning big-endian. This required runtime
validation to reject invalid values and made the code less readable.
Replace with a bool big_endian field that is self-documenting and
type-safe. The compiler now enforces valid values, eliminating the
need for the validation check in audio_validate_settings().
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
assert() on valid values, and handle acceptable NULL arguments
gracefully.
Note audio_driver_write() and audio_driver_read() used to return
size (with a "XXX: Consider options") when sw was NULL. Imho, it is more
correct to not pretend to have read/written anything by default in the
AudioBackend base abstract class.
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The replay infrastructure shouldn't depend on internals of audio/.
(st_sample is an internal implementation detail and could be different)
Let audio drive the audio samples recording/replaying.
Notice also we don't need to save & restore the internal ring "wpos",
all replay should care about is the number of samples and the samples.
Bump the replay version.
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Introduce a sub-class for current "audio_driver" based implementations.
Future AudioBackend implementations can do without it.
Next cleanup will actually remove "audio_driver" struct altogether and
make the subclass proper QOM objects.
Public APIs still rely on backend being an AudioMixeng. They will
assert() if not. This will be addressed later to allow other backends.
Note that the initial naming proposed for this object was AudioDriver,
however the semantics for "driver" is already overloaded and leads to
confusion, in particular with the QAPI AudiodevDriver. The defining
characteristic is of using QEMU's software mixing engine, so
AudioMixengBackend.
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Start a simple test program that will exercise the QEMU audio APIs.
It is meant to run manually for now, as it accesses the sound system and
produces sound by default, and also runs for a few seconds. We may want
to make it silent or use the "none" (noaudio) backend by default though,
so it can run as part of the automated test suite.
Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
