[MPlayer-users] gmplayer audio don't work for controls redhat 8 and 9

[The Wanderer]

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 
about AFAICT.

>>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.

-- 
       The Wanderer

A government exists to serve its citizens, not to control them.