Hardware/Software:
OpenSeizureDetector 5.1.0a
Devices: Xiaomi Redmi 13C & Samsung Galaxy A16
OS: Any
MP3 file: Verified working OK
Related issues: #246 and #250
Problem description
When enabling “Use MP3 Alarm Sound”, the warning sound is playing forever
However:
The MP3 alarm file is now playing correctly and no longer terminated after 5 seconds (see issue #250)
When disabling the MP3 alarm option → normal built-in warning sound is working correctly as before, i. e it is terminated after a single "bip".
Android System sounds are working fine. Both warning and alarm volume can be set through the system alarm (see issue #246)
Steps to reproduce
Open OpenSeizureDetector settings
Enable Use MP3 Alarm Sound
Select a valid MP3 file (one that is working in other apps)
Trigger a test warning or a real warning
Expected behaviour:
When MP3 alarm is enabled, the warning "bips" should work exactly like they work without an MP3 enabled alarm.
Actual behaviour:
The warning "bips" will never stop. Only shutting down OSD and restarting it will stop those endless warnings
Just to clarify what (in my humble opinion) the system should do:
In case of a "warning" condition a few "bips" should be audible. This is supposed to warn the PineTime wearer to calm the wrist movements, to prevent the triggering of an alarm.
In case that an mp3 file is configured as an alarm message, and the wearer of the PineTime has a seizure in public, then that mp3 file should play indefinitely.
The only two events that should terminate the playing of the mp3 file are:
- a member of the public is assisting the wearer, and switches the playing of the file off manually.
- the phone receives an incoming call (from a medical person who is responding to an SMS that was triggered by the alarm).
The reason for this setup is to allow an epileptic person to be in public without being constantly in need of an assistant present who is familiar with the treatment of a seizure.
Having a look at the beta branch (with some AI support), I suggest to loop by kind, not by clip duration. Right now playMp3() decides whether to loop based on the file's length (< 10000ms), which is unrelated to whether the sound should repeat. It should decide based on the rawResName kind it's already being passed.
This also lets us drop the 10-second-duration branching entirely, and simplifies the existing "already playing, don't restart" guard (lines 960–978) — that guard's latch-timer-based cutoff is really just a workaround for the other issue; once looping is instead scoped to alarm only, that guard can stay simple (just "don't restart the same URI while it's already playing") without needing the duration/latch-period math.
To actually stop the mp3 file we could change the "Mute Alarm" button to a bigger "Stop Alarm message" button. A member of the public pressing that button without assisting the epileptic person during a seizure is unlikely.
Should anyone disagree with the proposed functionality (or have an even better proposal or a suggestion for improvements), then please put it into the comments.
Hardware/Software:
Related issues: #246 and #250
Problem description
When enabling “Use MP3 Alarm Sound”, the warning sound is playing forever
However:
The MP3 alarm file is now playing correctly and no longer terminated after 5 seconds (see issue #250)
When disabling the MP3 alarm option → normal built-in warning sound is working correctly as before, i. e it is terminated after a single "bip".
Android System sounds are working fine. Both warning and alarm volume can be set through the system alarm (see issue #246)
Steps to reproduce
Expected behaviour:
When MP3 alarm is enabled, the warning "bips" should work exactly like they work without an MP3 enabled alarm.
Actual behaviour:
The warning "bips" will never stop. Only shutting down OSD and restarting it will stop those endless warnings
Just to clarify what (in my humble opinion) the system should do:
In case of a "warning" condition a few "bips" should be audible. This is supposed to warn the PineTime wearer to calm the wrist movements, to prevent the triggering of an alarm.
In case that an mp3 file is configured as an alarm message, and the wearer of the PineTime has a seizure in public, then that mp3 file should play indefinitely.
The only two events that should terminate the playing of the mp3 file are:
The reason for this setup is to allow an epileptic person to be in public without being constantly in need of an assistant present who is familiar with the treatment of a seizure.
Having a look at the beta branch (with some AI support), I suggest to loop by kind, not by clip duration. Right now playMp3() decides whether to loop based on the file's length (< 10000ms), which is unrelated to whether the sound should repeat. It should decide based on the rawResName kind it's already being passed.
This also lets us drop the 10-second-duration branching entirely, and simplifies the existing "already playing, don't restart" guard (lines 960–978) — that guard's latch-timer-based cutoff is really just a workaround for the other issue; once looping is instead scoped to alarm only, that guard can stay simple (just "don't restart the same URI while it's already playing") without needing the duration/latch-period math.
To actually stop the mp3 file we could change the "Mute Alarm" button to a bigger "Stop Alarm message" button. A member of the public pressing that button without assisting the epileptic person during a seizure is unlikely.
Should anyone disagree with the proposed functionality (or have an even better proposal or a suggestion for improvements), then please put it into the comments.