Sound Strikes Back...
2/1/2008
There is so many friends curiously think I'm only interested in Gamedevs, Graphics and Geeks (3G for abbr. ? -_-b).... As my official denial and fight-back (not so much seriously^^), I have prepared a little charming thing (which was implemented from scratch by myself) here for you guys, and I hope that you could find something more than meets the ears... Attentionl Managed DirectSound and .NET Framework 2.0 are required.
Download: Streaming Audio Sample (cancelled...)
2/7/2008
Today I decided to update this fun-project with an improved sample that supports essential streaming MPEG-1/3 (a.k.a. MP3) decoding. Although as far as I know DirectShow does not suit for the requirement of frame-by-frame audio splitting and decoding, which is absolutely needed for an as-neat-as-possible streaming media project, I finally found something even more interesting – FFmpeg, one of the best multimedia projects in F/OSS world. In this following sample, the MPEG-1/3 core was ripped and slightly modified from FFmpeg, and compiled with /clr option by using VS2005. The main difficulty I have met is the terribly slow running performance when debugging a CLR decodec. It’s really hard to drive a .NET based real-time MPEG-1/3 decodec in debugging environment. The reason lies behind this is that there is no optimization at all. But when we run it directly out of the IDE, things become more better by the mercy of JIT optimizations. From a perspective of Geeks that always be in pursuit of 100% perfect, the final effect is not wonderful enough and it may need some further fine-tuning. But for an experimental try-out, it’s fairly good I think:-)
2/10/2008
Yesterday when I decided to dig somewhat deeper into the MPEG-1/3 core to find why the debugging performance is too slow, I was shocked. I found several strange intrinsic functions that used some __asm blocks to try to improve the performance of native code. "Native code optimization in a managed running context", bad smell huh? In fact, that’s the REAL answer of the whole evil question. Some further profiling show that when these “native-optimized” intrinsic functions were called, there were so many context switches occurred between the managed and unmanaged boundary back and forth frequently, leading the debugging performance drop to an unbelievable low extent. After being aware of above situation, I quickly changed the compiling option of /clr (which supports mixing calling model) to /clr:pure (which could be applied to ensure that there will be no native executable codes exist in the assembly anymore), and I also replaced all of these __asm blocks with some equivalent operations by using normal C++/CLI sentences, then rebuilt the whole project. The result was so impressive: the debugging performance in IDE was dramatically improved over 10 times than what I got few days ago! Now there would be no problem to drive a pure .Net MPEG-1/3 core with all IDE debugging functions enabled in real-time!
Download: Streaming MPEG-1/3 Sample (updated, 43.2KB)
There is so many friends curiously think I'm only interested in Gamedevs, Graphics and Geeks (3G for abbr. ? -_-b).... As my official denial and fight-back (not so much seriously^^), I have prepared a little charming thing (which was implemented from scratch by myself) here for you guys, and I hope that you could find something more than meets the ears... Attentionl Managed DirectSound and .NET Framework 2.0 are required.
Download: Streaming Audio Sample (cancelled...)
2/7/2008
Today I decided to update this fun-project with an improved sample that supports essential streaming MPEG-1/3 (a.k.a. MP3) decoding. Although as far as I know DirectShow does not suit for the requirement of frame-by-frame audio splitting and decoding, which is absolutely needed for an as-neat-as-possible streaming media project, I finally found something even more interesting – FFmpeg, one of the best multimedia projects in F/OSS world. In this following sample, the MPEG-1/3 core was ripped and slightly modified from FFmpeg, and compiled with /clr option by using VS2005. The main difficulty I have met is the terribly slow running performance when debugging a CLR decodec. It’s really hard to drive a .NET based real-time MPEG-1/3 decodec in debugging environment. The reason lies behind this is that there is no optimization at all. But when we run it directly out of the IDE, things become more better by the mercy of JIT optimizations. From a perspective of Geeks that always be in pursuit of 100% perfect, the final effect is not wonderful enough and it may need some further fine-tuning. But for an experimental try-out, it’s fairly good I think:-)
2/10/2008
Yesterday when I decided to dig somewhat deeper into the MPEG-1/3 core to find why the debugging performance is too slow, I was shocked. I found several strange intrinsic functions that used some __asm blocks to try to improve the performance of native code. "Native code optimization in a managed running context", bad smell huh? In fact, that’s the REAL answer of the whole evil question. Some further profiling show that when these “native-optimized” intrinsic functions were called, there were so many context switches occurred between the managed and unmanaged boundary back and forth frequently, leading the debugging performance drop to an unbelievable low extent. After being aware of above situation, I quickly changed the compiling option of /clr (which supports mixing calling model) to /clr:pure (which could be applied to ensure that there will be no native executable codes exist in the assembly anymore), and I also replaced all of these __asm blocks with some equivalent operations by using normal C++/CLI sentences, then rebuilt the whole project. The result was so impressive: the debugging performance in IDE was dramatically improved over 10 times than what I got few days ago! Now there would be no problem to drive a pure .Net MPEG-1/3 core with all IDE debugging functions enabled in real-time!
Download: Streaming MPEG-1/3 Sample (updated, 43.2KB)
