[Spice-devel] RFC on sound codec refactoring

[Marc-André Lureau]

----- Original Message -----
> >> 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 don't think we need to change the rate dynamically. Also, doing this depending on guest state would mean you would have to also handle resampling in spice server, to avoid (possibly large) gaps of different rate.

>
> >
> > 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.

The client, old or new, should be able to adapt to the above.

> 
> 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.

works for me ;)