[Spice-devel] Sound rework 0/0

[Jeremy White]

> The open issue, in my mind, is whether or not it is worth doing a more
> complete generalization.  That is, the current code has essentially hard
> coded requirements for the format and number of channels.  It also uses
> fairly static sizing for frame buffers.

The spice-gtk code is pretty clean; it would shift to a 'general'
snd_codec.c fairly readily.

spice/server/snd_worker.c is really quite sloppy.  There are hard coded
assumptions about formats (you've got things like size >> 2, but even
worse is that the buffers are all uint32 - i.e. a hard coded assumption
about sample size).  So this code could be generalized, but it would
require fairly radical surgery.

The spice/client code is also fairly sloppy, although it tends to do
asserts to protect most of it's assumptions.

So my instinct at this point is to not try to generalize further, and to
leave my patch series as is.

Except possibly for qemu.  Afaict, there is no pass through on that
interface.  There appears to be a hard coded assumption of rate, format,
and channels.  Now my later patch adds a function for querying and
setting the rate.

So my question is:  since I'm adding a new interface to the spice
server, should I make it more general to include all the information
(e.g. format, channels, endianness) not just frequency?

Cheers,

Jeremy