When researched previously there was no consensus on the appropriate way to do this; multiple high end audio players used different (positive only, negative only, or mixed) strategies.

I'm happy to reconsider the code if you can provide some references.

My audio processing expert friends say this: "dividing by 32768.0 is better because it is simpler and avoids an needless additional nonlinearity."

And also this:

Also make sure that for the other direction you use multiply by 32768.0 and use something like MathUtil::SafeRound to avoid an overflow ;)

(Which might be an issue for Chrome because other people have written code to invert the non-linear version you currently have implemented.)

This issue seems to be out of TE-scope. Hence, adding label TE-NeedsTriageHelp for further investigation.

Thanks...!!

No TE help necessary; will take this and follow up with it when I can.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think Max is working on this?

Not to my knowledge. But we have exactly the same issue in the WebRTC library (https://bugs.chromium.org/p/webrtc/issues/detail?id=6594) so it isn't unfeasible that our DSP folks address both problems.

I'd advocate simply multiplying with 32767.0 float->int and dividing with 32768.0 for int->float, since it is less compute intensive and doesn't introduce non-linearity (which the saturation would). There'd be a tiny reduction in level when going back+forth but this *should* happen only in a few places throughout the signal path so will be unnoticeable.

Leaving assigned to Max, in case he's already done some work.

I strongly suggest using the same constant in both direction, at least until you measure the speedup and it is consistent and relevant.

Why make this more complex than it is?  Why make it again asymmetric in some way?

I strongly suggest using the same constant in both direction, at least until you measure the speedup and it is consistent and relevant.

Why make this more complex than multiple and divide by 32768?  Why make it asymmetric in some way?

The reason is to avoid non-linearities.

At some point I was going to do this as part of https://chromium-review.googlesource.com/c/chromium/src/+/1225701, but that one keeps being delayed due to higher priority stuff coming up. I completely agree with multiplying with 32767.0 and dividing by 32768.0 to avoid distortion though.

Yes, after some more thought about it, it makes sense to have the scaling
be asymmetric.  In my previous use cases, I always knew that that the
floating point samples had been generated by dividing by 32768, so there
was never a positive 1.0, but if the float samples might span the entire
range of [-1.0,1.0], then multiplying by 32767 makes sense.

Il giorno gio 6 dic 2018 alle ore 00:33 maxmorin via monorail <
monorail+v2.3787522839@chromium.org> ha scritto: