Like many people around the world, yesterday was spent with family and friends gift giving and much to much eating (the fried rice and turkey was fantastic).
Last night though I received an unexpected gift, from windows - a corrupted hard disk. Oh what a joyous event, a little drive that could was now a little drive that couldn't. Well by little I actually mean 500Gig. So after a few attempts at booting windows, Last Known Good, Safe Mode, Safe Mode Command Prompt etc, I then attempted a restore and low and behold the windows recovery option couldn't recognize the installation. Enough to drive your sanity to the limits.
I attempted to use a Recovery CD - Linux based and while I could use one tool to see the files in the drive still - or at least a listing, that was about it. GParted realised the disk was corrupt and instead recommended chdsk be run before trying to use GParted again. So cutting an unexciting story short, 16hours latter and chkdsk is still running. It's found a whole heap of problems and is still cracking along, slowly.
But here is the real lesson in the story (not the usual back up your stuff one) - avoid hibernate / sleep / standby in windows. Before the crash I had been copying files between two local drives, it had then gone in to standby - when I returned to the PC it was reporting a CRC error in the copy. My first though was a stuffed disk but since watching chkdsk I am thinking again - most of the corruption relates to files which were being copied, the point where windows was crashing relating to the disks or acpi. At the moment it's still a hunch but this MS knowledge base article isn't very reassuring Hard disk may become corrupted when entering standby or hibernation or when writing a memory dump
Any way heres hoping for a happy ending. I think I have at least another 8 hours of disk checking before I'll know the results. After that I'll be avoiding sleep / hibernation and standby, but thats just me.
Hope your technology this Christmas works better for you than it has me ;-)
Tuesday, December 25, 2007
Saturday, December 22, 2007
Open Source Audio on Windows with OpenAl.Net and Tao.OpenAl
I for some reason have a passion for Open Source Audio on Windows. I've got no idea why I don't just cross over and use Linux and its already fantastic collection of Audio programs (Hydrogen - an advanced drum machine, Rosegarden - Composition tool with MIDI support, Ardour - professional audio editing, multi-track audio mixing etc.) but for some reason I just enjoy C# and the IDE so I'm not moving, at least for the time being ;-)
Any way to get going with Open Source audio libraries in the .Net world there are a few good choices - so far I've used SDL.Net and OpenAl.Net (With Tao.OpenAl - it's a dependency for OpenAl.Net and Tao.SDL - it's a dependency for SDL.Net) and have had really good results.
Currently OpenSebJ - vScaleNotes, the high quality audio, fully sampled, virtual instrument tool, utalises SDL.Net for all of the sample playback and it will soon be using OpenAl.Net for all of the stream to disk recording.
I'm starting down the path of migrating OpenSebJ to Open Source only dependencies, currently OpenSebJ still requires the Managed DirectX libraries to function and as I've spoke of previously, accessibility is a serious issue here - that and the fact that Microsoft aren't further developing the MDX libraries. So a serious port is needed here, hopefully my object encapsulation is going to make this fairly easy ;-) Although I know some functions won't be supported going forward.
The fun part about using these libraries is making sure that you can package all of the dependencies in a single installer and make it really easy for people to use, rather than requiring a separate installation - some times though, the documentation can be a little lacking. So here's a little documentation for those looking for the requirements:
OpenAl.Net
OpenAl.Net requires the Tao.OpenAl framework; the Tao.OpenAl framework does the leg work interop'ing with the OpenAl DLL's.
To use OpenAl.Net in your project:
SDL.Net
Similar to OpenAL.Net SDL.Net needs Tao.SDL to do the leg work with the underlying SDL DLL's. SDL.Net is fairly similar to setup but doesn't have audio recording support.
To use it in your project:
The really cool thing is that all of these files can be bundled in the installer. Keep a copy of the original sources, as per the GPL and make sure they are included or accessible. Too easy, well once you know the score any way.
Happy Open Source Audio Programing ;-)
Any way to get going with Open Source audio libraries in the .Net world there are a few good choices - so far I've used SDL.Net and OpenAl.Net (With Tao.OpenAl - it's a dependency for OpenAl.Net and Tao.SDL - it's a dependency for SDL.Net) and have had really good results.
Currently OpenSebJ - vScaleNotes, the high quality audio, fully sampled, virtual instrument tool, utalises SDL.Net for all of the sample playback and it will soon be using OpenAl.Net for all of the stream to disk recording.
I'm starting down the path of migrating OpenSebJ to Open Source only dependencies, currently OpenSebJ still requires the Managed DirectX libraries to function and as I've spoke of previously, accessibility is a serious issue here - that and the fact that Microsoft aren't further developing the MDX libraries. So a serious port is needed here, hopefully my object encapsulation is going to make this fairly easy ;-) Although I know some functions won't be supported going forward.
The fun part about using these libraries is making sure that you can package all of the dependencies in a single installer and make it really easy for people to use, rather than requiring a separate installation - some times though, the documentation can be a little lacking. So here's a little documentation for those looking for the requirements:
OpenAl.Net
OpenAl.Net requires the Tao.OpenAl framework; the Tao.OpenAl framework does the leg work interop'ing with the OpenAl DLL's.
To use OpenAl.Net in your project:
- Add a dependency linking to OpenAl.Net
- OpenAl.Net has a dependency to Tao.OpenAL but if you load Tao.OpenAl into your project make sure it is linked properly
- Make sure the OpenAl DLL's are accessible, for instance in the output directory. You need alut.dll , OpenAL32.dll & wrap_oal.dll - if you don't have all 3, like if you only have alut.dll you will get an error message from the compiler saying that it can't find alut.dll - you need the other ones even though the compiler error message is wrong - I hate that, any way that's why I'm writing this ;-)
- So in your directory with your program you should have alut.dll , OpenAL32.dll , wrap_oal.dll , OpenALDotNet.dll , Tao.OpenAl.dll , AdvanceMath.dll , csogg.dll , csvorbis.dll
SDL.Net
Similar to OpenAL.Net SDL.Net needs Tao.SDL to do the leg work with the underlying SDL DLL's. SDL.Net is fairly similar to setup but doesn't have audio recording support.
To use it in your project:
- Add a reference to SDL.Net
- SDL.Net has a dependency to Tao.SDL but if you load Tao.SDL into your project make sure it is linked properly
- Make sure the SDL DLL's are available - you need a copy of SDL.dll , SDL_gfx.dll , SDL_mixer.dll - just throw them in the output directory if you don't care about locations ;-)
- Now in the output directory you should have SDL.dll , SDL_gfx.dll , SDL_mixer.dll, SdlDotNet.dll & Tao.Sdl.dll
The really cool thing is that all of these files can be bundled in the installer. Keep a copy of the original sources, as per the GPL and make sure they are included or accessible. Too easy, well once you know the score any way.
Happy Open Source Audio Programing ;-)
64 Bit Windows with C# Express .Net and 32 Bit DLL's
An architecture change is always welcome and the 64 Bit world presents new and options for memory management and the like but there is certainly a price to pay for this shift. So far my personal experience with the 64 bit world has been one of mixed emotions, many hours of things not working, spending time researching on the net and looking for obtuse answers that sort of solve our problems.
The latest one is trying to develop using C# Express 2008 on Windows XP 64 Bit Edition and then using interoperability with a 32 Bit DLL - OpenAl. For some reason the compiler doesn't realise that the 32 Bit DLL is just that, 32 Bits. By default any .Net application developed will target the platform called "Any CPU" as opposed to a specific architecture. This is cool if your not using native DLL's but is a bit of a pain when you do. You will know that you are getting this problem when you start seeing System.BadImageFormatException popping up. It means that your application is trying to cross the Bit boundary - apparently our gracious OS is a separatist?
Any way there seems to be a saving grace, you can do development on a 64 Bit OS and set C# Express to specifically target your application to x86, it's just not obvious. Targeting x86 will mean that your application will still run on a 64 Bit OS but will use WoW (Windows on Windows, which is a compatibility layer to backwards support 32 Bit applications) so you won't get the native use of those 64 Bit Int's but you will be able to use your 32 Bit DLL's.
To setup your application to do this you need to
The latest one is trying to develop using C# Express 2008 on Windows XP 64 Bit Edition and then using interoperability with a 32 Bit DLL - OpenAl. For some reason the compiler doesn't realise that the 32 Bit DLL is just that, 32 Bits. By default any .Net application developed will target the platform called "Any CPU" as opposed to a specific architecture. This is cool if your not using native DLL's but is a bit of a pain when you do. You will know that you are getting this problem when you start seeing System.BadImageFormatException popping up. It means that your application is trying to cross the Bit boundary - apparently our gracious OS is a separatist?
Any way there seems to be a saving grace, you can do development on a 64 Bit OS and set C# Express to specifically target your application to x86, it's just not obvious. Targeting x86 will mean that your application will still run on a 64 Bit OS but will use WoW (Windows on Windows, which is a compatibility layer to backwards support 32 Bit applications) so you won't get the native use of those 64 Bit Int's but you will be able to use your 32 Bit DLL's.
To setup your application to do this you need to
- G in to the menu option Tools>Options and the in the dialog box tick the box in the bottom right corner to "Show all settings"
- Once the settings expand go to "Projects and Settings" expand it and click on "General"
- Check the option which is called "Show advanced build configurations", then close the dialog box
- Now if you right click on the solution explorer, chose properties
- Goto "Configuration Properties", now you should be able to see the platform drop down. This will probably have only "Any CPU" selected; if so click on "Configuration Manager"
- Chose the option "New" under the "Active Solution Platform" drop down box
- Chose the new platform of x86 and copy your settings from "Any CPU"
- Then just make sure that your projects in your solution refer to x86 as the platform rather that "Any CPU"
Subscribe to:
Posts (Atom)