01-04-2021, 04:19 PM
This was probably the most annoying bug to test I have ever seen as I had to actually run the tone generator for about 20 minutes to hear when it fails and I had to do so every time I tried something. But the solution is simple and to me somewhat satisfyingly "low level".
Ths short version: The problem occurs on Android and maybe 32bit iPhones (i.e. the iPhone 5s of those supporting phyphox). It is independent of how often you set the frequency, but happens after an exact number of periods - even on the built in tone generator experiment.
In detail, the problem was that there was an integer overflow while calculating the index for the sine lookup table. Instead of calculating the sine function for each sample (which would mean 48000 sines per second - and that is not a quick and simple calculation) phyphox generates a table of 4096 pre-calculated sine values (thanks to sine's symmetry we could do with a fourth of this, but the implementation is easier this way). When generating the tone we then need to calculate the index of these values, which simply means that instead of calculating a phase from 0 to 2pi, we calculate an integer phase from 0 to 4095. And since it is cyclic, we just calculate an absurdly large number and map it to the 0 to 4095 range with the modulo function. And this absurdly large number hit the maximum of a signed 32bit integer of 2^31-1.
In terms of the tone generator, this means that limit is reached after (2^31-1)/48000 periods. So, if you try the default frequency of the included tone generator at 440 Hz, the tone will stop after 1192 seconds (almost 20 minutes). If you set it to 100 Hz it works for over an hour and if you set it to 8738Hz it breaks after exactly one minute.
The good news is that this is an easy fix included in the next update (probably another beta). The bad news is that this will be a while since it is a rather niche problem and the first change since we published the last beta version just before Christmas. Unfortunately, there is not much you can do about it except for trying to work around the problem by finishing the measurement with fewer total periods (I know, a very strange and hard to control limitation) or pausing the measurement, saving the current state and re-opening the state to continue from there. You might also be able to use two or more tone generators as the phase is tracked for each generator individually (using a different tone generator for different frequency range while keeping the others at a frequency of zero), but this is quite certainly not worth the hassle.
Ths short version: The problem occurs on Android and maybe 32bit iPhones (i.e. the iPhone 5s of those supporting phyphox). It is independent of how often you set the frequency, but happens after an exact number of periods - even on the built in tone generator experiment.
In detail, the problem was that there was an integer overflow while calculating the index for the sine lookup table. Instead of calculating the sine function for each sample (which would mean 48000 sines per second - and that is not a quick and simple calculation) phyphox generates a table of 4096 pre-calculated sine values (thanks to sine's symmetry we could do with a fourth of this, but the implementation is easier this way). When generating the tone we then need to calculate the index of these values, which simply means that instead of calculating a phase from 0 to 2pi, we calculate an integer phase from 0 to 4095. And since it is cyclic, we just calculate an absurdly large number and map it to the 0 to 4095 range with the modulo function. And this absurdly large number hit the maximum of a signed 32bit integer of 2^31-1.
In terms of the tone generator, this means that limit is reached after (2^31-1)/48000 periods. So, if you try the default frequency of the included tone generator at 440 Hz, the tone will stop after 1192 seconds (almost 20 minutes). If you set it to 100 Hz it works for over an hour and if you set it to 8738Hz it breaks after exactly one minute.
The good news is that this is an easy fix included in the next update (probably another beta). The bad news is that this will be a while since it is a rather niche problem and the first change since we published the last beta version just before Christmas. Unfortunately, there is not much you can do about it except for trying to work around the problem by finishing the measurement with fewer total periods (I know, a very strange and hard to control limitation) or pausing the measurement, saving the current state and re-opening the state to continue from there. You might also be able to use two or more tone generators as the phase is tracked for each generator individually (using a different tone generator for different frequency range while keeping the others at a frequency of zero), but this is quite certainly not worth the hassle.