On 04/14/10 22:51, malc wrote:
On Wed, 14 Apr 2010, Gerd Hoffmann wrote:
The code does not follow neither audio(which is passable should it be
internally consistent) nor general QEMU code style (braces missing)
Will add the missing braces.
+static void *spice_audio_init(void)
+{
+ if (!using_spice)
+ return NULL;
+ return qemu_malloc(42);
Eh? The HGttG references should at least be given an explanation in
the comments.
Just need return something non-NULL here to indicate success.
Also wanted to check how carefully the reviewers are looking ;)
c. I have a really hard time following what rt clock (regardless
of monotonicity is doing here at all)
Accept audio data with the correct rate. When sending directly to the
audio device the host hardware controls this. Spice sends the audio
data off to the network, so this doesn't work. The math used by spice
here looks like a old version of the noaudio code for rate control (/me
inherited that code so I don't know for sure), which makes sense to me.
cheers,
Gerd
