On Sat, Dec 20, 2008 at 11:41:20AM +0200, Hannu Savolainen wrote: > 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.
The click is expected and unavoidable. As long as there are no permanent changes, everything is good. > > 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. When playing high definition video, the CPU consumption is close to 80% on 3GHz Core 2. Even then, as I mentioned in the first post, the underruns apparently don't happen very often under normal conditions. Only when there is a burst of system activity there is a likelihood of the underrun, and as long as that's handled properly, playback will be fine (save a click when an underrun does happen). I'm still not convinced that underrun can NEVER happen (or rather is an error condition), regardless of the design of the application. What if the process gets suspended or something? The way it is now, the underrun is basically a fatal error requiring the reset of the device. Reminds me of the days when CD burners couldn't handle underrun properly... :) > > 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. I see. I guess their poor design unnecessarily puts higher demand on the system, thus making underruns far more likely. The interrupt skew also explains why the problem didn't go away when mplayer was given real-time priority (under Solaris). This is definitely mplayer's fault. However, it seems to me that we have two distinct problems here: underruns happening under normal conditions (mplayer's fault), and underruns not being handled gracefully (OSS's fault). Of course, if the first problem was fixed, the second would be irrelevant, so I see your argument here. However, I still don't believe that the underrun should cause a playback failure, however unlikely it might be. > > 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 see. You obviously know OSS design much better, so I won't argue here. > > 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. I think that's easier said than done. As it is, mplayer syncs everything to audio using that ioctl call. Even though that might be a bad idea, the correction would require major changes. I'm looking for something more expedient here... :) They do seem to have some hardcoded thresholds on the delays to prevent the underruns though, so tuning these might work. Anyway, I'm gonna quit bothering you. You've been more than helpful already, and I appreciate that. Thanks again. _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
