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

[Ron]

On Wed, Jun 13, 2012 at 01:49:59PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >> IMHO we should undust Alons opus patches *now* and get stuff ready.
> >> Given the sample rate issue a bit more work that just switching the
> >> codec, so it will need some time anyway.
> > 
> > I replied to Ron privately

Yeah, I only took that part off the list to avoid distracting an otherwise
busy thread with what seemed like a 'side issue' at the time, that Alon and
I could clarify and bring back to it again later.  You're welcome to quote
or forward any of that if you like.

> > but let me repeat my problems last time
> > around. They are certainly not unsurmountable, I just didn't have the
> > right motivation, that Ron provided right now (i.e. saying that we might
> > be carrying a breakable package):
> >  We have a fixed sample rate of 44100 in spiceaudio, as defined by spice
> >  server. I guess I could try to either resample (didn't want to go down
> >  that path last time since it seemed a waste of cpu for something I
> >  could just adjust upfront in the guest/client for playback/recording)
> >  or change it.
> 
> It's a waste indeed, and I think the best long-term option is to go for
> 48 kHz.  Real hardware does this, virtual qemu hardware does this, and
> using it on the complete path from guest to spice client makes perfect
> sense.

The 44.1 rate is what CD audio uses (for amusing reasons related to the
frame rate of video cassettes originally used for storing digital audio)
but it's becoming increasingly isolated in that for modern digital audio.

Lots of hardware these days doesn't handle that rate natively, and needs
it to be resampled to/from 48k anyway - so if you don't need 44.1 for
other reasons of your own, then roundtripping through it is a good thing
to avoid.

> I suspect there is no way around resampling support though.  We'll need
> it for compatibility reasons, so sound keeps working if only one side is
> able to operate at 48 kHz.

The ability to resample OTOH probably isn't a silly thing to have, and
can be fairly easily set up as an inline filter that is switched out
if you really don't need it.

Just to be clear about this though, there is actually no reason that
both sides of the link need to use the *same* sample rate, even without
a resampler.

For instance you can perfectly well push an 8kHz stream into opus, and
decode that as a 48kHz stream at the other end, or vice versa, without
resampling, for any integer fraction of 48k down to 8.  Or just because
one end needs to resample from 44.1 to 48, it doesn't prevent the other
side from still natively using 48k etc.

So this isn't something you strictly need to coordinate between endpoints
unless they have their own requirements to do that.  The common thing
they negotiate is "we both speak opus", while the sample rate they see
at their own ends can be entirely up to them to decide, without needing
to agree on a common rate, or to share information about the rate that
they chose.

Once encoded in opus, there is no "sample rate" anymore, except what you
choose to decode it as, at the time you choose to decode it.

Does that make sense, or did I just make this sound even more confusing
than it really is ;?


 Cheers,
 Ron