[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU VNC Audio - All audio data null

From: agraham
Subject: Re: [Qemu-devel] QEMU VNC Audio - All audio data null
Date: Sat, 14 Jul 2012 18:10:29 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 07/14/2012 01:55 PM, agraham wrote:
On 07/14/2012 11:44 AM, malc wrote:
On Sat, 14 Jul 2012, agraham wrote:

On 07/14/2012 03:17 AM, agraham wrote:
Hi Guys,

I've written a VNC client that implements the VNC QEMU Audio
Using QEMU 0.13 it works very very for remote sound, however after
upgrading to QEMU 1.1.0 the audio stream contains only bytes of zeros,
so this results in no sound on the client.

It is almost like the stream is muted by sending 0 bytes instead of the
actual data.

0: VNC: :SOUND: AudioOn
1: VNC: :SOUND: Received _QEMU_Audio_Server_Message: Operation: 1
2: VNC: :SOUND: Received _QEMU_Audio_Start
3: VNC: :SOUND: Received _QEMU_Audio_Server_Message: Operation: 2
4: VNC: :SOUND: Received _QEMU_Audio_Data 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Is there something new that needs to be done in order for the sound to
be pushed out, like some unmute mechanism?

I rebuilt QEMU 0.15.1 and sound worked but was very choppy, I think due
to some timer injection changes - but that's another issue.

Thanks in advance.


I've just rebuilt QEMU 1.0 (and all of its dependencies) and it has
the same
problem (zero bytes), so some incompatibility was introduced between
and 1.1.0.

Anyone got any clues ?

Please try to bisect the issue.

My previous comment had a typo, it should have said: between 0.15.1 and
1.0. (not 1.1.0)

bi-section so far:

I suspect that one of the following patches is causing the issue, these
are all added to QEMU 1.0 (by Fedora at least) and are included in 1.1.0

# Spice volume control backports, all are upstream for 1.1
Patch501: 0501-audio-add-VOICE_VOLUME-ctl.patch
Patch502: 0502-audio-don-t-apply-volume-effect-if-backend-has-VOICE.patch
Patch503: 0503-hw-ac97-remove-USE_MIXER-code.patch
Patch504: 0504-hw-ac97-the-volume-mask-is-not-only-0x1f.patch
Patch505: 0505-hw-ac97-add-support-for-volume-control.patch
Patch506: 0506-audio-spice-add-support-for-volume-control.patch
Patch507: 0507-Do-not-use-pa_simple-PulseAudio-API.patch
Patch508: 0508-configure-pa_simple-is-not-needed-anymore.patch
Patch509: 0509-Allow-controlling-volume-with-PulseAudio-backend.patch

In order to use the QEMU VNC Audio for remote sound, you must
export QEMU_AUDIO_DRV=none, this indicates that you are not using a

QEMU_AUDIO_DRV=none is deceptive, but accurate, it tells QEMU not to
connect to the QEMU host sound system. It does _not_ mean there is no

Volume/mute control for VNC QEMU remote sound should _always_ be managed
from the client side and should be on by default, but it looks like
something is interfering with the stream from QEMU >0.15.1 on the server
side and thus breaking the QEMU VNC extension.


I cannot seem to get any further trying to find the source of this issue, except to say that QEMU Audio over VNC used to work in QEMU 0.13 until about QEMU 15.1 then it appears to have stopped working as described above.

My VNC client is written in perl (along with Perl-SDL) from scratch, I wrote it because I could not find a client that implemented the QEMU VNC protocol extensions.

Line 4 above is output from the following code:

sub _QEMU_Audio_Data () {

  my $self=shift;
  my $sound=$self->{sound_server};

  my $socket = $self->{socket};
$socket->read( $sound->{len}, 4 ) || return ($self->_SetError('unexpected end of data')); $sound->{bytes_read}=$socket->read( $sound->{_audio_buff}, (unpack 'N', $sound->{len}),$sound->{_audio_offset}) || return ($self->_SetError('unexpected end of data'));

# # For debugging
my @data=unpack 'C*',$sound->{_audio_buff};
$self->DEBUG ($DB_SOUND,"Received _QEMU_Audio_Data @data");


My application does not use Libvirt or Spice and relies on this QEMU feature, I'm hoping that it will not get deprecated because it works fantastically and is very lightweight.

Tracking down and fixing this would very much be appreciated.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]