Audio Pulsing/Dropout for larger files (andOr bad network connection?)

[KlienVo]

The following three Sadiss tracks: Plantery Skins Anfang Planetary Skins Anfang Stretched (2x) Planetary Skins Anfang stretched

based on the following partials/frames files (attached as .zip): 03_UmfassenUmfangen_Stereo_beginning_frames.txt 03_UmfassenUmfangen_Stereo_beginning_Stretched2_frames.txt 03_UmfassenUmfangen_Stereo_beginningStretched_frames.txt frames-files.zip

The 3 tracks have got the same number of partials. (hence the load of concurrent oscillators run by each client should stay the same for each track) The tracks only differ in duration (i.e. have been stretched in Spear) and file size.

The two stretched tracks display the audio 1s pulsing error in varying dimensions. Seems like the 1s buffer download rhythm becomes audible due to some error. (either timing or bandwidth [or whatever] related)

[matbind]

Testing locally with app running on same machine as http and ws servers: No pulsing audible for any of the tracks. Testing with live server and a mobile phone the problem is easily reproduced. With the 2x stretched track it sounds like the partial data stops 'too early'. Hard to tell what really is going on. Current hypothesis is that there is an issue with the end time. No idea though why this happens on a real device but not when running the app on the same machine as the servers. Testing with live server and app running on my machine in the browser, the problem appears as well. This means:

• The problem is not because of mobile device performance.
• It might be because of how the chunks are created.

Printing chunkEndTime - ctx.currentTime when setting the breakpoints (which happens each time data is received from the server), the resulting value is ~1.5s for the non-stretched file, and around ~.5s for the 2x stretched file. A value lower than one means it stops before the next set of data is received and processed, if I am not mistaken. This would explain the pulsing sound.

Adding 5 seconds to the start time (in addition to the 2 seconds that already are added) solves the problem. Somehow the 2 seconds are enough for the non-stretched file, but break the 2x stretched one. The reason for this is currently not clear as the partial count per chunk is the same for both files, and the amount of transferred data seems to be similar as well.

Cause The issue is the time it takes to read the chunk file. On the server the normal file takes about .5s to load and parse, while the stretched file takes ~1.5s. Since the start time is set before the reading of the file (due to the limitation that we don't have global time on the server) the loading time gets 'subtracted' from the start and end times, leading to the end time to fall below 1s, breaking the track. I am not in the mood to describe it more coherently, but it makes sense.

Solution There are multiple ways to solve this. The most sensible one (since it makes most sense in the long run, I believe) is to make the performer preload the track. Maybe something like having to click the start button twice, once for loading, once for starting. This makes the current implementation of autoplay useless though. I'll think of something soon.

[KlienVo]

Many thanks. In Athens we had the situation that some of the phones had audio signals, others didn't. Am I mistaken oder would this then be caused by something different?

[matbind]

This is quite difficult to say, without reproducing the issue. Tracks ParkChoir_EN_GR_2023-06-09 and 2x stretched have similar loading times, LenasDoor_EN-GR_2023-06-09 about half of that. So it could very well be that this was, at least in part, the cause of what you observed there.

Edit: Just checked in #83 - you wrote that both tracks did perform decently at some point, so it might be something else entirely. We'll see.

[matbind]

@KlienVo This should now be fixed, please test and close this issue if it is.

[matbind]

The track data is now read from the file where it is stored as soon as the performer clicks the track in the list of tracks in the performance. While it is loading the track cannot be started, indicated by a clock icon where the play/stop button usually is. Auto-play still works as before.

[KlienVo]

Sounds all good now! Looks like the problem has been solved. I generated 2 tracks with even bigger file sizes and partial counts now that seem to play back without problem. 1. PlanetarySkins_Anfang_50MbVersion (partials-count 11761, frame-count 56570) 2. PlanetarySkins_207Mb (partials-count 11761, frame-count 226277)