Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-04-25 09:34, Gerd Hoffmann wrote:
> On 04/25/12 13:03, Jan Kiszka wrote:
>> Hi Gerd,
>>
>> I had problems with Windows LiveMeeting expecting a microphone as
>> input. But the HDA model only exposes a line-in port. The following hack
>> works for me, but I bet there is a cleaner solution. Any suggestions?
> 
> Good to know this works.  /me has patches ready to go, was just waiting
> for testing feedback ...
> 
> Pushed to git://git.kraxel.org/qemu audio.1
> 
> They do essentially the same, except that they leave the existing
> hda-duplex code as-is and add a new hda-micro codec instead which
> advertises the input as micro to the guest.

Yep, would work fine - if the issue below allowed me to use it.

> 
>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>> too small DAC buffer, is that true? Is there anything one can do about
>> this?
> 
> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
> considering buffer flipping intel-hda has to shuffle data every 10ms,
> and the windows guest needs to be scheduled too so it can re-fill the
> other half of the buffer.  Which obviously makes sound playback *very*
> sensitive to latencies anywhere in the qemu.
> 
> What you can do about it?  Dunno whenever windows allows to tweak the
> buffer size somehow.  When I looked deeper at that a while back the
> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
> should be fixed now with the switch to coroutines and full async i/o.
> Likewise qxl, although this depends on recent guest drivers.  For vnc
> enabling the threaded vnc server helps alot (without it moving around
> windows leads to sound dropouts).

I found another workaround: audio hw passthrough. Works nicely. And this
indicates that there should be still some room for improvement in the
device model so that Windows chooses a proper ring buffer size, no?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Alexander Graf]

On 02.05.2012, at 20:17, Jan Kiszka wrote:

> On 2012-04-25 09:34, Gerd Hoffmann wrote:
>> On 04/25/12 13:03, Jan Kiszka wrote:
>>> Hi Gerd,
>>> 
>>> I had problems with Windows LiveMeeting expecting a microphone as
>>> input. But the HDA model only exposes a line-in port. The following hack
>>> works for me, but I bet there is a cleaner solution. Any suggestions?
>> 
>> Good to know this works.  /me has patches ready to go, was just waiting
>> for testing feedback ...
>> 
>> Pushed to git://git.kraxel.org/qemu audio.1
>> 
>> They do essentially the same, except that they leave the existing
>> hda-duplex code as-is and add a new hda-micro codec instead which
>> advertises the input as micro to the guest.
> 
> Yep, would work fine - if the issue below allowed me to use it.
> 
>> 
>>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>>> too small DAC buffer, is that true? Is there anything one can do about
>>> this?
>> 
>> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
>> considering buffer flipping intel-hda has to shuffle data every 10ms,
>> and the windows guest needs to be scheduled too so it can re-fill the
>> other half of the buffer.  Which obviously makes sound playback *very*
>> sensitive to latencies anywhere in the qemu.
>> 
>> What you can do about it?  Dunno whenever windows allows to tweak the
>> buffer size somehow.  When I looked deeper at that a while back the
>> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
>> should be fixed now with the switch to coroutines and full async i/o.
>> Likewise qxl, although this depends on recent guest drivers.  For vnc
>> enabling the threaded vnc server helps alot (without it moving around
>> windows leads to sound dropouts).
> 
> I found another workaround: audio hw passthrough. Works nicely. And this
> indicates that there should be still some room for improvement in the
> device model so that Windows chooses a proper ring buffer size, no?

Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)


