[Spice-devel] [PATCH] make celt to be optional

[Gerd Hoffmann]

  Hi,

> From 44.1 you'd still need to externally resample to one of 8, 12, 16, 24,
> or 48k - but you can put any of those rates in, and take any of those out
> again without them needing to be the same.  So only endpoints actually
> needing an 'oddball' rate would need a resampler to get them, they wouldn't
> force the other end to also support and use that rate as well.

Ok, so we must resample 44.1 anyway before encoding.

>> Is that true for celt 0.5.1 too btw?
> 
> Unfortunately no.  For celt you compose your own 'mode' and that mode
> essentially defines the bitstream.  Different modes make different
> bitstreams so you need to decode with the same mode you encoded with.

Ok, so it's easiest to simply not touch celt.

So, how to go forward?  spice-server gets a 44.1 stream from qemu today.
 I think we should switch that to 48k.  Needs changes in the sound
interface and in qemu.  spice-server needs to be able to handle both old
(44.1) and new (48k) qemu.  spice-server also needs to be able to handle
clients with different capabilities (possibly even at the same time if
multiclient is enabled, not sure multiclient support covers the sound
channel though).

So we'll need resampling support for both 44.1 -> 48k and 48k -> 44.1.
In the end we'll have the following cases, at the server side:

  old qemu, no caps [-> 44.1 pcm]
  pass through pcm audio data as-is

  new qemu, no caps [-> 44.1 pcm]
  resample 48k -> 44.1

  old qemu, cap_celt
  encode 44.1 celt

  new qemu, cap_celt
  resample 48k -> 44.1, encode 44.1 celt

  old qemu, cap_opus
  resample 44.1 -> 48k, encode opus

  new qemu, cap_opus
  encode opus

We might want to add:

  new qemu, cap_pcm48k
  pass through pcm audio data as-is

Long-term (new spice-server, new qemu, clients supporting opus) we'll
operate at 48k on the whole chain without resampling needed in the
spice-server.

Client side is easy, we just decode stuff and pass it on to pulseaudio
to deal with it.

cheers,
  Gerd