xeyrion+l...@gmail.com wrote: > 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? > Even after that there will be clicks in audio every time an underrun happens. So actually this doesn't fix anything. > 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. > Properly designed applications don't cause underruns regardless of what else happens in the system. Playing DVD movies is a piece of cake task in current PCs and there is no need for any kind of real time OS.
Special real time OS might be required only when the application wants to use very short buffers (few samples) and/or when it's consuming more than ~80% of the CPU time itself. > 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... > In this particular case I can blame mplayer designers and only them. They have used design logic that will never work (regardless of the number of channels). They can very well assume that the playback device will maintain proper state regardless of the number of channels. However the application itself must be designed so that it can feed audio data at the rate it's consumed by the device. Maudio waits too long before writing new data which causes underruns. > 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. > There is no reliable way to fix this in OSS. If the fragment size is enforced to be multiple of 6 channels then the problem will move somewhere else. > I do know what to hack now to get this fixed, and that's all I need... :) > The fix is to modify mplayer to simply write whatever data it has to the device without calling SNDCTL_DSP_GETSPACE or anything else. If the fragment size is set to match roughly the video frame rate (or half of it) then everything should work just fine. Nimber of fragments should be set to 2. Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
