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