No Sound on Ubuntu 9.10 and VMware Workstation 7 (again!)

I was running Windows XP Pro in virtual machines (VMs) within VMware Workstation 7 on a 64-bit Ubuntu 9.10 (Karmic Koala) host.  I had repeatedly had problems with no audio in earlier versions of Workstation (e.g., 6.5.2).  Various fixes, reboots, and other efforts had randomly gotten the audio working again within one or more VMs.

Now I had a new situation:  there was no audio in any VM and, when I checked, I found there was also no sound in Ubuntu itself.  Once again, I ran various searches and began trying various suggestions.  I came across an Ubuntu Community Documentation page on Sound, which led me to another Community page on Sound Troubleshooting Procedure.  Step 1 in that procedure led me to Stéphane Gaudreault's long, step-by-step procedure on upgrading the Advanced Linux Sound Architecture (ALSA) (1.0.22.1) on Karmic.  (On WinXP, using another computer, Stéphane's page loaded in Internet Explorer, but not in Firefox.  It loaded slowly in Firefox in Ubuntu.)  I closed Workstation, and then copied and pasted each line of that procedure into Terminal.  (It was possible to copy and paste multiple lines at once, including line ends; they would run one after another.)  One exception:  as far as I could tell, I did not get the "panelw library not found" error he described, so as he advised, I skipped the "symbolic links" part of his instructions.  Everything seemed to go smoothly until his very last command (sudo alsaconf), which opened the ALSA Configurator.  After clicking OK, the Configurator said, "Searching sound cards," and then gave me this error:

No supported PnP or PCI card found.

Would you like to probe legacy ISA sound cards/chips?

So it seemed that possibly I did not need to go through Stéphane's procedure, though I did appreciate how perfectly it went.  I might have just run "sudo alsaconf" in the first place, assuming I already had some version of ALSA loaded on my computer; doing so might have given me this same hardware-related error notice -- unless Stéphane's procedure was its cause.  That seemed possible; maybe my ALSA was now so new that Ubuntu had not yet caught up.  I tried listening to a WAV file, just in case, but no, sure enough, still no sound.  I ran a search for that error message.  This led to a VIA Technologies Release Note (oddly, not found on the VIA website) that said,

When installing driver, if the ALSA Configurator reminds that "No supported PnP or PCI card found", it means the kernel cannot find the pci audio device. Select "No" to exit the installation and uninstall the driver. Please read Notes b des-cription to resolve the problem.

Exiting the Configurator did not seem to uninstall anything, so I interpreted that part of the Release Note to mean that I was supposed to uninstall the driver myself, somehow.  Notes, point b, in that document said this:

Before installation, make sure your linux kernel can find the pci audio device first. If your kernel can not find any pci device with command 'lspci', you'd better add an option in /boot/grub/menu.1st file. At the end of line with "kernel /boot/vmlinuz-xxxx", xxxx is the kernel version, add the following:

pci=conf1

This information appeared to mean that I should have done this before going through Stéphane's procedure.  I didn't know how to undo that procedure, so I decided to poke around a bit more, in search of other possibilities.  I started back at the Sound Troubleshooting Procedures (STP) page.  It gave me several commands to copy and paste into Terminal.  This gave me a link to Stephen Olesen's Pastebin website, where all kinds of information about my system was automatically posted for other people to see and, presumably, help me with.  The last message produced by those commands I cut and pasted was, "Please inform the person helping you."  So apparently I could post a question in a forum somewhere, and include the Pastebin address instead of cluttering up the forum with all that information about my system.

Anyway, the STP page said that the Pastebin file should contain some indication of the "Driver version," the "Library version," and the "Utilities version."  I tried searching the Pastebin file for "Driver version" and, sure enough, there it was, not far from the top.  It said this:

ALSA Version
------------
Driver version: 1.0.22.1
Library version: 1.0.22
Utilities version: 1.0.22

