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

[David Jaša]

Ron píše v Pá 15. 06. 2012 v 16:29 +0930:
> 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.  

Celt is already good enough in my experience in this regard and I don't
expect Opus to be any worse.

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

IIRC this was the case, they wanted to use it to feed outputs from some
tools to a software run in the guest and they liked that the spice audio
support was ready to use for them, apart from not allowing codec choice.

David

> 
>  Ron
> 
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24