Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Mon, Jul 16, 2012 at 03:10:25AM +0100, agraham wrote:
On 07/16/2012 01:03 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME
(sw));
[..snip..]
:)
I'm as happy as Larry, works great,
Please do file a bug against Fedora for this problem, so that our
maintainers sort it out
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/16/2012 09:12 AM, Daniel P. Berrange wrote:
On Mon, Jul 16, 2012 at 03:10:25AM +0100, agraham wrote:
On 07/16/2012 01:03 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME
(sw));
[..snip..]
:)
I'm as happy as Larry, works great,
Please do file a bug against Fedora for this problem, so that our
maintainers sort it out
Daniel
Will do.
Hey, your blog rocks!
Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/16/2012 09:12 AM, Daniel P. Berrange wrote:
On Mon, Jul 16, 2012 at 03:10:25AM +0100, agraham wrote:
On 07/16/2012 01:03 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME
(sw));
[..snip..]
:)
I'm as happy as Larry, works great,
Please do file a bug against Fedora for this problem, so that our
maintainers sort it out
Daniel
done.
https://bugzilla.redhat.com/show_bug.cgi?id=840653
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/15/2012 12:21 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
On 07/15/2012 12:01 AM, malc wrote:
On Sat, 14 Jul 2012, agraham wrote:
[..snip..]
/usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive
file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0
-device
virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0
-device
virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0
-netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std
-vnc :1100,lossy -rtc base=localtime,clock=host -global
kvm-pit.lost_tick_policy=discard -chardev
socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon
chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot
/var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1
-uuid
cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw
ac97,es1370
Replacing es1370 with sb16 or removing it does not change anything.
Once again, works for me, not with the insane command line like above
though, bisecting is your only option unless someone has bright ideas.
Are you using the AC97 driver?
It shouldn't matter, but i've used SB16 under DOS.
Bi-section complete :)
I've found the root cause and hopefully you should be able to reproduce
the issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Could you rebuild with this switch added to your configure, you should
the experience the issue as I do.
The option was added in Fedora qemu-1.0-x which included QEMU-0.15-1 + a
ton of patches. after rebuilding / removing patches /rebuilding etc.. as
you advised, all patches where removed and the problem still existed!
that lead me to the difference in the configure options.
which lead to:
http://git.qemu.org/?p=qemu.git;a=blob;f=audio/mixeng.c#l349
349 void mixeng_volume (struct st_sample *buf, int len, struct
mixeng_volume *vol)
350 {
351 #ifdef CONFIG_MIXEMU
352 if (vol-mute) {
353 mixeng_clear (buf, len);
354 return;
355 }
I see the words mute + clear, which is what I originally experienced :)
I'm not a C programmer so cannot fix this myself, but I imagine that any
mixemu code should do nothing if QEMU_AUDIO_DRV=none.
Interestingly:
# Copyright (c) 2004-2005 Vassili Karpov (malc)
Any connection with you?
Lastly, I think it would be more efficiency and bandwidth friendly to
zero the length such that no data would be sent to other clients that do
use this feature (I assume spice), after all there really is no point in
sending zero bytes.
Even when zeros are sent to the sound device you will often here a click
or a crackle for a fraction of a second, so by no sending anything you
would avoid that.
Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote:
On 07/15/2012 12:21 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
On 07/15/2012 12:01 AM, malc wrote:
On Sat, 14 Jul 2012, agraham wrote:
[..snip..]
/usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive
file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0
-device
virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0
-device
virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0
-netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga
std
-vnc :1100,lossy -rtc base=localtime,clock=host -global
kvm-pit.lost_tick_policy=discard -chardev
socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon
chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot
/var/mist/chroot -runas qemu -snapshot -S -daemonize -name
windows-xp-1
-uuid
cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw
ac97,es1370
Replacing es1370 with sb16 or removing it does not change anything.
Once again, works for me, not with the insane command line like above
though, bisecting is your only option unless someone has bright ideas.
Are you using the AC97 driver?
It shouldn't matter, but i've used SB16 under DOS.
Bi-section complete :)
Thanks.
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
I'll try that when time permits.
--enable-mixemu enable mixer emulation
Could you rebuild with this switch added to your configure, you should the
experience the issue as I do.
The option was added in Fedora qemu-1.0-x which included QEMU-0.15-1 + a ton
of patches. after rebuilding / removing patches /rebuilding etc.. as you
advised, all patches where removed and the problem still existed! that lead me
to the difference in the configure options.
which lead to:
http://git.qemu.org/?p=qemu.git;a=blob;f=audio/mixeng.c#l349
349 void mixeng_volume (struct st_sample *buf, int len, struct mixeng_volume
*vol)
350 {
351 #ifdef CONFIG_MIXEMU
352 if (vol-mute) {
353 mixeng_clear (buf, len);
354 return;
355 }
I see the words mute + clear, which is what I originally experienced :)
I'm not a C programmer so cannot fix this myself, but I imagine that any
mixemu code should do nothing if QEMU_AUDIO_DRV=none.
Interestingly:
# Copyright (c) 2004-2005 Vassili Karpov (malc)
Any connection with you?
Yes.
Lastly, I think it would be more efficiency and bandwidth friendly to zero the
length such that no data would be sent to other clients that do use this
feature (I assume spice), after all there really is no point in sending zero
bytes.
It wouldn't be correct though, syncing and such...
Even when zeros are sent to the sound device you will often here a click or a
crackle for a fraction of a second, so by no sending anything you would avoid
that.
Albert
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME (sw));
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/16/2012 01:03 AM, malc wrote:
On Sun, 15 Jul 2012, agraham wrote:
[..snip..]
I've found the root cause and hopefully you should be able to reproduce the
issue.
There was a configure option introduced called --enable-mixemu.
--enable-mixemu enable mixer emulation
Try this
diff --git a/audio/audio.c b/audio/audio.c
index 583ee51..1c77389 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -818,6 +818,7 @@ static int audio_attach_capture (HWVoiceOut *hw)
sw-active = hw-enabled;
sw-conv = noop_conv;
sw-ratio = ((int64_t) hw_cap-info.freq 32) / sw-info.freq;
+sw-vol = nominal_volume;
sw-rate = st_rate_start (sw-info.freq, hw_cap-info.freq);
if (!sw-rate) {
dolog (Could not start rate conversion for `%s'\n, SW_NAME
(sw));
[..snip..]
:)
I'm as happy as Larry, works great,
Thank you so much.
Albert.
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
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 extensions. 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. Albert 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 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
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 extensions. 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. Albert 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 0.15.1 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 upstream. # 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 back-end. 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 sound. 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. Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
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
extensions.
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.
Albert
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
0.15.1
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
upstream.
# 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
back-end.
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
sound.
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.
Albert
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);
$sound-sound_play_data($self-{sound_ctrl});
}
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.
Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote:
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:
[..snip.]]
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
0.15.1
and 1.1.0.
Anyone got any clues ?
Please try to bisect the issue.
[..snip..]
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.
As i said, try bisecting, doesn't involce too many brainwaves only raw
machine power.
FWIW i just built a fresh checkout and it works for me with my own
client...
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);
$sound-sound_play_data($self-{sound_ctrl});
}
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.
Albert
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip.]] 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 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. [..snip..] 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. As i said, try bisecting, doesn't involce too many brainwaves only raw machine power. Well, the problem is I'm rebuilding from Fedora spec file and that contains about 122 patches very many relating to spice that could cause the problem and it's in one of these that the bug may be introduced. FWIW i just built a fresh checkout and it works for me with my own client... Which Client are you using? Are you sure you're not using spice protocol? I've just rebuilt qemu package from: http://koji.fedoraproject.org/koji/buildinfo?buildID=329768 This is the latest Fedora 17 Package which builds qemu-kvm-1.1.0.tar.gz + a bunch of patches. The only patch I've included is: 0001-kvm-Enable-use-of-kvm_irqchip_in_kernel-in-hwlib-cod.patch, because it will not compile without that patch. So it should pretty much match stock 1.1.0 I can confirm that the QEMU VNC Audio still does _not_ work and I get the exact same results, i.e. when I read the sample format data from the socket it contains the right amount of data, but the data contains zeros bytes, this results in silence. Also I found this: http://www.digipedia.pl/usenet/thread/19179/2346/#post2351 The QEMU version they refer to is Fedora 16 which contains 0.15.x, which confirms my own findings as stated above. Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip.]] 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 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. [..snip..] 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. As i said, try bisecting, doesn't involce too many brainwaves only raw machine power. Well, the problem is I'm rebuilding from Fedora spec file and that contains about 122 patches very many relating to spice that could cause the problem and it's in one of these that the bug may be introduced. Sorry, but i do not have Fedora and if you insist on using patched version do talk to Fedora people. FWIW i just built a fresh checkout and it works for me with my own client... Which Client are you using? http://repo.or.cz/w/qemu-vcap.git Are you sure you're not using spice protocol? Yes. I've just rebuilt qemu package from: http://koji.fedoraproject.org/koji/buildinfo?buildID=329768 This is the latest Fedora 17 Package which builds qemu-kvm-1.1.0.tar.gz + a bunch of patches. The only patch I've included is: 0001-kvm-Enable-use-of-kvm_irqchip_in_kernel-in-hwlib-cod.patch, because it will not compile without that patch. So it should pretty much match stock 1.1.0 I can confirm that the QEMU VNC Audio still does _not_ work and I get the exact same results, i.e. when I read the sample format data from the socket it contains the right amount of data, but the data contains zeros bytes, this results in silence. Also I found this: http://www.digipedia.pl/usenet/thread/19179/2346/#post2351 The QEMU version they refer to is Fedora 16 which contains 0.15.x, which confirms my own findings as stated above. Get a vanilla git version and try to reproduce if it's reproducible - bisect, if not try to seek help through Fedora channels. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/14/2012 09:09 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip.]] 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 0.15.1 and 1.1.0. Anyone got any clues ? Please try to bisect the issue. [..snip..] 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. As i said, try bisecting, doesn't involce too many brainwaves only raw machine power. Well, the problem is I'm rebuilding from Fedora spec file and that contains about 122 patches very many relating to spice that could cause the problem and it's in one of these that the bug may be introduced. Sorry, but i do not have Fedora and if you insist on using patched version do talk to Fedora people. FWIW i just built a fresh checkout and it works for me with my own client... Which Client are you using? http://repo.or.cz/w/qemu-vcap.git Are you sure you're not using spice protocol? Yes. I've just rebuilt qemu package from: http://koji.fedoraproject.org/koji/buildinfo?buildID=329768 This is the latest Fedora 17 Package which builds qemu-kvm-1.1.0.tar.gz + a bunch of patches. The only patch I've included is: 0001-kvm-Enable-use-of-kvm_irqchip_in_kernel-in-hwlib-cod.patch, because it will not compile without that patch. So it should pretty much match stock 1.1.0 I can confirm that the QEMU VNC Audio still does _not_ work and I get the exact same results, i.e. when I read the sample format data from the socket it contains the right amount of data, but the data contains zeros bytes, this results in silence. Also I found this: http://www.digipedia.pl/usenet/thread/19179/2346/#post2351 The QEMU version they refer to is Fedora 16 which contains 0.15.x, which confirms my own findings as stated above. Get a vanilla git version and try to reproduce if it's reproducible - bisect, if not try to seek help through Fedora channels. I got the git version and created a tarbal and used the F17 Spec file to build all the packages - and it worked! So this is now plain stock QEMU (v1.1.50). The problem still exists, exactly the same as previously described, and what I was expecting given my previous testing. I also tried your client, and could not hear anything, the output was as follows: # ./acap 5 server is `QEMU (windows-xp-1)' Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least -1342018345912.717 ms long) underrun!!! (at least -1342018345917.003 ms long) underrun!!! (at least -1342018345912.526 ms long) So I modified the acap.sh script to save all received data to a file as follows: #!/bin/sh inputfd=$1 echo $@ 12 cat file $inputfd #aplay -t raw -c 2 -f S16_LE -r 44100 $inputfd And this confirms that my original findings. # hexdump -C file 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000bf690 00 00 00 00 00 00 00 00 || 000bf698 So now, I am assuming that you did _not_ hear actual sound, but assumed it was working because the output of the above script shows data was being received. Can you confirm this? Does QEMU have a bug reporter ? Albert
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 09:09 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip..] I got the git version and created a tarbal and used the F17 Spec file to build all the packages - and it worked! So this is now plain stock QEMU (v1.1.50). The problem still exists, exactly the same as previously described, and what I was expecting given my previous testing. I also tried your client, and could not hear anything, the output was as follows: # ./acap 5 server is `QEMU (windows-xp-1)' Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least -1342018345912.717 ms long) underrun!!! (at least -1342018345917.003 ms long) underrun!!! (at least -1342018345912.526 ms long) So I modified the acap.sh script to save all received data to a file as follows: #!/bin/sh inputfd=$1 echo $@ 12 cat file $inputfd #aplay -t raw -c 2 -f S16_LE -r 44100 $inputfd And this confirms that my original findings. # hexdump -C file 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000bf690 00 00 00 00 00 00 00 00 || 000bf698 So now, I am assuming that you did _not_ hear actual sound, but assumed it was working because the output of the above script shows data was being received. Can you confirm this? No, i actually heard the sound playing as expected. Once again try bisecting the issue, and also give the configure and qemu invocation command lines. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/14/2012 11:23 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 09:09 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip..] I got the git version and created a tarbal and used the F17 Spec file to build all the packages - and it worked! So this is now plain stock QEMU (v1.1.50). The problem still exists, exactly the same as previously described, and what I was expecting given my previous testing. I also tried your client, and could not hear anything, the output was as follows: # ./acap 5 server is `QEMU (windows-xp-1)' Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least -1342018345912.717 ms long) underrun!!! (at least -1342018345917.003 ms long) underrun!!! (at least -1342018345912.526 ms long) So I modified the acap.sh script to save all received data to a file as follows: #!/bin/sh inputfd=$1 echo $@ 12 cat file$inputfd #aplay -t raw -c 2 -f S16_LE -r 44100$inputfd And this confirms that my original findings. # hexdump -C file 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000bf690 00 00 00 00 00 00 00 00 || 000bf698 So now, I am assuming that you did _not_ hear actual sound, but assumed it was working because the output of the above script shows data was being received. Can you confirm this? No, i actually heard the sound playing as expected. Once again try bisecting the issue, and also give the configure and qemu invocation command lines. [..snip..] This is the RPM build output: + rpmbuild -bs /root/rpmbuild/SPECS/qemu.spec warning: Could not canonicalize hostname: fc14-x64-1 Wrote: /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm + rpm -ivh /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm qemu ## + target= + '[' x86_64 '!=' '' ']' + target='--target x86_64' + '[' 1 '!=' 0 ']' + echo 'Silent Building: qemu-1.1.0-8.fc14' Silent Building: qemu-1.1.0-8.fc14 + rpmbuild --rebuild --target x86_64 --nodeps /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm Installing /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm Building target platforms: x86_64 Building for target x86_64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.dOwniU + umask 022 + cd /root/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /root/rpmbuild/BUILD + rm -rf qemu-kvm-1.1.0 + /usr/bin/gzip -dc /root/rpmbuild/SOURCES/qemu-kvm-1.1.0.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd qemu-kvm-1.1.0 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.PvPr1E + umask 022 + cd /root/rpmbuild/BUILD + cd qemu-kvm-1.1.0 + LANG=C + export LANG + unset DISPLAY + buildarch='i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmumips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmush4-softmmu sh4eb-softmmu i386-linux-user x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user m68k-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-usersh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-usersparc32plus-linux-user' + extraldflags=-Wl,--build-id + buildldflags=VL_LDFLAGS=-Wl,--build-id [ CONFIGURE LINE ] + ./configure --target-list=x86_64-softmmu --prefix=/usr --sysconfdir=/etc --audio-drv-list=pa,sdl,alsa,oss --disable-strip '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIE -DPIE' --enable-spice --enable-mixemu --enable-trace-backend=dtrace --disable-werror --disable-xen The eventually results in: Wrote: /root/rpmbuild/RPMS/x86_64/qemu-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-kvm-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-img-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-common-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-guest-agent-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-user-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-x86-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-arm-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-mips-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-cris-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-m68k-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-sh4-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-kvm-tools-1.1.0-8.fc14.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.VZSTHh The
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/14/2012 11:42 PM, agraham wrote: On 07/14/2012 11:23 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 09:09 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: On 07/14/2012 06:20 PM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: 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: [..snip..] I got the git version and created a tarbal and used the F17 Spec file to build all the packages - and it worked! So this is now plain stock QEMU (v1.1.50). The problem still exists, exactly the same as previously described, and what I was expecting given my previous testing. I also tried your client, and could not hear anything, the output was as follows: # ./acap 5 server is `QEMU (windows-xp-1)' Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least -1342018345912.717 ms long) underrun!!! (at least -1342018345917.003 ms long) underrun!!! (at least -1342018345912.526 ms long) So I modified the acap.sh script to save all received data to a file as follows: #!/bin/sh inputfd=$1 echo $@ 12 cat file$inputfd #aplay -t raw -c 2 -f S16_LE -r 44100$inputfd And this confirms that my original findings. # hexdump -C file 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000bf690 00 00 00 00 00 00 00 00 || 000bf698 So now, I am assuming that you did _not_ hear actual sound, but assumed it was working because the output of the above script shows data was being received. Can you confirm this? No, i actually heard the sound playing as expected. Once again try bisecting the issue, and also give the configure and qemu invocation command lines. [..snip..] This is the RPM build output: + rpmbuild -bs /root/rpmbuild/SPECS/qemu.spec warning: Could not canonicalize hostname: fc14-x64-1 Wrote: /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm + rpm -ivh /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm qemu ## + target= + '[' x86_64 '!=' '' ']' + target='--target x86_64' + '[' 1 '!=' 0 ']' + echo 'Silent Building: qemu-1.1.0-8.fc14' Silent Building: qemu-1.1.0-8.fc14 + rpmbuild --rebuild --target x86_64 --nodeps /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm Installing /root/rpmbuild/SRPMS/qemu-1.1.0-8.fc14.src.rpm Building target platforms: x86_64 Building for target x86_64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.dOwniU + umask 022 + cd /root/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /root/rpmbuild/BUILD + rm -rf qemu-kvm-1.1.0 + /usr/bin/gzip -dc /root/rpmbuild/SOURCES/qemu-kvm-1.1.0.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd qemu-kvm-1.1.0 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.PvPr1E + umask 022 + cd /root/rpmbuild/BUILD + cd qemu-kvm-1.1.0 + LANG=C + export LANG + unset DISPLAY + buildarch='i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmu mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu sh4-softmmu sh4eb-softmmu i386-linux-user x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user m68k-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-user sparc32plus-linux-user' + extraldflags=-Wl,--build-id + buildldflags=VL_LDFLAGS=-Wl,--build-id [ CONFIGURE LINE ] + ./configure --target-list=x86_64-softmmu --prefix=/usr --sysconfdir=/etc --audio-drv-list=pa,sdl,alsa,oss --disable-strip '--extra-ldflags=-Wl,--build-id -pie -Wl,-z,relro -Wl,-z,now' '--extra-cflags=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIE -DPIE' --enable-spice --enable-mixemu --enable-trace-backend=dtrace --disable-werror --disable-xen The eventually results in: Wrote: /root/rpmbuild/RPMS/x86_64/qemu-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-kvm-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-img-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-common-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-guest-agent-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-user-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-x86-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-arm-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-mips-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-cris-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-m68k-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-system-sh4-1.1.0-8.fc14.x86_64.rpm Wrote: /root/rpmbuild/RPMS/x86_64/qemu-kvm-tools-1.1.0-8.fc14.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.VZSTHh The QEMU Command: /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: [..snip..] /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0 -device virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0 -device virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0 -netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std -vnc :1100,lossy -rtc base=localtime,clock=host -global kvm-pit.lost_tick_policy=discard -chardev socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot /var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1 -uuid cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw ac97,es1370 Replacing es1370 with sb16 or removing it does not change anything. Once again, works for me, not with the insane command line like above though, bisecting is your only option unless someone has bright ideas. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/15/2012 12:01 AM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: [..snip..] /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0 -device virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0 -device virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0 -netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std -vnc :1100,lossy -rtc base=localtime,clock=host -global kvm-pit.lost_tick_policy=discard -chardev socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot /var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1 -uuid cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw ac97,es1370 Replacing es1370 with sb16 or removing it does not change anything. Once again, works for me, not with the insane command line like above though, bisecting is your only option unless someone has bright ideas. Are you using the AC97 driver?
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sun, 15 Jul 2012, agraham wrote: On 07/15/2012 12:01 AM, malc wrote: On Sat, 14 Jul 2012, agraham wrote: [..snip..] /usr/bin/qemu-kvm -usb -no-fd-bootchk -M pc -enable-kvm -m 128 -drive file=/Storage/Windows/Images/Clone_of_Windows-XP-x32,if=none,media=disk,cache=unsafe,aio=native,snapshot,format=qcow2,id=virtio-blk-pci0 -device virtio-blk-pci,addr=0x05,bus=pci.0,drive=virtio-blk-pci0,id=storage0 -device virtio-net-pci,mac=52:e0:0a:14:00:03,netdev=hostnet0,addr=0x09,bus=pci.0,id=virtio-net-pci0 -netdev tap,script=no,downscript=no,id=hostnet0 -usbdevice tablet -vga std -vnc :1100,lossy -rtc base=localtime,clock=host -global kvm-pit.lost_tick_policy=discard -chardev socket,id=monitor,path=windows-xp-1.monitor,server,nowait -mon chardev=monitor,mode=readline -pidfile windows-xp-1.pid -chroot /var/mist/chroot -runas qemu -snapshot -S -daemonize -name windows-xp-1 -uuid cc0df7d6-26e4-4c60-911e-cd107935c6e6 -boot order=c -cpu kvm32 -soundhw ac97,es1370 Replacing es1370 with sb16 or removing it does not change anything. Once again, works for me, not with the insane command line like above though, bisecting is your only option unless someone has bright ideas. Are you using the AC97 driver? It shouldn't matter, but i've used SB16 under DOS. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On Sat, 14 Jul 2012, agraham wrote: [..snip..] Just to confirm, I'm connecting via a TCP INET socket (i.e. server and client are different machines), your acap.ml script also allows unix: sockets, which one are you using? The default, TCP. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] QEMU VNC Audio - All audio data null
On 07/14/2012 03:17 AM, agraham wrote: Hi Guys, I've written a VNC client that implements the VNC QEMU Audio extensions. 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. Albert 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 0.15.1 and 1.1.0. Anyone got any clues ? Thanks. Albert
