On 10/08/2013 08:44 AM, Jeremy White wrote: >> However, I can see the record path has a fixed 44100 value, which is >> probably bogus today for != 44100 recording? > > Yah; there is a fair amount of hard coding (although I'm probably > overly biased by my time in the old client :-/). > > And, afaik, there's not a lot of testing done at anything other than 44100, > so we may find corner cases yet. For the record, I've done some probing into the effects of the hard coded 44100, and I believe it does no harm, particularly if we run at 48000. The hard coding only affects the size of the compressed celt buffer; it's computed to be this big: #define FRAME_SIZE 256 #define CELT_BIT_RATE (64 * 1024) #define CELT_COMPRESSED_FRAME_BYTES (FRAME_SIZE * CELT_BIT_RATE / 44100 / 8) which ends up being 47 :-/. Basically, the size of the buffer dictates how much compression to perform. If the frequency goes higher, that logic actually allows for a smaller buffer; i.e. we can compress the same number of samples a bit more. But in our 'worry' case, all that happens is we continue to use 47 bytes instead of 43, and do a slightly less efficient compression job. So I think we'd only have troubles if we ran well below 44100, and then only for old clients connecting to new servers, and only for record mode. So, um, <small>nevermind</small>. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel