html5 client sound forwarding broke

[Antoine Martin]

Originally reported in ticket:845#comment:28.
Affects trunk and 2.0

[Antoine Martin]

Bisection:

• r15000 OK
• r15300 BAD
• r15150 OK
• r15225 BAD
• r15190 BAD
• r15170 OK
• r15180 OK
• r15185 BAD
• r15182 OK
• r15184 BAD
• r15183 BAD
• r15182 OK

So that's caused by r15183 which is "#1424: zero copy whenever possible in the network layer".
It's probably sending the wrong datatype down to the audio decoders.

The problems with "legacy:mp3" could just be caused by the lack of mp3 support on the server:

client 3: audio codec mp3 is not supported by the server

(but I thought we had fallback code for this?)

[Antoine Martin]

With older versions, the "sound-data" packets contain buffers using the [object Array] datatype, whereas the new code uses Uint8Array.
Oh javascript, why you so flaky.
Fixed in r15697 (will need backporting to v2.0).
Still TODO: fix legacy:mp3?

[Antoine Martin]

Found another pair of gems: r15698, r15704 + r15705.

(but I thought we had fallback code for this?)

We do... but it was broken in some cases, fixed in r15701.

Backports for all of the above in: r15706, r15702, r15700.

Minor sound related improvement in r15703.
Then, r15707 improves the buffer handling: we keep the network layer zero-copy buffers until we submit them to the audio decoder. (unlikely to backport this one because it may break something)

[Antoine Martin]

@afarr: mostly a FYI - feel free to close. Sound should now be fixed in 2.0 - and it is also using zero-copy in trunk - the "legacy" decoding issues are now tracked in #1509.

[Antoine Martin]

crickets - closing.