[Spice-devel] Sound rework 0/0

[Fabio Fantoni]

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 at lists.freedesktop.org
> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4510 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20131029/963a94d3/attachment-0001.bin>