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

[Ron]

On Thu, Jun 14, 2012 at 01:58:55PM +0200, David Jaša wrote:
> Christophe Fergeau píše v Čt 14. 06. 2012 v 12:31 +0200:
> > On Thu, Jun 14, 2012 at 10:14:36AM +0200, Alexander Larsson wrote:
> > > However, that is imho a different issue than the celt051 support. A new
> > > release of spice client and server supporting opus does not magically
> > > make old servers and client disappear, so it would still be the case
> > > that e.g. debian spice client would get lame audio performance if
> > > connecting to say a RHEV spice client, or if some old client connects to
> > > a server running on debian. In time, it would perhaps make sense to drop
> > > celt051 support, but its seems pretty bad to release a client binary
> > > that doesn't do audio well with all currently existing deployed servers.
> > 
> > It all depends if we consider remote SPICE access with limited bandwidth and
> > with audio needed will be an important use case that must run as good as
> > possible. In my opinion, sound is most of the time not the most important
> > thing if what you want is a remote desktop. It also won't be really
> > noticeable on LAN, or in GNOME Boxes use case, ...
> > 
> > What I gather from this thread is that we don't want anyone to use the
> > fallback PCM code, which means we should deprecate it if that's really what
> > we want... Maybe the clients could be patched to stop advertising raw PCM
> > support? I don't know if no audio at all is more acceptable than not doing
> > audio well in some cases.
> 
> There was an interest in lossless audio for some medical application
> some time ago so support for explicit codec choice (and incoproration of
> FLAC or some better lossless codec, if any) would be a big improvement
> for some spice users.

I guess this kind of depends on what they mean by "lossless".

At 64kb/s, in listening tests of opus, there were a notable number of
samples where the listeners could not pick opus from the reference.

At 128kb/s, even codec developers and practiced listeners have trouble
hearing any difference from the reference samples with high quality
headphones, on all but the most pathologically difficult examples
to code.

And we expect that will improve even further in the months to come.
The decoder and bitstream are frozen, but there is still potential
for a compatible encoder to make notable improvements to quality.

So if what they want is 'transparency', then maybe opus can do this
for them all by itself.  That's not the same as true lossless if they
need to analyse the samples received - but that would be something
I'd expect to have an application specific data stream all of its own
if that was needed, rather than it using the generic audio support
of spice.

 Ron