Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement active sensing alike #95

Closed
atsushieno opened this issue Feb 16, 2022 · 3 comments
Closed

implement active sensing alike #95

atsushieno opened this issue Feb 16, 2022 · 3 comments

Comments

@atsushieno
Copy link
Owner

atsushieno commented Feb 16, 2022

Sometimes when a host is killed, the disconnected plugin service spew infinite log lines which means it's running its audio processing forever.

2022-02-16 10:53:41.486 291-2760/? I/chatty: uid=1041(audioserver) HwBinder:291_4 identical 1 line
2022-02-16 10:53:41.499 291-2760/? W/android.hardware.audio.service.ranchu: TinyalsaSink::write:125 pcm_write was late reading frames, dropping 22131 us of audio
...

We should send and receive MIDI active sensing alike i.e. mutual health check messages and shut down if it's dead.

@atsushieno
Copy link
Owner Author

Copied from #101 :

aap::PluginClientInstance::activate() starts active sensing, and aap::PluginClientInstance::deactivate() stops it. While processing audio, it is supposed to send active sensing messages. It should have no timestamp content as there may be time mismatch.

AAP aap::PluginServiceInstance::updateActiveSensingStatus() is called by the native binder based service implementation, and updates latest_active_sensing_time field (time is managed only within the service process). When aap::PluginServiceInstance::process() runs, it checks the time field and if it was way old (which TBD, but it's 300 msec. in MIDI 1.0 Standard), it does not call the plugin's process() function.

atsushieno added a commit that referenced this issue May 28, 2022
It is to prepare for #73 and #95.

(Though depending on how we actually bind those callbacks, the Kotlin API
may be removed and transformed to hook into native listener.)
@atsushieno
Copy link
Owner Author

I have been rethinking about status updates. In MIDI era we needed active sensing because it is impossible for clients (senders) to find the latest status. For AAP, we can immediately know if AAP Service is not working, as either Binder is shut down, or each operation returns error (we nowadays indeed detect those). Also the services can dump logs for details.

Therefore we do not really need active sensing alike. This can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant