refactor(sdk): Allow to send waveform for any audio message#5732
refactor(sdk): Allow to send waveform for any audio message#5732poljar merged 3 commits intomatrix-org:mainfrom
Conversation
CodSpeed Performance ReportMerging #5732 will not alter performanceComparing Summary
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5732 +/- ##
==========================================
- Coverage 88.43% 88.42% -0.01%
==========================================
Files 360 360
Lines 99796 99794 -2
Branches 99796 99794 -2
==========================================
- Hits 88250 88245 -5
- Misses 7405 7409 +4
+ Partials 4141 4140 -1 ☔ View full report in Codecov by Sentry. |
Hywan
left a comment
There was a problem hiding this comment.
The changes look good to me. I'm a bit annoyed by the regression with the waveform format, but since it's a different type and it's documented in the CHANGELOG, I think it's fine.
|
Re-running the benchmarks. I suspect the result is misleading and could be due to noise. @zecakeh can you fix the conflicts please? |
bnjbvr
left a comment
There was a problem hiding this comment.
Thanks, we're on board with this change, and as you said it'll make the switch to the new MSC simpler. We might delay the landing of this PR, since we want to limit landing breaking changes at the FFI layer until the Matrix conference.
One comment I would have is: why to use f32 and not f64? We'd have a much better precision when it comes to the [0; 1] range, leading to a better precision in the normalized range; and I don't think we're getting any notable speedup for using 32 bits instead of 64 bits here.
Would it make sense to change to a f64 in this patch?
|
I don't mind changing to f64 but I chose f32 because it is precise enough to be converted to an integer value between 0 and 1024 and it should be enough to draw it too so I don't see what we gain by increasing the precision? |
|
I wary of using float32s, because they can't represent finely small values, viz. values in the [0; 1] range. That is, many small float32 values would be normalized to the same int in the [0; 1024] range, so if you looked at a flat projection of the f32 range to the int10 range, you might see holes in the int range. Since float64 have so much more precision, it's unlikely that this problem would happen with those. |
|
I am not convinced that this is true, because f32 has a precision of 6 significant digits, and for integer values between 0 and 1024 we only need 4. |
bnjbvr
left a comment
There was a problem hiding this comment.
I've double-checked that with a program, and agree with your conclusion; good point.
Approving, but we've been requested to not merge this immediately.
|
No problem, I'll rebase this after the Matrix conference then to solve the conflicts. |
The EX releases for the conf have been done, you can now rebase so we can merge. |
By moving the waveform declaration into `BaseAudioInfo`. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
ab7b887 to
49ca2f0
Compare
Done |
|
Oh I forgot to fix the typo. |
Most clients will probably work with values between 0 and 1 and need to convert it just to send it, so we can move that conversion into the SDK. This is also more forwards-compatible, because MSC3246 now has a different max value for the amplitude, so when this becomes stable, the only change needed will be in the SDK. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
49ca2f0 to
36f147a
Compare
|
Done. |
We plan to use this in Fractal to always be able to present a waveform for an audio message.
The second commit might be more controversial: it changes the format of the waveform from a list of
u16between 0 and 1024 to a list off32between 0 and 1. This is done because the value between 0 and 1024 used in the event is quite arbitrary (and they have changed in MSC3246 since then), most clients should end up with values between 0 and 1, and need to convert it for sending it. So this centralizes this conversion in the SDK.