pabru
commented
6 years ago It might be best to go ahead with VLC over Telnet integration for this.
Pros:
- no native binaries - works on ARM and other CPU architectures without recompiling
- no native binary version dependencies - no need to recompile because of breaking ABI changes
- no need to pull in a third-party dependency
- quite easy to program as (AFAIK) it's just simple text over TCP socket
Cons:
- may be flaky due to intra-host connectivity breaking for some reason
- not native library integration = blackbox = can enter unknown states and cause flakiness/hang-ups
- efficiency (not likely to have any impact, but listed here for efficiency
- may need VLC-side activation by the user (turn on the right VLC setting)
- needs native binary to be installed (come on, VLC is a common application)
To check:
- is it possible to run more than one VLC {, telnet} session? if not, we could be polluting a session that the user has already loaded with their own music. we should isolate the AtSoundtrack session into a separate VLC instance or something, if possible/practical.
- the exact protocol/command syntax for the telnet interface
Options:
Edit: was audio source, but existing Spotify integrations treat Spotify as a controllable, black-box sound emitter rather than as a source of an audio byte stream. It might be easier if this project doesn't integrate with pure-Java libraries but instead treats some binary on the host machine as a similar controllable, black-box sound emitter.