Alex

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-02 19:42, Alexander Graf wrote:
> 
> On 02.05.2012, at 20:17, Jan Kiszka wrote:
> 
>> On 2012-04-25 09:34, Gerd Hoffmann wrote:
>>> On 04/25/12 13:03, Jan Kiszka wrote:
>>>> Hi Gerd,
>>>>
>>>> I had problems with Windows LiveMeeting expecting a microphone as
>>>> input. But the HDA model only exposes a line-in port. The following hack
>>>> works for me, but I bet there is a cleaner solution. Any suggestions?
>>>
>>> Good to know this works.  /me has patches ready to go, was just waiting
>>> for testing feedback ...
>>>
>>> Pushed to git://git.kraxel.org/qemu audio.1
>>>
>>> They do essentially the same, except that they leave the existing
>>> hda-duplex code as-is and add a new hda-micro codec instead which
>>> advertises the input as micro to the guest.
>>
>> Yep, would work fine - if the issue below allowed me to use it.
>>
>>>
>>>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>>>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>>>> too small DAC buffer, is that true? Is there anything one can do about
>>>> this?
>>>
>>> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
>>> considering buffer flipping intel-hda has to shuffle data every 10ms,
>>> and the windows guest needs to be scheduled too so it can re-fill the
>>> other half of the buffer.  Which obviously makes sound playback *very*
>>> sensitive to latencies anywhere in the qemu.
>>>
>>> What you can do about it?  Dunno whenever windows allows to tweak the
>>> buffer size somehow.  When I looked deeper at that a while back the
>>> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
>>> should be fixed now with the switch to coroutines and full async i/o.
>>> Likewise qxl, although this depends on recent guest drivers.  For vnc
>>> enabling the threaded vnc server helps alot (without it moving around
>>> windows leads to sound dropouts).
>>
>> I found another workaround: audio hw passthrough. Works nicely. And this
>> indicates that there should be still some room for improvement in the
>> device model so that Windows chooses a proper ring buffer size, no?
> 
> Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)

The point is that both pt as well as emulation suffer from the same
issue: lacking real-time support of QEMU. So I guess Windows uses a
different buffer size for the real hardware than for our HDA model.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Gerd Hoffmann]

  Hi,

>>> I found another workaround: audio hw passthrough. Works nicely. And this
>>> indicates that there should be still some room for improvement in the
>>> device model so that Windows chooses a proper ring buffer size, no?
>>
>> Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
> 
> The point is that both pt as well as emulation suffer from the same
> issue: lacking real-time support of QEMU. So I guess Windows uses a
> different buffer size for the real hardware than for our HDA model.

What IRQ rate you are seeing?

cheers,
  Gerd

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Alexander Graf]

On 03.05.2012, at 14:29, Jan Kiszka wrote:

> On 2012-05-02 19:42, Alexander Graf wrote:
>> 
>> On 02.05.2012, at 20:17, Jan Kiszka wrote:
>> 
>>> On 2012-04-25 09:34, Gerd Hoffmann wrote:
>>>> On 04/25/12 13:03, Jan Kiszka wrote:
>>>>> Hi Gerd,
>>>>> 
>>>>> I had problems with Windows LiveMeeting expecting a microphone as
>>>>> input. But the HDA model only exposes a line-in port. The following hack
>>>>> works for me, but I bet there is a cleaner solution. Any suggestions?
>>>> 
>>>> Good to know this works.  /me has patches ready to go, was just waiting
>>>> for testing feedback ...
>>>> 
>>>> Pushed to git://git.kraxel.org/qemu audio.1
>>>> 
>>>> They do essentially the same, except that they leave the existing
>>>> hda-duplex code as-is and add a new hda-micro codec instead which
>>>> advertises the input as micro to the guest.
>>> 
>>> Yep, would work fine - if the issue below allowed me to use it.
>>> 
>>>> 
>>>>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>>>>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>>>>> too small DAC buffer, is that true? Is there anything one can do about
>>>>> this?
>>>> 
>>>> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
>>>> considering buffer flipping intel-hda has to shuffle data every 10ms,
>>>> and the windows guest needs to be scheduled too so it can re-fill the
>>>> other half of the buffer.  Which obviously makes sound playback *very*
>>>> sensitive to latencies anywhere in the qemu.
>>>> 
>>>> What you can do about it?  Dunno whenever windows allows to tweak the
>>>> buffer size somehow.  When I looked deeper at that a while back the
>>>> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
>>>> should be fixed now with the switch to coroutines and full async i/o.
>>>> Likewise qxl, although this depends on recent guest drivers.  For vnc
>>>> enabling the threaded vnc server helps alot (without it moving around
>>>> windows leads to sound dropouts).
>>> 
>>> I found another workaround: audio hw passthrough. Works nicely. And this
>>> indicates that there should be still some room for improvement in the
>>> device model so that Windows chooses a proper ring buffer size, no?
>> 
>> Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
> 
> The point is that both pt as well as emulation suffer from the same
> issue: lacking real-time support of QEMU. So I guess Windows uses a
> different buffer size for the real hardware than for our HDA model.

