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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel