Hi, Thanks, this explains everything. The problem does happen with 6 channel sound. I suppose the quick fix would be to have mplayer insert 2 blank channels to get the 8 channel stream?
You are right about how mplayer works, but I'm not convinced that that's the entire problem. Even if mplayer used the select/poll, there is no guarantee that it would actually get to run in time to fill up the buffer. This would likely be just as bad, or even worse, than the asynchronicity of the interrupts, depending on the frequency of those interrupts and the system load. In either case, since we don't have the luxury of the real-time OS, buffer underruns are inevitable, regardless of the playback method. But it doesn't seem correct to have the state of the stream permanently altered just because there was an underrun - it should be just a temporary glitch. I guess what mplayer developers assumed was that the playback device will be in the same state that they left it in, which is not the case here. You can't really blame them for that though... Now, I'm not criticising anything here, and definitely not telling you to quickly go and fix it... :) I'm not sure that the workaround would be that nasty though - if the card doesn't support the fragment size that's multiple of the current number of channels, just store how many samples were written, insert blanks as you see fit, and then pad the next write appropriately... But this is not my code, so it's not for me to decide. I do know what to hack now to get this fixed, and that's all I need... :) Thanks again. _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
