RE: no sound in guests
The appropriate qemu command line option for xp is '-soundhw es1370', and for 7 '-soundhw hda'. Quality probably won't be brilliant in 7. Full windows should detect these automatically. Your host (if linux) must include alsa, and you will probably have to run alsamixer to un-mute sound. When you get good host sound by running 'speaker-test -c 2 -t wav', save the configuration with 'alsactl store'. To reload at boot time type or script 'alsactl restore'. If you build qemu-kvm from the package, you will need to set the ./configure options for alsa and intel hda and es1370. Good luck! Simon Date: Wed, 26 Sep 2012 11:05:14 +0800 Subject: no sound in guests From: maillist...@gmail.com To: kvm@vger.kernel.org Hi, I found that there is no sound in guests of Win7, WinXP and even fedora. I searched the web to issue export QEMU_AUDIO_DRV=alsa before starting the guest but no use. Anyone can help to fix it? Host: CentOS 6.3 (64 bits) Guest: Windows 7 (32 bits)/WinXP (32 bits)/Fedora 17 (64 bits) Thanks, rioz -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
no sound in guests
Hi, I found that there is no sound in guests of Win7, WinXP and even fedora. I searched the web to issue export QEMU_AUDIO_DRV=alsa before starting the guest but no use. Anyone can help to fix it? Host: CentOS 6.3 (64 bits) Guest: Windows 7 (32 bits)/WinXP (32 bits)/Fedora 17 (64 bits) Thanks, rioz -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sound not working on vm clients
On Sat, Jun 16, 2012 at 06:40:13PM -0700, David Highley wrote: We have two vm clients and neither have sound. hosting platform is Fedora 16 x86_64 first client is Fedora 17 i686 second client is Ubuntu 12.04 i686 libvirt-0.9.6-5.fc16.x86_64 qemu-kvm-0.15.1-5.fc16.x86_64 Tried both VNC and Spice modes. Did set, vnc_allow_host_audio = 1, in /etc/libvirt/qemu.conf file. Just in case we put selinux in Permissive mode. Still no sound. Is there a sound device emulated in the guest? can you provide the qemu command line? Another question is, when and if graphics 3D acceleration will work? We tried the HoN game, disabled graphics detection, it segfaulted. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sound not working on vm clients
We have two vm clients and neither have sound. hosting platform is Fedora 16 x86_64 first client is Fedora 17 i686 second client is Ubuntu 12.04 i686 libvirt-0.9.6-5.fc16.x86_64 qemu-kvm-0.15.1-5.fc16.x86_64 Tried both VNC and Spice modes. Did set, vnc_allow_host_audio = 1, in /etc/libvirt/qemu.conf file. Just in case we put selinux in Permissive mode. Still no sound. Another question is, when and if graphics 3D acceleration will work? We tried the HoN game, disabled graphics detection, it segfaulted. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
Hi, Agreed. If we can know the virtual device for KVM in a better way (e.g. any specific PCI SSID or such), we can narrow the condition more safely. PCI Subsystem ID 1af4:1100 is qemu/kvm (not only Intel HDA, most other emulated pci devices have it too). Complete entry: 00:04.0 0403: 8086:2668 (rev 01) Subsystem: 1af4:1100 Physical Slot: 4 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e203 (32-bit, non-prefetchable) [size=16K] Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
On 07.11.11 12:25, Gerd Hoffmann wrote: Hi, Agreed. If we can know the virtual device for KVM in a better way (e.g. any specific PCI SSID or such), we can narrow the condition more safely. PCI Subsystem ID 1af4:1100 is qemu/kvm (not only Intel HDA, most other emulated pci devices have it too). Complete entry: 00:04.0 0403: 8086:2668 (rev 01) Subsystem: 1af4:1100 Physical Slot: 4 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e203 (32-bit, non-prefetchable) [size=16K] Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel cheers, Gerd We discuss Intel ICH/AC'97 (snd-intel8x0) here, but I hope that PCI SSID is same. From Parallels VM side we also have specific PCI SSID (1ab8:0400): 00:1f.4 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio Controller (rev 02) Subsystem: Device 1ab8:0400 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at ee00 [size=256] I/O ports at f000 [size=256] Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 Now we can make detection code more adequate. I will make patch today. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
Hi, We discuss Intel ICH/AC'97 (snd-intel8x0) here, but I hope that PCI SSID is same. Hmm, it's not, the ac97 emulation doesn't use the default qemu subsystem id for some reason. Here is the entry: [root@fedora ~]# lspci -vns6 00:06.0 0401: 8086:2415 (rev 01) Subsystem: 8086: Physical Slot: 6 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at c000 [size=1K] I/O ports at c400 [size=256] Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 I guess that should be fixed. 8086: isn't valid anyway and I doubt it serves any useful purpose other than avoiding a guest complaining about the subsystem id being unset. /me goes preparing a patch. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
At Mon, 07 Nov 2011 10:25:24 +0100, Gerd Hoffmann wrote: Hi, Agreed. If we can know the virtual device for KVM in a better way (e.g. any specific PCI SSID or such), we can narrow the condition more safely. PCI Subsystem ID 1af4:1100 is qemu/kvm (not only Intel HDA, most other emulated pci devices have it too). Complete entry: 00:04.0 0403: 8086:2668 (rev 01) Subsystem: 1af4:1100 Physical Slot: 4 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e203 (32-bit, non-prefetchable) [size=16K] Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Thanks. BTW, this reminds me of a possible improvement in the current HD-audio driver. It has some workaround for the delayed DMA-position update (the DMA-position isn't completely updated when IRQ is issued) by offsetting the buffer position. This is controlled by bdl_pos_adj option of snd-hda-intel driver, and this could be zero for VMs. Takashi -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
At Mon, 07 Nov 2011 11:35:49 +0100, Gerd Hoffmann wrote: Hi, We discuss Intel ICH/AC'97 (snd-intel8x0) here, but I hope that PCI SSID is same. Hmm, it's not, the ac97 emulation doesn't use the default qemu subsystem id for some reason. Here is the entry: [root@fedora ~]# lspci -vns6 00:06.0 0401: 8086:2415 (rev 01) Subsystem: 8086: Physical Slot: 6 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at c000 [size=1K] I/O ports at c400 [size=256] Kernel driver in use: Intel ICH Kernel modules: snd-intel8x0 I guess that should be fixed. 8086: isn't valid anyway and I doubt it serves any useful purpose other than avoiding a guest complaining about the subsystem id being unset. Yeah, especially the value 0 looks pretty bad. /me goes preparing a patch. Thanks! Takashi -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wierd hack to sound/pci/intel8x0.c
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset + ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset + ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound card
register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO emulation
is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
The problem could be potentially fixed reducing precision of PICB emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy card
for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible how
to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
The only thing we can is to improve detection code. Suggestions are welcome.
Regards,
Den
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
On 11/06/2011 06:15 PM, Denis V. Lunev wrote:
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound
card register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO
emulation is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
Note on kvm this is rare, since the guest thread and the emulator thread
are the same.
The problem could be potentially fixed reducing precision of PICB
emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy
card for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible
how to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
Ok, so if I understand correctly, this loop is a hack for broken
hardware, and this patch basically unhacks it back, assuming that the
emulated (or assigned) hardware is not broken.
The only thing we can is to improve detection code. Suggestions are
welcome.
I think it's fine to assume that you're not assigning a 2004 era sound
card to a guest. So I think the code is fine as it is, and can only
suggest to add a comment explaining the mess.
Thanks for explaining.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
At Sun, 6 Nov 2011 20:15:01 +0400,
Denis V. Lunev wrote:
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset + ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound card
register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO emulation
is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
The problem could be potentially fixed reducing precision of PICB emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy card
for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible how
to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
The only thing we can is to improve detection code. Suggestions are welcome.
Agreed. If we can know the virtual device for KVM in a better way
(e.g. any specific PCI SSID or such), we can narrow the condition more
safely.
thanks,
Takashi
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
At Sun, 06 Nov 2011 18:31:42 +0200,
Avi Kivity wrote:
On 11/06/2011 06:15 PM, Denis V. Lunev wrote:
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound
card register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO
emulation is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
Note on kvm this is rare, since the guest thread and the emulator thread
are the same.
The problem could be potentially fixed reducing precision of PICB
emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy
card for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible
how to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
Ok, so if I understand correctly, this loop is a hack for broken
hardware, and this patch basically unhacks it back, assuming that the
emulated (or assigned) hardware is not broken.
Exactly. The loop itself is still needed, but the check can be
less restrictive.
The only thing we can is to improve detection code. Suggestions are
welcome.
I think it's fine to assume that you're not assigning a 2004 era sound
card to a guest. So I think the code is fine as it is, and can only
suggest to add a comment explaining the mess.
True. Denis, care to submit a patch?
thanks,
Takashi
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
On 11/6/11 8:31 PM, Avi Kivity wrote:
On 11/06/2011 06:15 PM, Denis V. Lunev wrote:
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound
card register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO
emulation is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
Note on kvm this is rare, since the guest thread and the emulator thread
are the same.
It is the same for Parallels too, but it can be scheduled out anyway.
The most important part here is context switches cost, which is actually
high and enough to result
in different PICB value.
The problem could be potentially fixed reducing precision of PICB
emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy
card for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible
how to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
Ok, so if I understand correctly, this loop is a hack for broken
hardware, and this patch basically unhacks it back, assuming that the
emulated (or assigned) hardware is not broken.
The only thing we can is to improve detection code. Suggestions are
welcome.
I think it's fine to assume that you're not assigning a 2004 era sound
card to a guest. So I think the code is fine as it is, and can only
suggest to add a comment explaining the mess.
Thanks for explaining.
no prob
Regard,
Den
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wierd hack to sound/pci/intel8x0.c
On 11/6/11 8:47 PM, Takashi Iwai wrote:
At Sun, 06 Nov 2011 18:31:42 +0200,
Avi Kivity wrote:
On 11/06/2011 06:15 PM, Denis V. Lunev wrote:
On 11/6/11 6:51 PM, Avi Kivity wrote:
The recently merged 228cf79376f1 (ALSA: intel8x0: Improve performance
in virtual environment) is hacky and somewhat wrong.
First, the detection code
+ if (inside_vm 0) {
+ /* detect KVM and Parallels virtual environments */
+ inside_vm = kvm_para_available();
+#if defined(__i386__) || defined(__x86_64__)
+ inside_vm = inside_vm ||
boot_cpu_has(X86_FEATURE_HYPERVISOR);
+#endif
+ }
+
is incorrect. It detects that you're running in a guest, but that
doesn't imply that the device you're accessing is emulated. It may be a
host device assigned to the guest; presumably the optimization you apply
doesn't work for real devices.
Second, the optimization itself looks fishy:
spin_lock(chip-reg_lock);
do {
civ = igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV);
ptr1 = igetword(chip, ichdev-reg_offset +
ichdev-roff_picb);
position = ichdev-position;
if (ptr1 == 0) {
udelay(10);
continue;
}
- if (civ == igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV)
- ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
+ if (civ != igetbyte(chip, ichdev-reg_offset +
ICH_REG_OFF_CIV))
+ continue;
+ if (chip-inside_vm)
+ break;
+ if (ptr1 == igetword(chip, ichdev-reg_offset +
ichdev-roff_picb))
break;
} while (timeout--);
Why is the emulated device timing out? Can't the emulation be fixed to
behave like real hardware?
Last, please copy kvm@vger.kernel.org on such issues.
The problem is that emulation can not be fixed.
How this is working for real hardware? You get data from real sound
card register.
The scheduling is off at the moment thus you can not be re-scheduled.
In the virtual environment the situation is different. Any IO
emulation is expensive.
The processor is switched from guest to hypervisor and further to
emulation process
takes a lot of time. This time is enough to obtain different value on
next register read.
That's why this code is really timed out. Please also note that host
scheduler also
plays his games and could schedule out VCPU thread.
Note on kvm this is rare, since the guest thread and the emulator thread
are the same.
The problem could be potentially fixed reducing precision of PICB
emulation,
but this results in lower sound quality.
This kludge has been written this way in order not to break legacy
card for which we
do not have an access. The code reading PICB/CIV registers second time
was added
to fix issues on unknown for now platform and it looks not possible
how to find/test
against this platform now. We have checked Windows drivers written by
Intel/AMD
(32/64 bit) and MacOS ones. There is no second reading of CIV/PICB
inside. We
hope that this is relay needed only for some rare hadware devices.
Ok, so if I understand correctly, this loop is a hack for broken
hardware, and this patch basically unhacks it back, assuming that the
emulated (or assigned) hardware is not broken.
Exactly. The loop itself is still needed, but the check can be
less restrictive.
The only thing we can is to improve detection code. Suggestions are
welcome.
I think it's fine to assume that you're not assigning a 2004 era sound
card to a guest. So I think the code is fine as it is, and can only
suggest to add a comment explaining the mess.
True. Denis, care to submit a patch?
sure! I'll do that tomorrow
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
About sound problem on guests
Hi folks, KVM - 1:0.12.4+dfsg-1~bpo50+1 0 host - Debian 5.0 I have been suffering sound problem on guests for sometimes. Please advise whether the same has been solved. If YES please advice how to solve it. TIA B.R. Stephen L -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003 Terminal Server and Sound
- Original Message - On Tuesday, June 22, 2010, 12:42:27, --[ UxBoD ]-- wrote: I am attempting to get sound working on a W2K server and failing horribly :( The sound device was picked up correctly as a ES1370 and shows as being functional; yet when I rdesktop -r sound:remote server name and run Media Player it reports that it is unable to open the device. If you're using a terminal services connection to the machine, it doesn't need a sound card - sound is provided by the remote service itself. Note however that Windows 2000 doesn't support sound through terminal connection - you need XP or newer. Well the answer appears to be devishly simple in that RedHat/CentOS have disabled sound support all together :( -- Thanks, Phil -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Windows 2003 Terminal Server and Sound
Hi, I am attempting to get sound working on a W2K server and failing horribly :( The sound device was picked up correctly as a ES1370 and shows as being functional; yet when I rdesktop -r sound:remote server name and run Media Player it reports that it is unable to open the device. I have read that it could be due to QEMU_AUDIO_DRV not being set. Any help and advice would be gratefully appreciated. -- Thanks, UxBoD -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows 2003 Terminal Server and Sound
On Tuesday, June 22, 2010, 12:42:27, --[ UxBoD ]-- wrote: I am attempting to get sound working on a W2K server and failing horribly :( The sound device was picked up correctly as a ES1370 and shows as being functional; yet when I rdesktop -r sound:remote server name and run Media Player it reports that it is unable to open the device. If you're using a terminal services connection to the machine, it doesn't need a sound card - sound is provided by the remote service itself. Note however that Windows 2000 doesn't support sound through terminal connection - you need XP or newer. -- Jernej Simončič http://eternallybored.org/ Pills to be taken in twos always come out of the bottle in threes. -- Davis's Basic Law of Medicine -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
No sound
Hi folks, Host - Debian 5.0 KVM VM - Ubuntu 9.10 No sound on playing youtube. Volume on host and VM has been turned to max, Virtual Machine Manager Edit - Preferences Install Audio Device [check] Local VM Please help. TIA B.R. Stephen L -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
