Hannu Savolainen wrote: > Garrett D'Amore kirjoitti: >> Vladimir Novoseltsev wrote: >>> Hi, >>> I've problem with smooth sound playback if system is under load. >>> In average load insignificant, but could peak to 100%. Applications >>> causing load are java based (IntelliJ Idea, and GWT project building >>> running in terminal), both get IA schedule class from X (as all >>> application running under X do). >>> This seems to have influence not only on sound playback, but on >>> other highly interactive tasks as well, like mouse pointer tracking >>> (under load it becomes sloppy). >>> The system is OpenSolaris snv_117, running on C2D 6550 at 2.8Ghz, 6Gb >>> ram and GTX260 video, sound driver is audiohd. >>> >>> cat /dev/sndstat >>> SunOS Audio Framework >>> >>> Audio Devices: >>> 0: audiohd#0 Intel HD Audio, ICH9 (DUPLEX) >>> >>> Mixers: >>> 0: audiohd#0 Intel HD Audio, ICH9 >>> Realtek HD codec: ALC885 >>> >>> >>> Is there any way to tune system to avoid such problem? >>> >>> PS. Sorry for messy description, english is not my native language. >> >> If you're doing development, and you're saturating your CPU, there >> isn't a lot that can be done. The best thing you can do is either try >> to locate more CPU, or reduce the priority of the processes that are >> consuming so much CPU. The best tool to use to do this is "priocntl". >> >> Note that the problem with smooth audio is probably not a constraint >> of the audio framework, but of the audio applications. If they can't >> get enough CPU to keep the audio pipeline from underruning, then >> you're going to have pauses/drops/skips. > This is my best knowledge too. Audio drivers require just few > milliseconds for their operation so the dropout problems are almost > certainly caused by them. If the average CPU load gets above 80% it's > likely that the system is CPU bound. In general there is enough CPU > power available for all the concurrently running applications. However > the audio device buffers need to be kept filled all the time. During a > CPU bound situation it may happen that this fails when the load peaks > to 100% momentarily. > > Another reason to dropout problems is that many applications try to > avoid blocking by using usleep() to wait until enough buffer space is > available. However usleep() usually waits longer than requested (by > definition). It is almost certain that in this way the application > will wake up too late if the system is under moderate load. > > Assuming that system HZ is 100 under Solaris any usleep() will wait at > least 10 ms (up to 20 ms + delays caused by other load). In addition > the application may need few milliseconds to do its processing. Audio > buffer interrupts in turn occur 175 times/second (by default) which > means every 5.7 ms. Depending on the buffering logic used by the > application the sleep time may be too long.
Well designed applications won't have this problem under Boomer. Boomer can allow applications to queue up a *lot* of audio data, without underruns. Of course, if you want to have low latencies (e.g. for synchronization with on-screen video, or sounds in response to game events) or conference calling, then the situation is harder. But a typical audio playback application can queue up to 64k at a time for most Boomer drivers. At 48,000 kHz with 16-bit stereo, that corresponds to about 340 milliseconds of buffering. So the application has plenty of time to switch back and perform some audio processing. -- Garrett > > Best regards, > > Hannu > _______________________________________________ > opensound-discuss mailing list > opensound-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/opensound-discuss
