xeyrion+l...@gmail.com wrote: > > 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). > Then there may be problems. > 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... :) > > Audio is different than CD burning. The CD writer can be stopped/restarted and the writing process just slows down a bit. The recovery may also mean starting a new session or something like that. However it can be recovered.
Audio devices consume samples at fixed rate (say 48000/sec). If the application doesn't give samples fast enough then there will always be audible click (at least). When an underrun occurs it's all too late. There is no way to recover. >>> 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. > They actually don't put any higher demand to the system. The only problem is that they wait too long before calling write. The alternative is that the application waits inside (audio) write where it can be woken up exatly at the right moment. > 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). There is no way to handle underruns gracefully. There is no data that could be fed to the device while the application is out of business. There might be a way to prevent channel swapping during underruns in 5.1 mode. However this is likely to just move the problem to some other place. > >>> 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. > > The easiest and most reliable way to sync with audio is to use normal blocking write(). Now mplayer triest desperately to block before calling write so that the write doesn't block. That doesn't make any sense. I would be very surprised if removing the SNDCTL_DSP_GETOSPACE call and the select() call after it doesn't fix the problem. Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
