Il 16/10/2013 20:56, Jeremy White ha scritto:
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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel
Thanks for works on improve of audio part and Opus support, are there news about this series of patches?
Attachment:
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel