keeping the pilotlight lit, normally when listening to an audiobook or music playlist the Pinephone locks it's screen after a minute and suspends the OS after a few more minutes as set by the user.
This suspend action makes it possible to carry a pinephone all day ready ro receive incoming telephone calls and still have battery if the phone is not used for more than 45min to an hour a day.
Every time the system suspends the audio stream is killed, even after wakeup most of the time the audio playback app needs to be killed and restarted for it to output audio.
I want a way to keep a tightly controlled and minimized audio app running while using minimal CPU waste power, and without the bloat of the system processes.
I only want the pilotlight lit, not the whole furnace.
I have several ideas that might be able to be implemented with only scripts, but I will need a LOT of help making this work if I run into bugs.
The idea works like this:
1- when an audio app is running we get the audio pause/skip controls on the lockscreen, there are already processes which load when audio is started
2- when audio mode is detected a special suspend mode is activated or enabled
A- an exception is made to the suspend mode script, perhaps an alternate suspend mode
a- the process running the audio is moved to one awake cpu core and the lowest voltage and mhz possible is engaged, only enough to allow for the audio stream to continue
b- if possible audio is buffered into hardware audio acceleration chip and even the audio app CPU is suspended until 10-20 sec before the buffer runs out,
c- buffer refills, suspend special audio process, repeating
B- when system is taken out of suspend the audio app and special settings for single CPU are ended
An alternative would be to add an audio buffer playback system to the programs running on the modem module, perhaps a virtual serial audio device fed over the data connection line. The modem module has its own Android based no-GUI OS, memory, and CPU, it is always awake and waiting for incoming calls and texts, which results in it sending a de-suspend command to the Pinephone, as running its own OS processes.
Currently unless there is USB power in the Pinephone pro can get at most around two hours of audio playback even though the the screen is dark and locked as all processes continue to run at full power.
This suspend action makes it possible to carry a pinephone all day ready ro receive incoming telephone calls and still have battery if the phone is not used for more than 45min to an hour a day.
Every time the system suspends the audio stream is killed, even after wakeup most of the time the audio playback app needs to be killed and restarted for it to output audio.
I want a way to keep a tightly controlled and minimized audio app running while using minimal CPU waste power, and without the bloat of the system processes.
I only want the pilotlight lit, not the whole furnace.
I have several ideas that might be able to be implemented with only scripts, but I will need a LOT of help making this work if I run into bugs.
The idea works like this:
1- when an audio app is running we get the audio pause/skip controls on the lockscreen, there are already processes which load when audio is started
2- when audio mode is detected a special suspend mode is activated or enabled
A- an exception is made to the suspend mode script, perhaps an alternate suspend mode
a- the process running the audio is moved to one awake cpu core and the lowest voltage and mhz possible is engaged, only enough to allow for the audio stream to continue
b- if possible audio is buffered into hardware audio acceleration chip and even the audio app CPU is suspended until 10-20 sec before the buffer runs out,
c- buffer refills, suspend special audio process, repeating
B- when system is taken out of suspend the audio app and special settings for single CPU are ended
An alternative would be to add an audio buffer playback system to the programs running on the modem module, perhaps a virtual serial audio device fed over the data connection line. The modem module has its own Android based no-GUI OS, memory, and CPU, it is always awake and waiting for incoming calls and texts, which results in it sending a de-suspend command to the Pinephone, as running its own OS processes.
Currently unless there is USB power in the Pinephone pro can get at most around two hours of audio playback even though the the screen is dark and locked as all processes continue to run at full power.
