Hi, Does this happen with 5.1 (6 channel) playback?
The 6 channel format is problematic because it's not a power of 2. Every time there is a playback underrun OSS will insert an empty fragment of audio to the device. This disturbs the channel assignment because the inserted fragment size is not multiple of 6 channels. The workaround would be using fragment sizes that are not power of 2. However there are many sound cards that are fixed to given fragment/buffer size and the workaround is not possible with them. The real reason to the problem is that mplayer causes frequent underruns. I don't remember exactly what problem was but I recall mplayer doesn't use normal blocking writes or select/poll to syncronize with audio. Instead it calls SNDCTL_DSP_GETOSPACE to guess how long it should wait and then it waits by calling usleep() (or was it select() with a timeout). This is doomed to fail because the sound card works asynchronously with system timer interrupts that controls usleep(). This should be fixed instead of adding nasty workarounds to OSS. Best regards, Hannu --------- xeyrion+l...@gmail.com wrote: > Hi, > > I'm reposting this problem here as per suggestion on the OSS forums. > > So here we go. I have this problem - the channel order gets messed up > during the playback. Everything starts up just fine, but then at some > time during the playback the channel order changes (i.e., center goes > to subwoofer or front left, it looks like other channels shift > accordingly). The seek or pause (which causes the player to close and > reopen the dsp device) will always set the channel order back to > normal. > > The problem is far more frequent when the system is under heavy load. > When the system is otherwise idle, the problem happens quite rarely > (once or twice during a 2 hour movie, sometimes not at all). However, > when the system is loaded (either CPU or disk IO), the problem happens > every few minutes, even though the playback is otherwise smooth. It > seems that something is expecting a real-time response. > > I only use mplayer and OSS for playback, so it's gotta be either one > of these causing problems. First I assumed it's mplayer, and, to > verify that, tried a program similar to osstest, except with different > sound on each channel. The playback was fine, regardless of the system > load. So I posted a similar message to the mplayer's mailing list > (http://article.gmane.org/gmane.comp.video.mplayer.user/58887), and > have yet to receive any response... > > However, in the meantime, since my linux kernel was due for upgrade > anyway, I decided to try ALSA drivers and see what happens. And guess > what, the problem goes away. I used ALSA with OSS emulation, and > mplayer with exactly the same setup (i.e., output through OSS). So now > I'm not so sure anymore that the problem is with mplayer. It seems > instead that this is either an outright OSS bug, or, more likely, the > change in the OSS API semantics. > > The difference between OSS and ALSA is best seen when the system is > heavily loaded. When using OSS, the channel order is pretty much > random and the audio is choppy. But when using ALSA, the sound stays > smooth all the way until the player starts dropping samples due to the > sync problems (which requires a much higher system load), and the > channel order never changes. > > System info: I tried OSS b1011, b1012, b1016, and b1050, VMIX disabled > whenever possible. The machine is AMD64 quad-core, audio chip is > CMI8788, I tried Debian and Solaris OS. Problem is always present to a > varying degree. It is almost negligible on Linux when the machine is > idle and VMIX is disabled. > > I would appreciate any suggestions on how to resolve this problem. > > Thanks in advance. > > _______________________________________________ > oss-devel mailing list > oss-devel@mailman.opensound.com > http://mailman.opensound.com/mailman/listinfo/oss-devel > _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
