* [Qemu-devel] QEMU VNC Audio - All audio data null @ 2012-07-14 2:17 agraham 2012-07-14 5:37 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 2:17 UTC (permalink / raw) To: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 2:17 [Qemu-devel] QEMU VNC Audio - All audio data null agraham @ 2012-07-14 5:37 ` agraham 2012-07-14 10:44 ` malc 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 5:37 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 5:37 ` agraham @ 2012-07-14 10:44 ` malc 2012-07-14 12:55 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 10:44 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 10:44 ` malc @ 2012-07-14 12:55 ` agraham 2012-07-14 17:10 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 12:55 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 12:55 ` agraham @ 2012-07-14 17:10 ` agraham 2012-07-14 17:20 ` malc 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 17:10 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 17:10 ` agraham @ 2012-07-14 17:20 ` malc 2012-07-14 19:30 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 17:20 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 17:20 ` malc @ 2012-07-14 19:30 ` agraham 2012-07-14 20:09 ` malc 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 19:30 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 19:30 ` agraham @ 2012-07-14 20:09 ` malc 2012-07-14 22:16 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 20:09 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 20:09 ` malc @ 2012-07-14 22:16 ` agraham 2012-07-14 22:23 ` malc 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 22:16 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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 "$@" 1>&2 cat > file <&$inputfd #aplay -t raw -c 2 -f S16_LE -r 44100 <&$inputfd And this confirms that my original findings. # hexdump -C file 00000000 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 22:16 ` agraham @ 2012-07-14 22:23 ` malc 2012-07-14 22:42 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 22:23 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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 "$@" 1>&2 > cat > file <&$inputfd > #aplay -t raw -c 2 -f S16_LE -r 44100 <&$inputfd > > And this confirms that my original findings. > > # hexdump -C file > 00000000 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 22:23 ` malc @ 2012-07-14 22:42 ` agraham 2012-07-14 22:52 ` agraham 2012-07-14 23:01 ` malc 0 siblings, 2 replies; 23+ messages in thread From: agraham @ 2012-07-14 22:42 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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 "$@" 1>&2 >> cat> file<&$inputfd >> #aplay -t raw -c 2 -f S16_LE -r 44100<&$inputfd >> >> And this confirms that my original findings. >> >> # hexdump -C file >> 00000000 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 -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. Albert ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 22:42 ` agraham @ 2012-07-14 22:52 ` agraham 2012-07-14 23:23 ` malc 2012-07-14 23:01 ` malc 1 sibling, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 22:52 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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 "$@" 1>&2 >>> cat> file<&$inputfd >>> #aplay -t raw -c 2 -f S16_LE -r 44100<&$inputfd >>> >>> And this confirms that my original findings. >>> >>> # hexdump -C file >>> 00000000 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 -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. > > Albert 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 22:52 ` agraham @ 2012-07-14 23:23 ` malc 0 siblings, 0 replies; 23+ messages in thread From: malc @ 2012-07-14 23:23 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 22:42 ` agraham 2012-07-14 22:52 ` agraham @ 2012-07-14 23:01 ` malc 2012-07-14 23:13 ` agraham 1 sibling, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 23:01 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 23:01 ` malc @ 2012-07-14 23:13 ` agraham 2012-07-14 23:21 ` malc 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-14 23:13 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 23:13 ` agraham @ 2012-07-14 23:21 ` malc 2012-07-15 19:22 ` agraham 0 siblings, 1 reply; 23+ messages in thread From: malc @ 2012-07-14 23:21 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-14 23:21 ` malc @ 2012-07-15 19:22 ` agraham 2012-07-15 19:48 ` malc 2012-07-16 0:03 ` malc 0 siblings, 2 replies; 23+ messages in thread From: agraham @ 2012-07-15 19:22 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-15 19:22 ` agraham @ 2012-07-15 19:48 ` malc 2012-07-16 0:03 ` malc 1 sibling, 0 replies; 23+ messages in thread From: malc @ 2012-07-15 19:48 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-15 19:22 ` agraham 2012-07-15 19:48 ` malc @ 2012-07-16 0:03 ` malc 2012-07-16 2:10 ` agraham 1 sibling, 1 reply; 23+ messages in thread From: malc @ 2012-07-16 0:03 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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:av1474@comtv.ru ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-16 0:03 ` malc @ 2012-07-16 2:10 ` agraham 2012-07-16 8:12 ` Daniel P. Berrange 0 siblings, 1 reply; 23+ messages in thread From: agraham @ 2012-07-16 2:10 UTC (permalink / raw) To: malc; +Cc: qemu-devel 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-16 2:10 ` agraham @ 2012-07-16 8:12 ` Daniel P. Berrange 2012-07-16 10:56 ` agraham 2012-07-16 19:58 ` agraham 0 siblings, 2 replies; 23+ messages in thread From: Daniel P. Berrange @ 2012-07-16 8:12 UTC (permalink / raw) To: agraham; +Cc: qemu-devel 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 :| ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-16 8:12 ` Daniel P. Berrange @ 2012-07-16 10:56 ` agraham 2012-07-16 19:58 ` agraham 1 sibling, 0 replies; 23+ messages in thread From: agraham @ 2012-07-16 10:56 UTC (permalink / raw) To: Daniel P. Berrange; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Qemu-devel] QEMU VNC Audio - All audio data null 2012-07-16 8:12 ` Daniel P. Berrange 2012-07-16 10:56 ` agraham @ 2012-07-16 19:58 ` agraham 1 sibling, 0 replies; 23+ messages in thread From: agraham @ 2012-07-16 19:58 UTC (permalink / raw) To: Daniel P. Berrange; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2012-07-16 19:59 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-14 2:17 [Qemu-devel] QEMU VNC Audio - All audio data null agraham 2012-07-14 5:37 ` agraham 2012-07-14 10:44 ` malc 2012-07-14 12:55 ` agraham 2012-07-14 17:10 ` agraham 2012-07-14 17:20 ` malc 2012-07-14 19:30 ` agraham 2012-07-14 20:09 ` malc 2012-07-14 22:16 ` agraham 2012-07-14 22:23 ` malc 2012-07-14 22:42 ` agraham 2012-07-14 22:52 ` agraham 2012-07-14 23:23 ` malc 2012-07-14 23:01 ` malc 2012-07-14 23:13 ` agraham 2012-07-14 23:21 ` malc 2012-07-15 19:22 ` agraham 2012-07-15 19:48 ` malc 2012-07-16 0:03 ` malc 2012-07-16 2:10 ` agraham 2012-07-16 8:12 ` Daniel P. Berrange 2012-07-16 10:56 ` agraham 2012-07-16 19:58 ` agraham
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.