VirtualBox

Ticket #5332 (closed defect: duplicate)

Opened 4 years ago

Last modified 4 years ago

AC97 audio doesn't work on Windows 7 64bit guest -> duplicate of #2785

Reported by: t35t0r Owned by:
Priority: major Component: audio
Version: VirtualBox 3.0.10 Keywords: AC97, audio, Windows7
Cc: Guest type: Windows
Host type: other

Description

AC97 audio doesn't work on Windows 7 Pro (Final) 64bit guest on OSX 10.5.8 host under VirtualBox 3.0.10 . I tried with and without the guest additions and I also tried SoundBlaster 16 with and without the guest additions. Neither worked.

Attachments

VBox.log Download (56.7 KB) - added by verdy_p 4 years ago.
no sound in Windows Seven (using Directsound+ICH AC97 driver)

Change History

comment:1 Changed 4 years ago by frank

  • Summary changed from AC97 audio doesn't work on Windows 7 Pro (Final) 64bit guest on OSX 10.5.8 host under VirtualBox 3.0.10 to AC97 audio doesn't work on Windows 7 Pro (Final) 64bit guest on OSX 10.5.8 host

The guest additions are not required for the audio output. Use the AC97 device. Is the virtual soundcard correctly detected by the guest? Note that VirtualBox on Mac OS X hosts doesn't support audio input, only audio output. Please attach a VBox.log file of a VM session when you used the AC97 device.

Changed 4 years ago by verdy_p

no sound in Windows Seven (using Directsound+ICH AC97 driver)

comment:2 Changed 4 years ago by verdy_p

Does not work also for me:

  • Guest is Windows Seven, I tried both the proposed "ICH AC97" emulation driver and the "SoundBlaster 16" emulation driver.
  • Host is Windows XP, or Vista or Seven, all of them configured with WHQL-certified audio drivers (either the drivers from Microsoft itself, or the OEM driver) that support both the SB16 and AC97 specifications.

Here is the VBOX.log (no sound in Windows Seven (using Directsound+ICH AC97 driver))

Guest Windows reports that no audio hardware was not detected, most probably the Plug'n play descriptors reported by the emulation driver is not correct or is not correctly virtualized.

comment:3 Changed 4 years ago by verdy_p

The interesting lines in VBOX.log are these:

00:00:03.994 Audio: Trying driver 'dsound'. 670 00:00:04.061 Audio: set_record_source ars=0 als=0 (not implemented)

Are there other conditions in order to support DirectSound record sources? Does it require the record capabilities when just the play capabilities are needed?

comment:4 Changed 4 years ago by walmartshopper

Same here, no sound with Windows 7 Pro RTM 64bit on a Slackware64 host. I was able to install the Realtek AC97 drivers successfully, and from within the guest, sound appears to be working and the green bar is moving as if sound is being output. However there is nothing coming out of the speakers. Sound is working fine on the same host with an XP guest.

comment:5 Changed 4 years ago by robhancock

Windows Update does not seem to provide a driver for Windows 7 x64 for the ICH AC97 hardware emulated by VirtualBox. Windows 7 32-bit seems to be able to download a driver from Windows Update that works fine (only tested the RC version). This situation is understandable, since I don't think any real 64-bit capable machine would have had that audio chipset so why would anyone release a driver for it (other than for VirtualBox)? The Realtek AC97 drivers do install (though they complain about being unsigned) but on my system (Fedora 11 64-bit host) the audio output is crackling and distorted.

It sounds like the VirtualBox guys should do one of:

-fix the problem with the Realtek AC97 driver and the emulated ICH AC97 -find a different AC97 driver that will install and actually function properly with the emulated hardware -emulate some other hardware like some HDA codec that has native Windows 7 drivers for it available

comment:6 Changed 4 years ago by Technologov

Added myself as CC on this issue. Please change topic name (remove Mac OS X), as it is not related to host OS.

-Technologov

comment:7 Changed 4 years ago by verdy_p