For pt hardware, the BARs just get directly mapped into guest memory space, so BAR accesses don't go through QEMU anymore. I guess you're also using the in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The vcpus should keep running even when you move windows in VNC, right?

So it could just as well be that Windows is not using a different buffer size, but you're simply exiting into QEMU a lot less, getting better latencies.


Alex

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-03 09:42, Alexander Graf wrote:
> 
> On 03.05.2012, at 14:29, Jan Kiszka wrote:
> 
>> On 2012-05-02 19:42, Alexander Graf wrote:
>>>
>>> On 02.05.2012, at 20:17, Jan Kiszka wrote:
>>>
>>>> On 2012-04-25 09:34, Gerd Hoffmann wrote:
>>>>> On 04/25/12 13:03, Jan Kiszka wrote:
>>>>>> Hi Gerd,
>>>>>>
>>>>>> I had problems with Windows LiveMeeting expecting a microphone as
>>>>>> input. But the HDA model only exposes a line-in port. The following hack
>>>>>> works for me, but I bet there is a cleaner solution. Any suggestions?
>>>>>
>>>>> Good to know this works.  /me has patches ready to go, was just waiting
>>>>> for testing feedback ...
>>>>>
>>>>> Pushed to git://git.kraxel.org/qemu audio.1
>>>>>
>>>>> They do essentially the same, except that they leave the existing
>>>>> hda-duplex code as-is and add a new hda-micro codec instead which
>>>>> advertises the input as micro to the guest.
>>>>
>>>> Yep, would work fine - if the issue below allowed me to use it.
>>>>
>>>>>
>>>>>> BTW, sound output quality of a Win7 guest on my Linux hosts sucks while
>>>>>> it's fine for a Linux guest. I vaguely recall that Windows requests a
>>>>>> too small DAC buffer, is that true? Is there anything one can do about
>>>>>> this?
>>>>>
>>>>> Yes.  The buffer is ~ one page and can hold 20 ms of sound data, so
>>>>> considering buffer flipping intel-hda has to shuffle data every 10ms,
>>>>> and the windows guest needs to be scheduled too so it can re-fill the
>>>>> other half of the buffer.  Which obviously makes sound playback *very*
>>>>> sensitive to latencies anywhere in the qemu.
>>>>>
>>>>> What you can do about it?  Dunno whenever windows allows to tweak the
>>>>> buffer size somehow.  When I looked deeper at that a while back the
>>>>> biggest latency issues in qemu used to be qxl, ide/qcow2 and vnc.  qcow2
>>>>> should be fixed now with the switch to coroutines and full async i/o.
>>>>> Likewise qxl, although this depends on recent guest drivers.  For vnc
>>>>> enabling the threaded vnc server helps alot (without it moving around
>>>>> windows leads to sound dropouts).
>>>>
>>>> I found another workaround: audio hw passthrough. Works nicely. And this
>>>> indicates that there should be still some room for improvement in the
>>>> device model so that Windows chooses a proper ring buffer size, no?
>>>
>>> Why? For hw passthrough, mmio doesn't go through qemu anymore, right? :)
>>
>> The point is that both pt as well as emulation suffer from the same
>> issue: lacking real-time support of QEMU. So I guess Windows uses a
>> different buffer size for the real hardware than for our HDA model.
> 
> For pt hardware, the BARs just get directly mapped into guest memory space, so BAR accesses don't go through QEMU anymore. I guess you're also using the in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The vcpus should keep running even when you move windows in VNC, right?
> 
> So it could just as well be that Windows is not using a different buffer size, but you're simply exiting into QEMU a lot less, getting better latencies.

