MSC3052: Sample events

[erkinalp]

This is a rudimentary way of streaming sample streams using Matrix.

[Sorunome]

are the samples encoded in some way? base64?

[erkinalp]

Base64 is just one of the allowed encodings. Base85 or JSON-escaped are also possible.

[uhoreg]

I think that this proposal is not very useful without also specifying something concrete (including the encoding) that would use it, whether as part of this MSC or as a companion MSC (or MSCs). And while I'm happy to that you're trying to make this mechanism generic, I don't think it will ever make it into the spec without also having a specific thing that uses it.

[Half-Shot]

Presumably you could use relations to chain together samples

[Half-Shot]

For someone ill informed:

• What's the expected duration of an average base64 encoded samples? (is it practical?)
• Is it realistic to expect a browser application to load and buffer a base64 audio sample seamlessly or will there be stutter in practise?

[erkinalp]

• 125-150 milliseconds to 10-20 minutes, depending on the average communication latency between the sampler and intended receivers in the room.
• That needs to be tested in practice.

[ara4n]

I may be missing something obvious here but: what is the use case? Why would you want to do this, rather than (say) streamed file transfer via the media repository, as per #2354?

Trying to tunnel RTP over Matrix events - or indeed any kind of binary data over Matrix, feels like a bad smell: we have a media repository for that.

[erkinalp]

The designed-for use case is high (but controlled) latency voice calls and IoT with full replayability, down to sample level.

[erkinalp]

Marked as draft as there are unresolved concerns before having this implementable.

[uhoreg]

It seems to me an obvious alternative is to store the samples in the media repo rather than base64-encoding them.

[erkinalp]

Media repository does not allow for conference moderation semantics where you can change the permission to talk midway.

[uhoreg]

What I mean is: instead of having the samples field be an encoding of the samples, it would instead be an mxc:// URL pointing to the samples in the media repo, while still using the m.samples event type.

I'm not saying that I think it should be done that way. But I think that it's an obvious alternative that I would expect to see listed in the "Alternatives" section.

[erkinalp]

What I mean is: instead of having the samples field be an encoding of the samples, it would instead be an mxc:// URL pointing to the samples in the media repo, while still using the m.samples event type.

I understood that, but it is not an alternative, due to stark difference in timing, persistence and moderation semantics of media repository and room events. Those two cover entirely different use cases.