I'm considering buying SoundEasy 14 so I can start getting more into speaker design. Right now, my last-ever PC is running win2k, which apparently can't run SE14 (?). I'll soon be retiring it and migrating all my old files and apps over to vmware fusion / win xp.
But, it seems like the SE14 USB key and sound card (in my case, it's a Motu 828mkII firewire interface) could be trouble spots with vmware. Has anyone tried this? I'm sure it would work just fine under Boot Camp, but VMWare is sooo much more convenient, I don't want the hassle of booting back and forth (I very rarely reboot my Macs), and I especially don't want to deal with any windows activation headaches associated with doing so.
Any other Mac users, please share your experiences with SE14 (or other diy-audio related software) and Win XP / VMWare. Any problems, fixes, or suggestions are welcome.
But, it seems like the SE14 USB key and sound card (in my case, it's a Motu 828mkII firewire interface) could be trouble spots with vmware. Has anyone tried this? I'm sure it would work just fine under Boot Camp, but VMWare is sooo much more convenient, I don't want the hassle of booting back and forth (I very rarely reboot my Macs), and I especially don't want to deal with any windows activation headaches associated with doing so.
Any other Mac users, please share your experiences with SE14 (or other diy-audio related software) and Win XP / VMWare. Any problems, fixes, or suggestions are welcome.
I have Soundeasy, but unfortunately, all my Macs are old and Power PC based. I would love to hear that it does run, then it would be another reason to think of upgrading to a shiny new Mac mini.
Actually, to be completely honest, apart from the bling it would be the only reason. All my Macs do exactly what is required, and none of them is newer than five years old. Front Row might be handy for my music server though.
Actually, to be completely honest, apart from the bling it would be the only reason. All my Macs do exactly what is required, and none of them is newer than five years old. Front Row might be handy for my music server though.
Never did find any answers out there... so I took a deep breath and hit the 'buy' button.
So far, so good. SoundEasy and it's USB security dongle are working just fine under vmware / Windows XP (Leopard is the host OS, of course). The real problem is that Firewire support under vmware totally sucks. In fact, it's non-existant. So my MOTU 828mkII doesn't work at all.
I should have recognized this problem in advance, as it comes down to the nitty-gritty technical aspects of how hardware and software are set up for USB vs. FireWire... a subject I'm already well familiar with. One of the reasons FireWire is so much better for audio is that it was conceived from the start as an interface for high performance multimedia (video, audio). As a result, a lot of the important timing and IO management functions are done directly in hardware (DMA engines and so forth). That's why 1394 chipsets all have their own dedicated 24.576MHz crystal - native audio/video timing in hardware. As a result, it's very difficult for a virtualized OS to share the firewire chipset - the OS drivers offload too much stuff down to the hardware level, and those resources cannot really be shared.
USB, on the other hand, is just a dumb data pipe - it merely passes all the data up to the OS. That's why the chipsets are so cheap - the hardware doesn't do anything other than pass data back and forth. This creates a lot of CPU overhead when you're doing multimedia stuff, since the OS now has to micro-manage the transactions on the bus, and handle difficult timing / synchronization tasks (not trivial). This is also the reason that FireWire consistently delivers much better throughput performance than ostensibly similar-speed USB, even on simple things like read / write to an external hard disk.
However, in a virtualized environment, USB's simplicity turns out to be a benefit, since individual USB devices can be captured by one OS or another, coexisting on the same platform. The chipset doesn't care because it's just a pass-through, so all the virtualization software needs to do is ensure that only one OS can access a connected device at one time. Once an OS owns a USB device, it's drivers talk directly to that device - there's really nothing to configure in the motherboard chipset.
The result is: I'm now going to buy a USB audio interface for SoundEasy - probably the EMU 0404 USB2. Given how amazingly well vmware supports USB, I have no doubts that it'll work just fine.
So, a word of warning to all you would-be vmware / audio users out there: FireWire and virtualization do not play well together.
So far, so good. SoundEasy and it's USB security dongle are working just fine under vmware / Windows XP (Leopard is the host OS, of course). The real problem is that Firewire support under vmware totally sucks. In fact, it's non-existant. So my MOTU 828mkII doesn't work at all.
I should have recognized this problem in advance, as it comes down to the nitty-gritty technical aspects of how hardware and software are set up for USB vs. FireWire... a subject I'm already well familiar with. One of the reasons FireWire is so much better for audio is that it was conceived from the start as an interface for high performance multimedia (video, audio). As a result, a lot of the important timing and IO management functions are done directly in hardware (DMA engines and so forth). That's why 1394 chipsets all have their own dedicated 24.576MHz crystal - native audio/video timing in hardware. As a result, it's very difficult for a virtualized OS to share the firewire chipset - the OS drivers offload too much stuff down to the hardware level, and those resources cannot really be shared.
USB, on the other hand, is just a dumb data pipe - it merely passes all the data up to the OS. That's why the chipsets are so cheap - the hardware doesn't do anything other than pass data back and forth. This creates a lot of CPU overhead when you're doing multimedia stuff, since the OS now has to micro-manage the transactions on the bus, and handle difficult timing / synchronization tasks (not trivial). This is also the reason that FireWire consistently delivers much better throughput performance than ostensibly similar-speed USB, even on simple things like read / write to an external hard disk.
However, in a virtualized environment, USB's simplicity turns out to be a benefit, since individual USB devices can be captured by one OS or another, coexisting on the same platform. The chipset doesn't care because it's just a pass-through, so all the virtualization software needs to do is ensure that only one OS can access a connected device at one time. Once an OS owns a USB device, it's drivers talk directly to that device - there's really nothing to configure in the motherboard chipset.
The result is: I'm now going to buy a USB audio interface for SoundEasy - probably the EMU 0404 USB2. Given how amazingly well vmware supports USB, I have no doubts that it'll work just fine.
So, a word of warning to all you would-be vmware / audio users out there: FireWire and virtualization do not play well together.
It took me a while to get it working.
The EMU will not work directly under XP. Their drivers are junk (no surprise, it's from Creative Labs) - the XP installer fails every time, even though the device is connected and windows recognizes it, etc. It is the only USB device I've encountered so far that does not work properly under vmware, and I'm pretty sure it's the driver software messing up, not windows or vmware. The driver / installer is probably trying to do some hare-brained low-level idiocy, bypassing the standard APIs. There's a reason standards exist, folks - it's called compatibility (imagine)! EMU / Creative Labs tech support was, as expected, useless "Umm... we don't support that".
However, I was still able to get sound in/out by installing the EMU under OSX and using the vmware built-in audio 'driver'. You may have to go into your OSX sound preferences and set the EMU as the default interface. If you are using your Mac's built-in interface, go to "Utilities > Audio Midi Setup" and group the inputs and outputs you want to use as a single "aggregate device" there, then make sure that aggregate device is set as default interface in preferences. I found that you must have the EMU connected and turned on before you open vmware or boot the virtual machine. Last but not least, try re-installing the vmware tools inside XP.
Finicky, but my setup is working at long last.
The EMU will not work directly under XP. Their drivers are junk (no surprise, it's from Creative Labs) - the XP installer fails every time, even though the device is connected and windows recognizes it, etc. It is the only USB device I've encountered so far that does not work properly under vmware, and I'm pretty sure it's the driver software messing up, not windows or vmware. The driver / installer is probably trying to do some hare-brained low-level idiocy, bypassing the standard APIs. There's a reason standards exist, folks - it's called compatibility (imagine)! EMU / Creative Labs tech support was, as expected, useless "Umm... we don't support that".
However, I was still able to get sound in/out by installing the EMU under OSX and using the vmware built-in audio 'driver'. You may have to go into your OSX sound preferences and set the EMU as the default interface. If you are using your Mac's built-in interface, go to "Utilities > Audio Midi Setup" and group the inputs and outputs you want to use as a single "aggregate device" there, then make sure that aggregate device is set as default interface in preferences. I found that you must have the EMU connected and turned on before you open vmware or boot the virtual machine. Last but not least, try re-installing the vmware tools inside XP.
Finicky, but my setup is working at long last.
One other odd thing I noticed - when I hook up my microphone to the EMU, I can turn up the gain until the signal level is nearly clipping, but inside XP / SoundEasy, the level indication is way down from the top of the scale. Seems like there is some level shifting going on, which attenuates the audio level and leaves an MSB or three empty by the time the bits make it into SE.
Wouldn't be easier to run XP through the Bootcamp? I do it on my big Mac and it runs like a champ. To be honest it runs better than PC running XP. That will save you from all the trouble in my mind. I have four discs insatlled, two for OSX, one for XP, and one for Vista, and is very fast and easy to switch.
By the way there is one company that is worst than Craetive Labs when it comes to drivers, and that is M Audio. From different standpoint, keep your EMU out of speaker testing, it's to god for that.
By the way there is one company that is worst than Craetive Labs when it comes to drivers, and that is M Audio. From different standpoint, keep your EMU out of speaker testing, it's to god for that.
True, but I already had my copy of XP installed in vmware... if I could boot XP directly and also within the VM without all the activation headaches, I would. But I am emphatically NOT buying another XP license just so I can run both ways on the same machine. Given the choice, I prefer the convenience of running XP under OSX so I can use the two concurrently - two cores for XP, 6 cores for OSX - plenty to go around. The hassles have been relatively minor (so far). With a little luck, the virtualization will continue to get better, and some of these issues will be resolved.
It seems to me that Microsoft is really distorting the terms of their XP license by preventing dual-environment booting (or whatever you want to call it) - it is, ultimately, the same underlying physical hardware, which I believe is what their license terms dictate, but they keep insisting that a virtual machine constitutes different hardware. This is an absurd assertion in my opinion. But until a class action suit happens, I guess we're SOL.
The hassles have been relatively minor (so far). With a little luck, the virtualization will continue to get better, and some of these issues will be resolved.It seems to me that Microsoft is really distorting the terms of their XP license by preventing dual-environment booting (or whatever you want to call it) - it is, ultimately, the same underlying physical hardware, which I believe is what their license terms dictate, but they keep insisting that a virtual machine constitutes different hardware. This is an absurd assertion in my opinion. But until a class action suit happens, I guess we're SOL.
Did you try to you install the same XP on that machine? I believe you will have no problem running it both ways. I believe XP is is looking for hardware address. I am pretty sure because I used same XP on both discs where the second one I upgraded to Vista - I purchased just upgrade Ulimate Vista, not a full version.
As for the EMU, well yes I use it for other things (headphone listening) sometimes too. But I have something even better up my sleeve - I am collaborating with a small group of dedicated DIYers on an FPGA-based USB2 DAC. This will be a giant-killer, having all the goodness of bit-perfect data transfer (since we are writing all of the software, the drivers will be clean and lightweight), obsessive-compulsive local clock generation and distribution from a super-high grade XO, and so on. Plus, the FPGA will have enormous capability for custom DSP functions - purist oversampling filters, speaker EQ, room EQ, crossovers, and whatnot. All of this digital whiz-bang will of course interconnect with the most important part: a separate DIY DAC board. We are aiming for the stars with that project - it is intended to be a complete no-compromise computer audio platform, and the DAC boards are separate, so they can be changed and upgraded as the analog technology evolves, or even just to try out different DAC chips for the heck of it. I'm enthusiastic, but we are still getting started, so there's a lot of work to be done yet. Maybe in time for next BAF, maybe not. Who knows?
Yes, FireWire is unquestionably the superior interface. The problem for DIY is the software complexity - a device must have a lot of smarts in it because FireWire uses essentially a networking protocol. Perhaps a few thousand lines of code are needed, and there are limited open-source options so you would probably be writing all of that plus the OS drivers, then debugging it - it's a very big task for just a couple of people in their spare time.
USB's simplicity is therefore an asset for DIY. The lack of clock management is made up for by buffering on each end, and relying on two-way communication at high speed. In the days of USB 1 / "Full Speed" (what a horrible marketing-ism), there was barely enough bandwidth to handle 2 channels, so the clocking schemes were all badly compromised. USB 2 can band-aid the clocking problem for a single device attached to a single computer, but all the extra speed is no help if there is more than one audio device which needs to work together... keeping multiple devices in sync takes a time-stamped protocol over a fully synchronous full duplex physical interface like firewire.
USB's simplicity is therefore an asset for DIY. The lack of clock management is made up for by buffering on each end, and relying on two-way communication at high speed. In the days of USB 1 / "Full Speed" (what a horrible marketing-ism), there was barely enough bandwidth to handle 2 channels, so the clocking schemes were all badly compromised. USB 2 can band-aid the clocking problem for a single device attached to a single computer, but all the extra speed is no help if there is more than one audio device which needs to work together... keeping multiple devices in sync takes a time-stamped protocol over a fully synchronous full duplex physical interface like firewire.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.