Not sure if you remember, but I did blog in the past about the ALSA ac3 plugin, that encodes the audio on the fly to play it through an external amplifier and a digital S/PDIF connection.
Well, beside the fact that the plugin was being shipped without proper testing, as it didn’t work at all (missing call to avcodec_init(), nonetheless), I now came to the conclusion that it was poorly designed too.
Think about it: what is that produces 5.1 output most of the time? Multimedia players, like xine, MPlayer and VLC, most of which also use FFmpeg for decoding in someway (at least xine and VLC do, MPlayer uses its own snapshot so it’s a different problem). So what the problem is? Well..
[NULL @ 0x304810cd10]insufficient thread locking around avcodec_open/close()
this is the error you get when you try to play something through xine using the AC3 encoding plugin of ALSA. The reason is simple: FFmpeg API is not thread-safe at all, especially when it comes to open and close, so xine has to take care of handling a mutex to lock access.. but it’s not possible to synchronise with ALSA’s access, so there’s no way to use a FFmpeg-based software together with that plugin while using a shared copy of FFmpeg. Of course upstream will just say that they don’t support shared FFmpeg, that they don’t give a crap and that it’s the design of the rest of the world that has to be changed, but the bottom line remains the same: ALSA’s ac3 plugin is pretty much useless.
An user commented on an ALSA bug with a patch that makes the plugin use another AC3 encoder, aften that is supposedly faster, I’ll have to try it, it might be worth using that just to workaround FFmpeg braindeadness, even if the current CVS version uses CMake (sigh).