[MPlayer-users] Slave mode - switch_audio does nothing or causes crash

[Alexander Roalter]

Phil Rhodes wrote:
>> Other then a backtrace, does the '#'-switch in normal mode work?
>> If not, do you use any audio filter (-af xxxx) at all?
> 
> What d'you mean by the # switch? In normal mode, when I'm running the 
> extracted VOB, I can specify any -sid and I get the English subtitles (maybe 
> mplayer has extracted only the English when I did the -dumpstream?)
what -sid and subtitles? it has nothing to do with it.

When playing from the command line (i.e. no slave mode), i can switch 
languages using the '#' key. I assume that internally the same function 
is bound to the 'change-audio-track' command via the slave interface.

That point made, mplayer exits on my machine when I change audio 
language (mark: not subtitle language, they are switched with he 
'j'-key) b/c the channel number is again set at zero (which is not true).

I made a hot fix and at the place mplayer exits I overrode this with a 
fixed channel number of 6 (which is true for my system), but otherwise 
is total BS. I did not venture out to search the correct number of 
channels currently in use (either specified via -channels n or -af 
channels=n, but neither did the programmers of this code part, so I'm 
not bothering anymore.

> 
> I am using some audio filters - good point, I'd overlooked it. Depending on 
> the user's settings in my application, mplayer may be launched into slave 
> mode with audio filters pan, volume (softvol), and soft clipping enabled.

The use of a single audio filter on my system triggers this behaviour, 
so I'm more or less sure (though I wouldn't bet any part of my body on 
it) that mplayer with the same parameters, but not in slave mode, would 
exit at the same place and complain about channel number wrong etc.

> If I hardcode the -aid 128 or 128 into my commanline, I get the anticiapted 
> result, but then I can't switch audio tracks at runtime - which I need.

> For completeness, I'm also using -vo gl:yuv=2:slice-height=0 because of 
> various interactions the directX output driver has with brightness, contrast 
> and saturation filters I'm using.

Shouldn't matter.

-- 
cheers,
Alex