Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About mooman

  • Rank
    InsanelyMac Protégé
  1. OK. I did a huge step forwards. I've read that CoreAudio doesn't use HPET, but instead relies on the time stamp counters and some funny calculations with CPU bus speed etc. So, FSB speed does matter. So, looking at dmesg output, nawcoms kernel seems to blindly double the reported FSB speed which seems to completely mess up the TSC. FSB was reported as 201 MHz (which is correct actually), and corrected it to 437 MHz. WTF... I now use AnV's 10.6.8 V8_2 kernel, which at first set the corrected FSB speed to 103 MHz and corrected it to 237MHz. Sound was already a lot less crackling, but still: too fast feeding samples. So I added following to my boot options: fsb=200000000 busratio=16 And now: TSC: Reported FSB: 200.0000MHz, corrected FSB: 200.866380MHz TSC: Verification of clock speed failed. Fallback correction was performed. Please upgrade bootloader. TSC: Frequency = 3213.862080MHz, FSB frequency = 200.866380MHz, bus ratio = 16 That looks better - and Sound is waaaaaaay more usable now. Still not enough to actually listen to music, though. So I raised the sample buffer size of the ensoniq driver by using the boot parameter es_oso=256 (the default is 64). And now I'm almost getting there. It's still a bit glitchy but almost usable. I'll try to get the FSB a little bit below 200MHz, because vmware states that the guest should run a tick slower than the host [1], and try to play with es_oso buffer size [1] http://www.vmware.co...ualMachines.pdf - a little outdated, virtual HPET is available in Workstation 9/Fusion 5 meanwhile. Hope this helps a bit.
  2. I'm struggling with this, too. Zenith432 explained it already here: http://www.insanelym...dpost&p=1252646 Meanwhile I think the problem lies even deeper iin either the kernel (I use nawcom), or at least the whole thing about vmware ws 9's HPET, rtc, etc emulation, or the lack thereof. I even tried to put the Audio drivers out of the way by using Soundflower+Esound to stream to my host's pulseaudio server. Same issue. So I suspect there something going utterly wrong in CoreAudio's resampling/buffering/timing CPU-whise, even before the audio drivers matter. Just out of interest: which kernel are you using?
  3. Nevermind, I found the issue. I used some ready2go 10.6.7 vmware image, and that one seems to have vmware graphics enabled (lightroom 4 trial works on it). I did a complete as-vanilla-as-possible install on my own now, and vmsvga2 works. Auto-fit is just "one-shot" when the window manager loads and refuses to work afterwards, but that's a minor issue. Now I just need to find out how to "enable" graphics for vmsvga2.
  4. Hi, when I install vmsvga2-1.2.4 driver in my SL 10.6.8 VM and reboot, the WindowManager doesn't come up. Means, it boots and at some point I only get the boot splash (or boot log with -v) and a working mouse cursor. Nothing suspicious in vmware.log - ScreenObject and SVGA3D are enabled. The VM runs nawcom legacy 10.8 kernel with -force64, and some weird version of vmware-tools with a VmwareGFX64.kext - I tried uninstalling vmware tools completely or just moving the kexts out of the way - same result. Does anyone have a hint what could be the issue?