I'm not a DirectX developer, but it looks to me like I've got huge swaths of DirectSound directly available from C#. I can check something specific, if you'd like.
I'm developing an app for surveillance that talks to multiple IP cameras and microphones. We made the unfortunate choice of C# early on.
- no normal RTSP support. Ok, I used libav (working hard to wrap it, cause it's a well written C library, but not trivial to use from C#)
- I get h264 frames that I need to look at before decoding. No way to give compressed h264 frames to WPF to decode. (So I use libav again). SilverLight actually does have MediaStreamSource -- but this is not a SilverLight app.
- Ok, so let's try to use the hardware decoder when it's there. libav supports it, yay! What about WPF? Well, no. You have to use Direct3D (?) to get a surface to draw on. With no way to do this from C# (Interop fails badly according to a DirectShow+Direct3D MVP I consulted). I give up, and use libav's software decoder.
- Ok, I have a bitmap, I want to blit it quickly to the screen - WTF? The only way to do it is use a Shared Memory section (interop again) to create a bitmapsource; then update the underlying memory.
- Except memory runs out after about 20 seconds (~400 frames) of .Invalidate() calls. WTF? Turns out it's a known bug introduced in v4 (wasn't there in v3.5). No fix yet. Just call GC.Collect() after every invalidate. Yay for "automatic" garbage collection!
- Ok, so now we have got a reasonable video. What about sound? Everyone with experience I know says "use NSound" (which is interop again). I opt for interopping with winmm, which I have experience from the C++ side.
- Now, to wrap it all together, I need a millisecond-precision timer. Sorry, no go in .net; Winmm's "timeBeginPeriod" to the rescue! but .net's Dispatcher still triggers my code every 15ms. WTF? I would be happier with a 100us timer, which windows doesn't even provide, but I can't get less than 15000us!
I'm so sorry we chose .NET; it seems to cater well to CRUD type applications, but it is so inadequate for everything I tried to do with it, that it's not even funny.
Probably not. I need frame-by-frame timing control. These APIs don't seem to deliver anything previous APIs didn't - just make it a little easier to use.
I looked at it, but it didn't appear that libvlc gave me the level of control I needed (frame accurate seeking and reporting, access to framebuffers, stuff that low-level). Perhaps I didn't look closely enough...
Just to clarify: my "it appears to be there" was in reference to the WinRT-powered DX11.1 in Windows 8. Your experience sounds exactly like why I wouldn't be doing anything vaguely low-level in C# in Windows 7 or earlier.
And you're comment is exactly why I wouldn't do it in Windows 8 either.
There hasn't been a single time when the answer to some deficiency was not "Well, this version of Windows/.NET is cr*p, but the next one is going to be perfect for every need".
I didn't choose to go with C# for this project - someone else did. Being the low-level guru, I was called in to fix all the deficiencies.
Really, .NET has been out for 10 years now, WPF for 5. There is no excuse for this abysmal level of support, and until I see Win8 actually working properly with sample code that addresses stuff such as I mentioned above, I won't consider it.
Sorry. That sounds like something meant for C++. Most of this sounds like pretty key stuff like the timer. Didn't anyone do a basic proof of concept first to flush this stuff out? Just curious.
Yes, they did a proof of concept using the MediaElement, with windows driven playing -- that actually works. And they assumed that fine timing control, different codecs, frame accuracy etc would be available if needed.
I agree it's meant for C++ on Windows (if it is meant for Windows at all - the 15ms timer precision thing runs so deep it bites in many places you wouldn't expect).
But Microsoft and MS fanboys keep touting that "C# is all you need to get things done" - that has never been the case, and I expect it not to be the case with WinRT either.
