[PATCH] Adjusting softvol / volume filter during playback causes static on big-endian audio on little-endian archs

[compn]

-af volume=5 works
but using -softvol and 0/9 keys causes static

[rotmer@…]

Adding patch for seems like this bug i'm having issues here too with. For me here it is triggered with s16be audio. Here is the related output:

AUDIO: 48000 Hz, 2 ch, s16be, 1536.0 kbit/100.00% (ratio: 192000->192000)
AO: [alsa] 48000Hz 2ch s16be (2 bytes per sample)

I don't like quite that much how exactly that patch works, so resulting chain looks like this then: input s16be -> format filter s16le -> softvol s16le -> format s16be -> output s16be, so there are 2 format filters for just softvol to work okay, but it works here nevertheless.

Maybe better way would be to somehow switch output to s16le on the fly as it is done automatically when you run mplayer -af volume file.vob, in this case related output is:

AUDIO: 48000 Hz, 2 ch, s16be, 1536.0 kbit/100.00% (ratio: 192000->192000)
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)

And soltvol works fine as it is now without patches.

[rotmer@…]

Initial patch for this bug.

[rotmer@…]

Ah, just noticed sample avi file from Reynaldo ​http://samples.mplayerhq.hu/avi/toonumentary-skieth.avi. It works here okay on svn without patches, so changing Summary a bit to actual sample file to date ​http://narod.ru/disk/17990301000/softvol-static-bug-1561.vob.html.

[reimar]

Avoiding double format filters would either mean converting to le from the start (giving worse performance if volume control is never actually used) or reinitializing the output (giving audio dropout when changing volume the first time), neither is really any better.
Fixed in SVN r30659, however without calling af_reinit recursively, recursion really should be reserved for cases where it means a vast simplification, otherwise the risk of endless recursion is a too high maintenance burden.