| Message ID | 4F97D9E4.7090608@siemens.com |
|---|---|
| State | New |
| Headers | show |
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. > 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). cheers, Gerd
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
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
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
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
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
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
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
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
diff --git a/hw/hda-audio.c b/hw/hda-audio.c index 8995519..bf28969 100644 --- a/hw/hda-audio.c +++ b/hw/hda-audio.c @@ -411,7 +411,7 @@ static const desc_node duplex_nodes[] = { .params = duplex_params_audio_linein, .nparams = ARRAY_SIZE(duplex_params_audio_linein), .config = ((AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT) | - (AC_JACK_LINE_IN << AC_DEFCFG_DEVICE_SHIFT) | + (AC_JACK_MIC_IN << AC_DEFCFG_DEVICE_SHIFT) | (AC_JACK_CONN_UNKNOWN << AC_DEFCFG_CONN_TYPE_SHIFT) | (AC_JACK_COLOR_RED << AC_DEFCFG_COLOR_SHIFT) | 0x20),