>> When spice-server detects that qemu hasn't been updated and is still using
>> 44.1, then it could advertise it does not support Opus and only use celt
>> until qemu is recompiled.
>
> Yep, that will work too. And it will probably handle the transition
> with less code.
That would sure be easier to implement. It would mean that a new spice
server and client would be mandatory when using the new qemu.
Otherwise, there would be no sound (I believe falling back to raw mode
won't work, as raw mode is based on a 44.1 driven frame size).
If we add an option to qemu, then we could start a new qemu in
a celt only mode for some form of backwards compatibility.
Is that an acceptable limitation?
The alternates, as far as I know, are:
1. Resample anything coming in at 48K to 44.1 if we need to
This should be straight forward, but is a fair bit of
extra processing, and would require finding some GPL compatible
resample code and adding it to the project.
2. Modify qemu to change the device sample rate dynamically
This seems like it should be possible. I'm working up a
hack to try it (basically, we regen the rate at voice_enable
time). This seems to fly in the face of 'normal'
practice, so there is probably something horrible wrong with it.
But it's fun to play :-).
If the 'require them to use new spice if they use the new qemu' option
is really viable, that sure would be a heck of a lot easier <grin>.
Cheers,
Jeremy
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel