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

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

[agraham]

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

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

[agraham]

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

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

[malc]

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

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

[agraham]

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

[agraham]

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

[malc]

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

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

[agraham]

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

[malc]

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

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

[agraham]

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

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

[malc]

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

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

[agraham]

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

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

[agraham]

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?

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

[malc]

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

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

[agraham]

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

[malc]

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

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

[malc]

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

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

[agraham]

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

[malc]

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

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

[malc]

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

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

[agraham]

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

[Daniel P. Berrange]

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

[agraham]

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

[agraham]

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