That didn't look like an exact match.  I wasn't sure if 1.0.22.1 was close enough to the others.  The STP page said the numbers needed to be equal.  If they weren't, then (a) one of the ALSA components was not successfully upgraded (which I didn't think was the problem, as I had seen no error messages), or (b) I booted an older kernel version (which wasn't the case either).  Anyway, there seemed to be a mismatch between my ALSA version and my Ubuntu kernel.  So it still looked like I would need to reinstall ALSA.  But then it occurred to me that I hadn't run the lspci command, as suggested by the Release Note (above), to see if my kernel could find a PCI device.  It found a bunch of PCI devices, including "MCP61 High Definition Audio."  Hmm.  Puzzling!

OK, well, the STP page had one more, very long line to copy and paste into Terminal.  If my driver version numbers (above) were acceptably similar to one another, maybe this was all I needed to do.  So I tried that.  It ran, but I couldn't tell for sure if it was happy.  I tried "sudo alsaconf" again.  Still the same result.  Mark Rijckenberg suggested, to someone having a similar problem, that they either revert to an earlier version of ALSA (which hadn't been working for me) or else consider switching from x64 back to 32-bit Ubuntu.  Having had many problems with 64-bit Ubuntu -- orphan problems, especially, that almost nobody else seemed to be having -- and having wrestled with the sound problem repeatedly for the past year, I decided to try my luck with 32-bit Karmic.  I describe the downgrading process in a separate post.

Another Try with VMware Workstation and Player

In a previous post, I described how I was sometimes getting no audio from my VMware virtual machines (VMs), at times when my 64-bit Ubuntu 9.04 (Jaunty Jackalope) installation on that same computer was able to play the same files without a problem. I experimented with VirtualBox as an alternative, but that was coming along slowly at this point, so I decided to give VMware another try. I had been using 64-bit VMware Workstation 6.5.2 to run 32-bit Windows XP VMs on this computer. I now recalled that, lately, I had begun to use VMware Player instead of Workstation to run some of my VMs. I wondered whether Player was somehow messing up my audio settings or my VMs, such that only a reboot or restart of the VM, of VMware, or of the whole computer would fix it (and sometimes that didn't even do the trick). I think what got me wondering about this was one occasion when I was not able to play an audio file in a VM in Player; but then, without rebooting or restarting anything, I opened another VM in Workstation and was able to play audio just fine - and then the audio in Player was OK too. I hadn't really been paying attention, and therefore wasn't sure that this was exactly how the sequence had unfolded; but I thought it was worth a second look. About a day later, I got my first renewal of flakiness from VMware. I was running a VM in Player. I minimized it and went to work on a different VM in Player. When I went back to the first one, I couldn't find it. That is, there was no entry for it in the taskbar at the bottom of the screen. I had learned, by now, that this didn't mean it had closed down; it just meant it was hiding. On Ubuntu's top panel (i.e., the taskbar running across the top of the screen, which in my case I had moved to the left side of the screen because left-right real estate was less crucial than top-bottom real estate, on my widescreen monitor) I saw the icon showing that VMware was up and running. I clicked on that and, sure enough, there was the name of that hidden VM. I clicked on it. It opened up - but not in Player. It opened up in VMware Workstation. This had happened several times previously, but this was the first time when I was absolutely sure, when I was watching for it. I made it full-screen and resized a few windows in Workstation - it had resumed in less than full-screen mode, which meant (in VMware's way of doing things) that all of the windows I had running in that VMware session were automatically resized - and then I clicked on the top panel. Workstation vanished. I went back to that icon in the left-side panel and brought that VM back onscreen yet again. Fortunately, the audio was still working, so this was as far as my bug-hunt was able to progress at this point. But it did make me wonder, again, whether VMware Player was part of the problem. At present, my sense was that running each VM in its own session of VMware Workstation was the most stable way to go. Postscript: two weeks later, running only Workstation since writing this note, I conclude that Player was indeed the problem. This problem has not recurred for me in Workstation.