audio: Add G.711 decoder

[onkrot]

https://en.wikipedia.org/wiki/G.711

Both a-law and mu-law implemented as lookup tables

[Croworbit]

is there content that this is used for?

[Dinnerbone]

(or at least a crafted example so we can test with, please!) Thank you!

[Lord-McSweeney]

I don't think it should be added to the AudioCompression struct in SWF, since it should (?) only appear in FLVs- is there another way to add it?

[lvyitian]

I don't think it should be added to the AudioCompression struct in SWF, since it should (?) only appear in FLVs- is there another way to add it?

@Lord-McSweeney Same in https://github.com/ruffle-rs/ruffle/pull/16526/commits/409a713034057af662c4e694cb842833055c94cf#diff-00d1b36fa29c1b47759997928f850c8ff051e7bcbe201ab073f0f855f1d3ecdeR1029 This has actually already been discussed in https://discord.com/channels/610531541889581066/614855396468719619/1244921689221894174

[torokati44]

At least I personally have changed my mind since then. Now I think it's fine. After all, we have also added H264 as VideoCodec...

[onkrot]

Okay, this definitely needed more testing (see #16614)

[onkrot]

FFmpeg commands for flv encoding A-law: ffmpeg -i output.wav -acodec pcm_alaw -ar 8000 -ac 1 a.flv Mu-law: ffmpeg -i output.wav -acodec pcm_mulaw -ar 8000 -ac 1 m.flv

[torokati44]

I'm still unable to make a passing test for this.

This is what FP plays the tone as:

And this is what this PR currently plays it as:

Maybe the FLV parser doesn't feed the decoder enough data...?

Could the same thing be causing the fairly common "MP3 decoder buffer underrun" errors?

I've also noticed that a decoder is being recreated for each "packet", which is probably not optimal...?

Pinging @kmeisthax.

[torokati44]

During some quick and dirty debugging, I noticed that the part that does the lookup table lookuping, is invoked by two different threads... Which is sus. Either it should be the main thread, or the one that handles the callback from the audio device... no? :thinking:

And BTW the length of non-silent parts compared to how far apart they are (see the second screenshot above), hints at the possibility that maybe we are reading 16-bit stereo samples at 44.1kHz from a data source that is 8-bit mono at 8kHz...?

As in the ratio of 2x2x44100 = 176400, vs. 1x1x8000 = 8000 (22.05) is suspiciously close to the 559 vs. 23 pixels (ratio of 24.3, close enough given the accuracy of measurement). But it might also be just a coincidence of course.