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.
OpenAl.Net requires the Tao.OpenAl framework; the Tao.OpenAl framework does the leg work interop'ing with the OpenAl DLL's.
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.
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.
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.
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"
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 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"