Hello everyone! A follow-up to the problem I have: Reimar D?ffinger replied with a concise answer to the problem on the mplayer-users mailing list: http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-May/079933.html ... which is fun to read. Thanks Reimar :) Any further expert opinions on this matter? I wouldn't like to go through hoops of compilation fun to get a working OpenAL / MPlayer. If I am not mistaken, this bug is known at Ubuntu. Best regards, Mihai Le Sun, 09 May 2010 14:23:14 +0300, Colin Guthrie <gmane at colin.guthr.ie> a ?crit: > Hi, > > Just for clarity to others reading, we discussed and tried to debug this > issue a lot on IRC already, so I'm familiar with the problem. > > 'Twas brillig, and Mihai Sucan at 09/05/10 12:06 did gyre and gimble: >> 4. somehow i think that mplayer -ao pulse does "pretty much the same" as >> it does mplayer -ao oss from the rvm Ubuntu PPA. The latter did take >> control of the sound card, via OSS. The former does somehow take control >> of the sound card, pulseaudio looses it, then mplayer happily goes on to >> use pulseaudio for subsequent audio stream output, but now ... >> pulseaudio >> is silenced. > > Well mplayer -ao oss will bypass pulse completely and, as you say, > basically "hog" the sound h/w. You can theoretically use: > padsp mplayer -ao oss > > and that should redirect oss output via PA too, but this may or may not > work overly reliably (aka YMMV). > > The interesting thing about the report is that when PA stops outputting > audible sound, the vumeters are properly moving up and down which means > that the sinks are not suspended, nor are the sinks unloaded and > replaced with a "Dummy Output" (null-sink) because they've been > unloaded. In other words everything seems setup to work correctly but > the reasons are eluding us! > > One thing you don't mention above, but is included in your debug output > is the fact that the alsa mixer output is not any different before vs. > after the problem. My initial hypothesis was that mplayer was somehow > flipping the digital output switch in alsa, thus causing it to seem like > it had simply stopped working. However analysis of the amixer output > seems to kill this idea. > > > So if anyone else has any bright ideas, please speak up! > > Col > -- Mihai Sucan http://www.robodesign.ro