[Spice-devel] RFC on sound codec refactoring

[Jeremy White]

>> Attached is a patch that suggests my idea.  I've done some hacks,
>> and it seems 'safe' to adjust the rate on the fly like this.
>
> line_out_ctl is driven by guest. Why would you change the rate when the device start/stop a stream? I don't think that's the right approach.

Well, if you're going to change the rate dynamically,
you've got to pick a point to do that.  My reading of the code
suggested that enable/disable was a point where the
buffering was clean, and a rate switch would be safe.

The alternate would be to add a callback of some kind,
so the spice server would call into qemu code when a
client attaches.  That may be a superior approach; but it was
harder for me to eyeball the code and feel I could be sure
to do it safely.

>
> I think the suggestion by Gerd & Christophe should be enough.
>
> If qemu is old, it should use 44.1 celt only.
> If qemu is new, it can use 48 celt or opus.
>
> This doesn't have to change dynamically, the client should be able to adapt to any of these situations.

Yes, a new client should be fine either way.  It's the old clients that
will break with this approach.  That is, an old client
running against a new qemu will need to have no sound.

But I'm muddying things; I'm playing with options that we may not
need.  It should be straight forward to add a resampling option, or
even my crazy dynamic resampling option, to a base implementation.

I'll go work on the base implementation so we can talk about something
tangible.

Cheers,

Jeremy