Thank you for having a look at my problem!
Unfortunately the trick of using the number of data point in the audio_in buffer does not work... On iOS, there is a one second delay when the experiment is run, which let the audio_in buffer be filled to the max even though it is only the first run. If you run the attached program, you will see this effect (on the frist run, size_audio_in is already 48000). On Android, it tells me that the audio_in is filled at 4800 points, which is exactly 10%, or a 100ms delay, which I do not really understand, but any way, we are facing the problem of the difference in which the timer is set between the two OS. [this last sentence is too long and I am afraid not 100% english, I hope I am clear enough]
It is the first time that this problem is seen I guess because 99% of the time you do your experiment in one go. Here, you create the frequency in one go, and you analyse the results in the following analysis. Note that the Walnut experiment you created add the same mechanism, but since the starting frequency was set and could not be changed, it gave a way to test this. Maybe I should have a second look to this experiment and see whether it could be modified.
Anyway, since you plan to change the way the audio is handled, it is not a big problem for me, it is more of an academic interest (and a clear sign that I should test my experiments on both OS !), do not spent too much time on that problem. If you have an easy way to detect a first pass I will be happy, but if not my hack is working so I am happy nevertheless.
Cheers,
Fred
Hello!
Well I guess you could, but you would have to tinker a bit the algorithm for it to work on both iOS and Android. But as soon as you use both the time and the index you will end up with a solution which will be more or less mathematically equivalent to the one I implemented, the sum of both timer and index smaller than 3. It may be more elegant, but it won't really answer the problem I think, don't you agree?
(As noted above, this is more an academic interest for me; I would be glad if a solution is found, and I appreciate your help, but I have a working solution and it is not worth too much of your time).
Cheers,
Fred
Well, actually I had a second look at the Walnut experiment, and I am pretty sure that there is a problem in the way the frequency are handled. At least on Android, I think that the first measurement is not correct, because of the problems discussed here. Again, not a big deal, but the solution will not be found there.
Cheers,
Fred
Unfortunately the trick of using the number of data point in the audio_in buffer does not work... On iOS, there is a one second delay when the experiment is run, which let the audio_in buffer be filled to the max even though it is only the first run. If you run the attached program, you will see this effect (on the frist run, size_audio_in is already 48000). On Android, it tells me that the audio_in is filled at 4800 points, which is exactly 10%, or a 100ms delay, which I do not really understand, but any way, we are facing the problem of the difference in which the timer is set between the two OS. [this last sentence is too long and I am afraid not 100% english, I hope I am clear enough]
It is the first time that this problem is seen I guess because 99% of the time you do your experiment in one go. Here, you create the frequency in one go, and you analyse the results in the following analysis. Note that the Walnut experiment you created add the same mechanism, but since the starting frequency was set and could not be changed, it gave a way to test this. Maybe I should have a second look to this experiment and see whether it could be modified.
Anyway, since you plan to change the way the audio is handled, it is not a big problem for me, it is more of an academic interest (and a clear sign that I should test my experiments on both OS !), do not spent too much time on that problem. If you have an easy way to detect a first pass I will be happy, but if not my hack is working so I am happy nevertheless.
Cheers,
Fred
(04-27-2020, 09:54 AM)Jens Noritzsch Wrote: I am still rather new to phyphox editor so please apologize if this cannot work: would it be possible to match the index against time in the first two steps, i.e., set index to 0 for time=0 and set index to 1 for time close to the increment?
Hello!
Well I guess you could, but you would have to tinker a bit the algorithm for it to work on both iOS and Android. But as soon as you use both the time and the index you will end up with a solution which will be more or less mathematically equivalent to the one I implemented, the sum of both timer and index smaller than 3. It may be more elegant, but it won't really answer the problem I think, don't you agree?
(As noted above, this is more an academic interest for me; I would be glad if a solution is found, and I appreciate your help, but I have a working solution and it is not worth too much of your time).
Cheers,
Fred
(04-27-2020, 03:58 PM)fbouquet Wrote: Note that the Walnut experiment you created add the same mechanism, but since the starting frequency was set and could not be changed, it gave a way to test this. Maybe I should have a second look to this experiment and see whether it could be modified.
Well, actually I had a second look at the Walnut experiment, and I am pretty sure that there is a problem in the way the frequency are handled. At least on Android, I think that the first measurement is not correct, because of the problems discussed here. Again, not a big deal, but the solution will not be found there.
Cheers,
Fred