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

[Michael Tokarev]

On 12.06.2012 15:35, Alexander Larsson wrote:
> On Tue, 2012-06-12 at 14:31 +0400, Michael Tokarev wrote:
>> On 12.06.2012 13:15, Alexander Larsson wrote:
>> []
>>> Its not incompatible, like I i said in my "(Well, .." part above. But
>>> what it means is that it will send audio as PCM instead of compressing
>>> it. This is much larger, and will cause anyone using the debian spice
>>> client to connect to a spice server (even one that supports celt) to use
>>> much more bandwidth due to this. Its not very obvious that the reason
>>
>> Why do you think it is really that bad?  When used in a LAN, bandwidth
>> doesn't matter, and it will even work a tiny bit better due to less
>> cpu usage for encoding/decoding.  It may matter for slow/long Internet
>> links, but these are much less important for audio.  Also, audio does
>> not come alone usually (except of a few windows sounds), it usually
>> comes together with video (ie, movies etc), which has their own
>> requiriments which are much stronger than even raw audio.
>>
>> I'm not saying celt or other codec is bad or not needed, something
>> is definitely worth to have to be able to transmit audio cheaply,
>> but it is not the first priority thing for sure.
>>
>> Much more important is to have good visual expirence, and this is what
>> spice is all about, and this is something what is not changed by this
>> patch.
>>
>> Do you not agree?
> 
> I don't really agree. Its true that if you have unlimited bandwidth,
> then bandwidth doesn't matter. But I don't think in practice this is
> true, as bandwidth always has some limits in reality. Its possible that

Yes, in practice there's always some limits.  For "standard" CD-quality
audio on a LAN, -- which I mentioned above -- this limit is more in
"unlimited" category (since PCM/RAW stream is small even for 10Mbps
network, but such networks don't exists on LANs anymore).

And yes, when you connect to it over 'net, esp. over long-distance links,
that limit becomes much more limiting.

> it works fine in some situations, but its also quite possible that its a
> deal-breaker in some others, and we have no data to substantiate the
> claim that it doesn't matter (in fact, it seems unlikely since the
> developers spent time and energy to implement audio compression).

Yet again, I didn't say it does not matter, I especially mentioned
this in previous email.

> Spice is very much about more than just pixels, that it does more than
> graphics (usb, sound, audio-video sync, clipboard, etc) is an important
> part of why Spice is better than other solutions. In fact, our support
> of movies by using compressed video and audio is a pretty important
> selling point of spice.
> 
> The main thing I disagree with this change is that you change how spice
> works, making act differently than its creators intended, due to a
> packaging technicallity. You decide that spice users are not interested
> in low-bandwidh audio, without asking and without telling them. (I'm
> sure it'll be mentioned somewhere, but its unlikely that most users will
> see it.)

Well.  Alternative I have is to not provide spice in Debian at all.  This
includes qemu/kvm packages shipping without spice support, so even if you
add spice client built from sources, it wont help.  This includes such
things like xspice.

Does this work better for you?  For users?

Thanks,

/mjt