That appears like a simple explanation, but I'm basically getting the
same exit rate with emulation as with pt (>2000 userspace exits/s). At
this rate, every significant userspace delay should be audible as it
also delays vcpu execution.

The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
IRQ? Likely before the end of the buffer. At half of its size?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Gerd Hoffmann]

  Hi,

>>> The point is that both pt as well as emulation suffer from the same
>>> issue: lacking real-time support of QEMU. So I guess Windows uses a
>>> different buffer size for the real hardware than for our HDA model.
>>
>> For pt hardware, the BARs just get directly mapped into guest memory space, so BAR accesses don't go through QEMU anymore. I guess you're also using the in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The vcpus should keep running even when you move windows in VNC, right?
>>
>> So it could just as well be that Windows is not using a different buffer size, but you're simply exiting into QEMU a lot less, getting better latencies.
> 
> That appears like a simple explanation, but I'm basically getting the
> same exit rate with emulation as with pt (>2000 userspace exits/s). At
> this rate, every significant userspace delay should be audible as it
> also delays vcpu execution.

No.  Whatever the qemu iothread is doing does *not* disturb the vcpu(s),
as long as they don't need the qemu mutex.  And with pt windows can play
sound without needing the qemu mutex, whereas with emulation it is needed.

> The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
> IRQ? Likely before the end of the buffer. At half of its size?

Yes, half buffer.  one page buffersize -> 20ms sound data total -> irq &
refill every 10ms -> 100 irqs/s needed.  Windows uses the same buffer
size in passthrough case.

cheers,
  Gerd

Re: [Qemu-devel] [HACK] hda: expose microphone instead of line-in

[Jan Kiszka]

On 2012-05-03 11:15, Gerd Hoffmann wrote:
>   Hi,
> 
>>>> The point is that both pt as well as emulation suffer from the same
>>>> issue: lacking real-time support of QEMU. So I guess Windows uses a
>>>> different buffer size for the real hardware than for our HDA model.
>>>
>>> For pt hardware, the BARs just get directly mapped into guest memory space, so BAR accesses don't go through QEMU anymore. I guess you're also using the in-kernel PIC, at which point you're not using QEMU anymore for the HDA. The vcpus should keep running even when you move windows in VNC, right?
>>>
>>> So it could just as well be that Windows is not using a different buffer size, but you're simply exiting into QEMU a lot less, getting better latencies.
>>
>> That appears like a simple explanation, but I'm basically getting the
>> same exit rate with emulation as with pt (>2000 userspace exits/s). At
>> this rate, every significant userspace delay should be audible as it
>> also delays vcpu execution.
> 
> No.  Whatever the qemu iothread is doing does *not* disturb the vcpu(s),
> as long as they don't need the qemu mutex.  And with pt windows can play
> sound without needing the qemu mutex, whereas with emulation it is needed.

I measured userspace exists from the kernel. So the VCPU went through
the process of taking our Big QEMU Lock, at least 2000 times per second.

> 
>> The IRQ rate with pt is around 100 HZ. When does the hardware trigger an
>> IRQ? Likely before the end of the buffer. At half of its size?
> 
> Yes, half buffer.  one page buffersize -> 20ms sound data total -> irq &
> refill every 10ms -> 100 irqs/s needed.  Windows uses the same buffer
> size in passthrough case.

Then our problem may also lie elsewhere in the audio path.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux