On Mon, 3 Feb 2020 at 20:38, Zoltán Kővágó <dirty.ice...@gmail.com> wrote: > > On 2020-02-03 11:00, Peter Maydell wrote: > > On Sun, 2 Feb 2020 at 19:39, Kővágó, Zoltán <dirty.ice...@gmail.com> wrote: > >> > >> This adds proper support for float samples in mixeng by adding a new > >> audio format for it. > >> > >> Limitations: only native endianness is supported. > > > > Could you explain a bit more what this limitation means, please? > > In general QEMU behaviour shouldn't depend on the endianness > > of the host, ie we should byteswap where necessary. > > None of the virtual sound cards support float samples (it looks like > most of them only support 8 and 16 bit, only hda supports 32 bit), it is > only used for the audio backends (i.e. host side). In > audiodev_to_audsettings we set endianness to AUDIO_HOST_ENDIANNESS, so > audio backends should always use native endian. > > So this limitation should only cause problems when an audio backend > overrides the endian setting. Wavcapture does it, but it does not > support float. Alsa, sdl, puleaudio and oss can also do it if for some > weird reason it acquires a stream with a different endianness than > requested.
Ah, right, I had missed that this is only used by backends; makes sense not to worry about non-native endianness then. If you do a respin of the patch you might add some of that into the commit message as an explanation of why the limitation isn't a significant one. thanks -- PMM