Or add Windows (all versions, or at least XP, Vista and Seven) in the list of Hosts affected by this bug (I've not tested Linux and Unix hosts).

Really, the ICH AC97 driver does not match any one of the hardware plug and play identifiers.

My PC exhibits these PnP hardware identifiers (in the Guest), for which there's simply no driver available on the guest OS and not even on the Additions CD image for guests:

PCI\VEN_8086&DEV_2415&SUBSYS_00008086&REV_01 PCI\VEN_8086&DEV_2415&SUBSYS_00008086 PCI\VEN_8086&DEV_2415&CC_040100 PCI\VEN_8086&DEV_2415&CC_0401

(the vendor ID is for Intel, there's no driver found for it by Microsoft's online database, so I think that there's not even any driver certified for Windows that include these IDs, or that the supplied emulation provides non matching hardware ressources)

The PnP enumerator also indicates that the following compatible IDs should be used to match a driver:

PCI\VEN_8086&DEV_2415&REV_01
PCI\VEN_8086&DEV_2415
PCI\VEN_8086&CC_040100
PCI\VEN_8086&CC_0401
PCI\VEN_8086
PCI\CC_040100
PCI\CC_0401

(clearly the last five are bogous and not enough qualifiying as they don't include a device ID, and just a vendor id and/or a revision, and/or the drivers database contains too many distinct drivers matching the same IDs)

The VirtualAudio driver on the Additions for Guest OS CD just looks for these:

[ControlFlags]
ExcludeFromSelect = *
[Microsoft]
%VIRTUALAUDIO_AA.DeviceDesc%=VIRTUALAUDIO, PCI\VEN_1414&DEV_0007

This entry means use the driver described in the INF file as "VIRTUALAUDIO", for the device matching the hardware ID "PCI\VEN_1414&DEV_0007". According to PnP databases on the web, it is the identifier that should be used to identify: "Microsoft(R) PCI Adapter MN-130", provided by "Microsoft / C-Media Inc.", and whose last known version is "5.12.01.0049" (05/20/2005) but known to work only on Windows 98, NT4, 2000, XP, but NOT on Vista or Seven.

There's no such device reported in the Devices control panel anyway.

The ExcludeFromSelect also forbids automatic selection, but even when trying to select it manually from the "Add New Hardware" dialog, or from the "Update driver" assistant from the Devices control panel (on the single entry with the yellow /!\ symbol described as "Multimedia audio controler", according to its detected device class), this driver is not selectable or gets rejected as incompatible.

So then, I've tried to look on the web for pci&venID=ven_8086&devID=dev_2415

And found this page:

 http://www.netbump.com/hadi/search.php?devType=pci&venID=ven_8086&devID=dev_2415

I tried to use the suggested driver (on Windows Seven), using the most precise ID:

PCI\VEN_8086&DEV_2415&SUBSYS_00008086&REV_01

but it failed most probably due to OS compatibility restrictions (enforced on Vista and Seven).

The only partially matching id must ignore the SUBSYS and REV identifiers (and it suggests the driver from DELL for its notebooks with integrated Intel audio devices):

pci\ven_8086&dev_2415	ftp://ftp.dell.com/audio/Z9479U01.exe

I think that the issue may be related to the fact that the PnP emulation in VirtualBox doesn't properly report the correct SUBSYS value (it could report the VENdor id instead...), or it uses the SUBSYS value as the incorrect VENdor id.

comment:8 Changed 4 years ago by Technologov

But what about Vista 64 ?

comment:11 Changed 4 years ago by Technologov

Please look here:  http://forums.virtualbox.org/viewtopic.php?f=8&t=23224&start=0

and here:  http://forums.virtualbox.org/viewtopic.php?f=15&t=24601

I have not tested those yet, so let me know if they work.

This is just the first step, not the final solution. We need to figure out a way to add those drivers to VBox additions, with permission from Realtek.

-Technologov

comment:17 Changed 4 years ago by robhancock

The Realtek drivers would be a reasonable solution, if they worked properly - there seem to be issues with audio crackling and volume control. Likely that codec doesn't completely match the one VirtualBox is emulating..

comment:18 Changed 4 years ago by Technologov

Bug #4310 looks like a duplicate of this one.

Developers: Please change topic: "AC97 audio doesn't work on Windows 7 Pro (Final) 64bit guest on OSX 10.5.8 host" --> "AC97 audio doesn't work on Windows 7 64bit guest"

-Technologov

comment:19 Changed 4 years ago by Technologov

Bug #2785 is related to this one.

-Technologov

comment:20 Changed 4 years ago by sandervl73

  • Host type changed from Mac OS X to other
  • Summary changed from AC97 audio doesn't work on Windows 7 Pro (Final) 64bit guest on OSX 10.5.8 host to AC97 audio doesn't work on Windows 7 64bit guest

comment:21 Changed 4 years ago by Technologov

Bug #3137 is related to this one.

-Technologov

comment:22 Changed 4 years ago by verdy_p

In fact it should just read "does not work on Windows 7 guest" (because this also includes 32-bit version) "and Vista guest" (where exactly the same symptom is observed)

comment:23 Changed 4 years ago by robhancock

32-bit Windows 7 seems to work fine (I don't know about Vista) because Windows Update is able to find a suitable driver. Only the 64-bit seems to be a problem..

comment:24 Changed 4 years ago by verdy_p

robhancock, can you look at your Device Manager and check which hardware device ID is detected on your installation, does it match any of the hardware id that I gave above ?

Open the Windows device Manager, click in the Multimedia devices category, select the device, and open its properties. Then look for the "hardware device IDs" or the "compatible device ID's: this is those IDs that are used y the device manager to accept compatible drivers, and that are also searched online with Windows Update.

If, this can explain why Windows Update can find a driver for you, and not for me. But someone needs to explain then why my "virtualized" hardware PnP device Ids are different.

If you have one of the ID's above, can you point the location where you downloaded the driver ? Or say which is the manufacturer and version, as reported in your installed device ?

May be it works because your actual audio on the host is effectively compatible with AC'97 and your audio device is still more basic

But more recent "HD Audio" devices are not all directly compatible with this older AC'97 specification (which seems to be supported only as a local-only virtualization, indirectly on the guest where it reuses the actual HD Audio driver in a lower layer of the guest OS, and only t oprovide backward compatibility within some applications); HD Audio devices include additional security requirements (which are part of the DirectSound driver model specification) for managing, for example, the HDCP protocol over HDMI and digital audio output jacks, and for managing DRM rights and data encryption for the highest quality output (including within the audio mixer which cannot mix unsecured and secured audio sources and render a high quality mixed signal to an unsecured analog output).

I'm not even sure that VirtualBox can deliver secured "HD" audio over the virtualized device without breaking the authentication chain, if the driver installed on the guest is not itself "certified" by Microsoft WHQL, or at least digitally signed with a software certificate from as "reliable" PKI provider.

Another cause of problem is the possible lack of implementation (in the VirtualBox host) of the audio data format coming from the guest: I've tried to change it to quite "common" 16-bit µ-law 44.1kHz dual-channel/stereo (usual CD quality level, normally not needing the HD security requirements), then to other lower quality data formats down to 8-bit µ-law or A-law differential 11.025kHz single-channel/mono (usual AM radio quality), and this does not change anything as the speakers are still silent (no error).

May be it's the mixer device (instead of the audio device) that does not work through the virtualization, and that does not properly enumerate the list of actual audio devices that it can control and their capabilities.

comment:25 Changed 4 years ago by robhancock

Actually, I can't entirely verify that it works with Windows 7 32-bit final release, but I do have a VirtualBox VM running the Windows 7 release candidate 32-bit and Windows Update was able to find a suitable driver there, for Intel 82801AA AC'97 Audio Controller provided by Microsoft. The listed hardware IDs are the same as you posted. The actual ac97intc.sys file in the driver is copyright 1998-2001 so it seems a fairly old driver.

The 82801AA ICH is very old at this point, it was released with the original Intel 810 chipset in 1999. As I mentioned, no actual 64-bit-capable machine would have had this hardware.

The host audio doesn't have anything to do with it, the audio is fully virtualized. (The host audio is HDA on this system.)

comment:26 Changed 4 years ago by agreen111

Hi, it's works  http://www.64bitdrivers.com/spoof.php?id=1399

includes \6251_Vista_APO\Vista64

comment:27 Changed 4 years ago by verdy_p

Avoid this redirecting link (which generates invalid requests and breaks the download, so that the ZIP file appears corrupted, apparently caused by a broken anti-bot script; I note that the redirector sometimes generates HTTP 500 server errors, or causes the ZIP file to be truncated after just a couple of megabytes).

Use instead this direct link which is much more reliable:  http://www.64bitdrivers.com/files/6251_Vista_APO.zip (30,002,195 bytes)

I had already tried this driver. This has just worked once, then failed again after restarting Windows (no more sound). Apparently this driver still has difficulties to find the virtualized hardware.

And possibly, this indicates a stability problem in the exposed ICH6 emulation used in VirtualBox, or the driver assumes some behavior (ordering of events? missing or unexpected interrupt? incorrect/random value of some flag bits in the registers after plyaing sound?) of the original hardware that the ICH emulation does not fully support, and possibly the driver adapts itself

Note that the original Intel ICH6 hardware had known severe hardware bugs, documented by Intel, and some drivers have been tweaked to autodetect these caveats in order to avoid complete system lockup, notably when handling bus mastering;

Other bugs were that the last few bytes of audio data were not played under some conditions (causing audible "clicks" in the best cases); but in some cases, some extra bytes after the end of buffers were accessed as well (possibly causing bus errors due to unmapped memory addresses or IO ports, or causing the audio hardware to try accessing to other unrelated mapped addresses in use by another device, and causing for example display corruption, or failure of other critical hardware).

It's possible that these drivers are autodetecting one of those known failing hardwares and readapt themselves by using some workaround (for example by padding the audio buffer with additional bytes), using some entries/flags in the registry to remember this (the safest methods being to pad the audio data with extra bytes, or to avoid some of the failing buffer lengths that have been documented by Intel, and being careful about data alignment). It may explain why this audio device is no longer supported by Intel, Microsoft, or the OEM manufacturers that included it.

Clearly, the choice of the old ICH for the virtualized emulation was a really poor choice of VirtualBox designers, and it would have been much better to emulate a supported device without such known hardware bugs: so upgrading the emulated device to a later release of ICH (without these known bugs) seems a more reliable long-term solution.

comment:28 Changed 4 years ago by verdy_p

This discussion will be useful for ICH audio emulation, and their known hardware problems (including clock problems, causing audio to be played "too fast" at higher frequency than expected):

 http://www.cs.cmu.edu/~412/history/2006F/ac97/

comment:29 Changed 4 years ago by sandervl73

verdy_p: I'm impressed by your rock solid conclusion about our poor design decisions after googling around a bit. Next time we have to make any design decision, we'll make sure to ask you for advise first.

comment:30 Changed 4 years ago by Technologov

  1. I don't see any connection between AC97 audio and ICH6 Hard Disk controller.
  1. I am happy with older PIIX3/4 HDD controllers, and see little need to move to ICH6.

-Technologov

comment:31 Changed 4 years ago by ni81036

ICH6 is not only hard disk controller, but whole chipset specification. Moreover, our ICH6 emulation is mostly just faking appropriate PCI ID, to make certain guests happy - behavior is mostly of PIIX3.

comment:32 Changed 4 years ago by verdy_p

Forget the erroneous "6" that I added inadvertantly after "ICH". But it's true the the ICO/ICH0 whole chipset has been upgraded since lone to version that did not have the various hardware bugs, so not needing the various workarounds implemented in Windows audio drivers.

The only important thing here is that this is an unsupported device, and you cannot expect that it will work today or even less tomorrow. The only thing to do is then to upgrade the emulation to a more recent version. I suggest ICH4, which DOES include a AC'97 audio device supporting HDA, but I absolutely don't know if this changes a lot of things in your current hardware emulation. But if this can work, it will make RealTek audio drivers certainly happier withit, with less unsupported workarounds for old hardware bugs.

Yes I've googled all around to find a solution, and still I cannot find any one. None of the solutions found do really apply to VirtualBox emulations, because all these solutions (using various OEM drivers with various workarounds for the same problems) are only meant to solve variably the same issues in a real hardware (but not in the virtual emulation where they are not at all relevant and where they would finally cause more problems).

And yes, sandervl73, I understand that your reply was a joke (a form of disguised critic). I don't want to criticize the way you are programming. But I REALLY cannot understand why you chose to emulate a completely unsupported hardware with known problems (even if you had full documentations about it : these docs are certainly not describing enough details if they do not describe the workarounds that have been impelmented on top of them, because even this documentation was certainly bogous and not reflecting the reality as it was perceived in the old Windows drivers written for that bogous hardware device.

(But is there only a single device today, without known hardware bugs/problems? Even CPU processors have bugs, the situation is even worse with today's GPUs which are even more complex and where none of them are fully working fully as described in specs, or even wokeing the same way in the same production series, with some parts generating errors that need local corrections, or with parts failing quite rapidly because of heat or because of random defects in the chemical production process; chipsets are also very complex units as they work with so many different clock constraints, that need special autodetection algorithms to provide alternate working paths either in the software driver or in the mutable firmware embedded in the firmware. Many fast devices are produced today, and then tweaked after production by running series of tests to disable some parts of the device. Many flat screens are sold with a few "acceptable" dead pixels for the same reason, otherwise the production would not suffice to the demand, and the devices would be much more expensive; Intel, AMD, and nVidia are doing the same with their CPU and GPU processors and chipsets, by recycling and downgrading them when they can't fully reach the expected zero-default level for which they were initially built: they fuse out some limitations permanently in them to avoid these defects that start being dramatic at the highest frequencies, or they fuse some power management capabilities. These are just a few examples, but they don't always report this in the marketed product type, when they judge that the disabled feature is not essential for their market, or when they can provide workarounds around some common defects).

comment:33 Changed 4 years ago by robhancock

verdy_p: AC97 and HDA are totally and completely different standards, there is no such thing as an AC97 supporting HDA.

Implementing a virtual HDA controller is likely the way for the VBox guys to go long term (it's supposed on modern Windows and Linux versions without manufacturer-specific drivers) but that's a non-trivial endeavor.

Adding an option for an AC97 controller that Windows 7 64-bit actually has a driver for that actually works might be a better short-term solution.

comment:34 Changed 4 years ago by verdy_p

Oooohhh... Strange enough, my PC supports both AC97 and HDA (it also supports some old games that just support the SB16 working mode), do you mean that it actually has two parallel devices? Or that one is supported only by its OEM driver building some sort of virtual AC97 interface (AC-Link) on top of HDA ? It seems that for Windows, the WDM driver model does not really make a difference between them : as long as the OEM driver correctly exposes the capabilities, all these will still work fine (the driver are supposed to implement what they claim to support, and Windows will attempt to fill the missing capabilities by using a software emulation, using the other exposed and supposedly working capabilities)

comment:35 Changed 4 years ago by robhancock

It almost certainly doesn't support both.. I think you're misunderstanding how the driver interface works - AC97 vs. HDA is a matter between the driver and the hardware, Windows doesn't care which interface it uses aside from what audio features the device claims to support.

comment:36 Changed 4 years ago by sandervl73

verdy_p: It's very simple. All hardware has bugs; the ones you listed don't seem that extraordinary. And keep in mind that we chose the ICH controller 4 to 5 years ago. HDA either wasn't there back then or rather unsupported.

Note that although the discussion isn't useless it really doesn't belong here.

comment:37 Changed 4 years ago by sandervl73

Also note that one important goal of virtualization is to provide a means to run legacy software. That means it really isn't wise to choose to emulate (only) modern hardware.

We will probably add a virtual HDA device next year.

comment:38 Changed 4 years ago by Technologov

The driver posted here doesn't work for me. Tried in Windows 7 32bit and 64bit guests.

Is there a _working_ driver for emulated AC97 or for Sound Blaster 16 ? How VMware Workstation solved this problem ?

-Technologov

comment:39 Changed 4 years ago by Technologov

Small explanation: The driver installed fine, and it appears in Windows 7, and media player in guest "sees" an audio device, but host doesn't produce any sound.

comment:40 Changed 4 years ago by verdy_p

ICH/ICH0 was already deprecated 4 or 5 years ago, and its severe bugs were already known when there were still some OEMs trying to paliate them by supporting some drivers using workarounds.

Anyway, this still does not explain why the SB16 emulation offered in VirtualBox does not work either.

And why do we have to choose either SB16 or ICH/ICH0 ? could'nt these two virtual devices be supported in parallel (for the guest OS, they would be seen as two separate audio devices)?

We could as well use checkboxes to enable/disable each audio emulation (including the legacy BEEP device) if you integrated a mixer to merge these audio sources, or if you could use the audio mixer of the underlying host OS (when it can accept that the same VirtualBox process can generate several audio sources visible and controlable separately in the host's mixer, without having to mix these sources yourself in the VirtualBox application).

And when you'll add a HDA virtual emulation, you'll have a fourth audio source to mix. By default, all these virtual devices could be enabled and made visible to the guest OS, so the guest OS can use whatever device it supports, and users will hear sound. They will be able to select/turn off these virtual devices in their guest OS according to their need, or using the audio mixer of the guest to mute some or all of them. And they'ell be also able to uninstall the "physical" devices from their guest OS by turning off the emulation when unchecking the associated emulations offered by VBOX in its configuration panel.

comment:41 Changed 4 years ago by verdy_p

robhancock, you said "It almost certainly doesn't support both.. I think you're misunderstanding how the driver interface works - AC97 vs. HDA is a matter between the driver and the hardware".

This is definitely not what I see in the BIOS settings of one of my PCs where both configurations are possible, so the hardware must certainly support both working modes. I did not say that this was the same driver to use in Windows. (Such BIOS settings frequently appear when a newer device specification is still not very well supported in older OSes, or when the current driver support for the newer device can cause performance issues, or incompatibilities/instabilities with the current driver model used by the running OS.)

And when both are enabled in BIOS settings, in Windows I will just see 2 separate audio devices, each one with its own system ressources (IO ports, interrupts, memory maps, and/or DMA channels) and its own driver, and both are integrated in the Windows audio mixer. "Dual" audio devices have existed since long now (they have existed even when the SoundBlaster 16 devices appeared, offering either an 8-bit or or 16-bit working mode, or both; in this case, the mixing work was made by the hardware without using CPU ressources to compute a single mono or stereo audio channel...).

And you can still install a secondary hardware audio board in any PC, if you wish, without having to disable the primary audio device (for Windows it does not matter if they use different working modes, it can perfectly handle several audio devices), just like you can also install a secondary display device, or a secondary keyboard, or a secondary disk controler, or a secondary USB host controler (many PCs today include several USB host controlers, or use a controler working in "dual" mode with one virtually connected to the other).

comment:42 Changed 4 years ago by Technologov

Correction: The driver work in most situations, but there are problems when too many VMs trying to use sound.

VirtualBox team: I recommend to ask Realtek to add those drivers to VBox Guest Additions (until we have better solution). I have no idea why they take 80 MB... I hope they can be slimmed down significantly.

We did a similar thing for VBox 1.4 and network drivers for Vista.

I tested on Windows 7 32/64-bit guests and Vista 64-bit guest. Vista 32-bit comes with AC97 driver pre-installed.

-Technologov

comment:43 Changed 4 years ago by robhancock

verdy_p: The SB16 emulation likely doesn't work for the same reason, nobody ever wrote a 64-bit driver for it because nobody would or could use an SB16 in a 64-bit machine.

As far as a device supporting both HDA and AC97, if that's indeed the case, it's either two PCI functions (logical devices) supported by one device, or two separate devices entirely. It remains that AC97 and HDA are not compatible at all, they use entirely separate drivers and implement entirely different interfaces.

Technologov: Given that the Realtek drivers seem to work poorly or not at all for many users I don't think it makes any sense for VBox guys to add them to guest additions when people that really want to try them can install them themselves..

comment:44 Changed 4 years ago by verdy_p

Hmmm... the SB16 emulation does not work in the 32-bit version of VirtualBox (running on a 32-bit version of Windows, and hosting a 32-bit version of Windows).

So the reason is somewhere else, and the response about missing 64-bit support is not relevant. I even suspect that there's a common bug explaining why *both* the SB16 and ICH emulations are not working as intended.

Are you effectively supporting all the needed ressource mappings (IO ports or mapped memory segments, in various 8/16/32-bit mode, possibly using optional DMA channels, and effectively raising the correct IRQ)?

Are the emulated device registers returning the correct flags? Are these registers honoring the correct distinctions between read and write accesses? Are read-write access to registers effectively altering the contents of other related registers? When a register is used to index and remap other registers in the allocated IO space (for example to map audio data buffers in the small IO space before writing to them), is this setting remembered? Are they throwing the expected events (notably IRQs and NMI, but also status flags when not using DMA but just simple polling every time frame)? Do you support all the needed register access orders used by drivers? Are their reported values updated timely and in order (notably status registers, and pending IRQs once they have been handled in the guest OS, in order to allow freeing buffers in the audio queue)? What happens if the guest OS itself uses its own local virtualization (notably for memory-mapped device registers)?

Are you correctly describing the ressources to the guest and honoring the PCI allocations requested by the guest according to the PCI capabilities that were given? Are you supporting power management states described in the ICH specifications (for powering on the device only when it starts being used), or do you assume that these virtual devices will be always on and that the guest's driver will not verify it ?

comment:45 Changed 4 years ago by verdy_p

An alternative: can you build your own logical audio device specification for Windows and simplify the interface in you own driver, by using your existing VM entry function, instead of depending on various IO/memory/DMA/IRQ ressources and working modes? This is what Microsoft apparently did in VirtualPC (and it works very well). This approach would mean that you would have to create and port this driver to various guest OSes (not just Windows, but also MacOSX, Linux, FreeBSD, NetBSD, Solaris, OpenVMS and others that can run on a x86 or IA64 or AMD64-based VM... using their own developement tools, instead of relying on their existing drivers), otherwise the device will not be enumerated and detected. But at least if this can help solve the problem for Windows hosts, and performance issues caused by a complex PCI/PnP emulation layer...

comment:46 Changed 4 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to duplicate

There's too much nonsense here, so I'll create a new ticket and close this one.

Please take this discussion to the forum. I've asked this before and will delete unrelated comments in the future.

comment:47 Changed 4 years ago by sandervl73

  • Summary changed from AC97 audio doesn't work on Windows 7 64bit guest to AC97 audio doesn't work on Windows 7 64bit guest -> duplicate of #2785

comment:48 Changed 4 years ago by verdy_p

Why did you need to restrict this bug to Win64 guest when closing it? The same defect also occurs on Win32 host running a Win32 guest, as well as on Win64 host running a Win32 guest.

I don't think this is specific to the guest (even if sound works on the same machine using the same version of VBOX installed on the same host OS, to run a 32-bit or 64-bit Linux guest: the difference is only in the subset of the device capabilities used by the guest's driver), but lies somewhere in the host part, i.e. directly in the device emulation layer implemented in VBox, which does not properly emulate the device it is supposed to emulate.

comment:49 Changed 4 years ago by robhancock

I don't think there's any problems with the device emulating what it claims to be. The problem is purely that there is no driver that works properly with this device for 64-bit Windows, so it's entirely a guest issue.

comment:50 Changed 4 years ago by verdy_p

Once again, you've not read the log submitted above which clearly indicates that it is running on a Win32 Host, NOT on a Win64 Host. And here too, the sound does not play (and the guest is ALSO Win32). Everywhere above, I spoke about Win32, you've not read it. Really the bug or limitation is not limited to Win64, and I really think it is on the host, not on the guest (even if there's no more supported device for it, all alternate drivers FOR WIN32 do not work: they fail to detect the hardware, these drivers simply don't run as they fail in their detection (or after the first test where the sound is played only once), then never stops, even if the PCI resources are presented to the guest OS and correctly enumerated and allocated and if there are matching PnP IDs. This can only be explained by a bug in the device emulation on the host. And exactly the same VM image (containing an installation of either Vista 32-bit or Windows Seven 32-bit) works sucessfully and can play sounds if using that VM image in VirtualPC (which does not use this virtual device but its own different virtual device, visible with its own PnP ID and its own addional guest driver specific to VirtualPC's emulated sound device).

The sound also works in a 32-bit installation of Linux in the VM image (which works without change, from within VirtualBox or within VirtualPC and on the same hardware machine). This can only be explained by differences in the emulation layer of the host, not on the guests as they are strictly identical.

(their VM images are exact copies of the same ".VHD" image file : I can switch off VirtualBox where sound does not work, and run the same image in VirtualPC where I get sound, then swith off VirtualPC and restart the same VM image in VirtualBox where sound does not work : is it more convincing ?).

Well I'd prefer to use VirtualBox to VirtualPC, because VirtualBox is performing much faster and has several other benefits for the integration in the Windows host (it uses less CPU ressources, and less energy, the CPU is also cooler and the CPU fan is not constantly active like in VirtualPC):

VirtualPC (unlike VirtualBox) also cannot run on Windows Seven if there's no hardware support for VMs in the CPU (Microsoft suppressed this support in Windows Seven where VirtualPC is not compatible and has been integrated in Pro and Ultimate version only...). If your host is running Windows Seven in 32-bit mode with a CPU without the VTX support, only VirtualBox works.

comment:51 Changed 4 years ago by douglasawh

@verdy_p when I first downloaded the drivers, I downloaded the High Definition drivers. Make sure you follow the instructions on ticket #2785 very closely.

comment:52 Changed 4 years ago by verdy_p

Does not work at all (it just worked once, when playing the first sound, then never again, without even changing any setting. Windows must have disabled it due to failure, such as loss of an expected event, or the driver itself tweaked itself its own internal settings in the registry).

And, the "High Definition Audio" driver does not install at all (only the Realtek generic driver produced ONE sound).

Anyway, I've converted all my PCs now to Windows 7 host. And I still don't have any sound in a Windows 7 guest (32bit or 64bit), or Windows XP guest (32bit only), or Windows Vista guest (32 bit or 64bit); I only get sound in a Linux guest.

I can't try with Virtual PC now, because it is not supported on Windows 7. Do I need a VirtualServer 2008 host ? Certainly no, I won't buy it (and anyway none of my PCs have the support for hardware virtualization, even the msot recent one that I bought 1 month ago, due to ambiguous Intel specifications of its processor which has two distinct models with the same commercial name... OEM manufacturers like HP or Dell still sell PC without clearly indicating if they support VTX, even if they indicate "Windows 7 ready" and "64bit version suppported")

Could that be caused by lack of hardware virtualization? In that case you'll still need to support it for some time (at least for the next 3 years), because lots of customers will ONLY be able to support paravirtualization (In VirtualPC for Vista, this is what Microsoft chose, using a simple entry to the hypervisor, for its virtual audio device driver).

comment:53 Changed 4 years ago by verdy_p

You can close the issue for me : now the sound works for running Windows 7 32-bit or Intel-64 or AMD-64 guests, or running Linux with 32-bit or Intel-64 or AMD-64 guests, or Solaris (on Windows 7, 64-bit or 32-bit hosts).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use