[MPlayer-users] gmplayer audio don't work for controls redhat 8 and 9
inverseparadox at comcast.net
Tue Jul 8 01:55:54 CEST 2003
Attila Kinali wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Sun, 06 Jul 2003 17:52:50 -0400
> The Wanderer <inverseparadox at comcast.net> wrote:
>>>Please check whether changing "pcm" has an effect with your card
>>>(mplayer uses pcm to change the volume).
>>>If it doesnt work for you, please send a full bugreport.
>>Just tested to be sure. Using ESD output, the volume control appears
>>with "/" and "*", and the volume changes, but the GKrellM PCM volume
>>slider does not move. Using OSS output, the volume control appears, the
>>volume does not change, but the GKrellM PCM volume slider moves in sync
>>with the mplayer volume control.
> Sounds strange, sounds really strange.
> I think we need a switch to use master if pcm isnt working
> (or is there already one ?)
Don't know, but nothing comes up on a somewhat cursory scan of the man
page, and nothing in sound.html seems unquestionably relevant; there are
a few things about volume filters, which might help as a workaround but
reportedly decrease audio quality and regardless aren't what you asked
>>Once again I find myself puzzled as to what should be included in a
>>proper bug report. In this case, the only parts of bugreports.html which
>>seem unquestionably appropriate are B.4.1 and B.4.2; aside from
>>replacing the gdb report with a log from a simple "mplayer -v" as
>>requested in B.4.5, what information would be needed beyond that which I
>>presented in my earlier crash-related report?
> Hmm.. here we need the exact type of the soundcard, the kernel version,
> the used driver (and it's version).
About what I'd guessed.
Kernel version is part of the general information requested in every
case, but the other two may be a bit more of a problem. As I said, my
sound card is actually a chip integrated into the motherboard; I can
give the manifacturer and model name/number, but I've got no idea what
driver is being used, and the only way I know of to even try to find out
more than is available through lspci -v involves restarting the system
and reading the startup messages, which is scarcely an ideal solution.
^_^ dmesg is of no use in this case, since the buffer it reads has been
getting flooded with network error messages from both known and unknown
causes, and the actual startup messges are long since gone.
> Bugreport writing is just a collecting of information that might be
> usefull for a developer. If it's something that distinguishes your
> enviroment from an other which doesnt show the problem or is a part
> of hardware / software that is related to the problem then it should
> be definitly be included in a bugreport
About what I figured... the trouble is A) that I'm not always as good as
I'd like to be at knowing what is/isn't related and B) that providing
just what I can determine to be related is frequently less than what's
requested by the documentation, and I don't like to go under spec
without knowing exactly what I'm doing. ^_^
I'll go nag my brothers again about testing to see if the problem occurs
in the same way on any of their systems... don't know how successful
I'll be, however.
A government exists to serve its citizens, not to control them.
More information about the MPlayer-users