Bug 1713410 - Use a wider integer in resampling segment calculation, to avoid overflow. r=alwu

I caught this locally on Android, c.mDuration was 104517 (which is more than two
seconds at the rate it was), it was overflowing uint32_t because we want to do
this in integers so the multiplication is big.  The alternative is to make the
computation in floating point, rounding up so that there's enough space in the
buffer.

Now I wonder why we have such a big segment sometimes, and only on some OSes, but
we can investigate this later.

Differential Revision: https://phabricator.services.mozilla.com/D138303

dom/media/AudioSegment.h

@@ -336,9 +336,11 @@ class AudioSegment : public MediaSegmentBase<AudioSegment, AudioChunk> {
       bufferPtrs.SetLength(channels);
       uint32_t inFrames = c.mDuration;
       // Round up to allocate; the last frame may not be used.
-      NS_ASSERTION((UINT32_MAX - aInRate + 1) / c.mDuration >= aOutRate,
+      NS_ASSERTION((UINT64_MAX - aInRate + 1) / c.mDuration >= aOutRate,
                    "Dropping samples");
-      uint32_t outSize = (c.mDuration * aOutRate + aInRate - 1) / aInRate;
+      uint32_t outSize =
+          (static_cast<uint64_t>(c.mDuration) * aOutRate + aInRate - 1) /
+          aInRate;
       for (uint32_t i = 0; i < channels; i++) {
         T* out = output[i].AppendElements(outSize);
         uint32_t outFrames = outSize;