hta: is there a way or being planned to have a way to disable the jitter buffer from the Web APIs?

(adding hta)

Actually, it should be straight forward to tune the GIPS engine accordingly.

if the music-mode is switched on:
a) playout stretching and shrinking shall not be used 
b) the playout buffer shall be a bit larger to ensure a constant playout.

Already now, you have a couple of options in WebRTC which control the audio engine...

hlundin@ et al: Is this possible today or would it require WebRTC library changes?

I think the "echoCancellation = false" constraint will actually do the Right Thing on the sender side. This is an obscure way of doing it, and should probably be changed.

On the receiver side, I don't think we have a Javascript API surface for this.

We cannot do this today. The problem is, as correctly identified in the original post, that delay adaptation in the jitter buffer kills the music timing. We could avoid some of that adaptation by aiming for a higher buffer level, but that is only half of the problem. The jitter buffer also takes care of clock drift between sender and receiver, and that is also handled by time-stretching. Hence, no silver bullet.

This seems more like a feature request - to tlegrand@ to have a look and prioritize.

Clock drift should not be a problem.
Assuming 50ppm tolerance, clock drift adds 3ms per minute.

if you have an pause every 10 minutes, then you can still adjust to keep m2e-delay low.

This is essentially a duplicate of feature request https://bugs.chromium.org/p/webrtc/issues/detail?id=677.

This feature goes beyond the basic design of WebRTC.