URL to configure speaker audio file

[Alan Noble]

At present, it is only possible to configure the speaker audio via a local file, using the AudioFilePath variable. It is proposed to add an AudioURL variable that specifies the URL of a remote file, i.e., a file hosted by a web server.

It is proposed to extend the use of AudioFilePath as follows:

• If connected to the network, the speaker netsender client will automatically attempt to get vars.
• If AudioURL is present, e.g.., https://ausocean.org/files/audio/xxx, compare the basename with the base name for AudioFilePath.
• If base names are identical, no action is required. Continue to use the file xxx.
• If there is no AudioFilePath or the base name is different, fetch the URL and then write the base name xxx to /home/pi/xxx, then update AudioFilePath accordingly.

If only AudioFilePath is present, revert to the current behavior.

The proposed mechanism is efficient in that AudioURL is only fetched if the base name is different from that of AudioFilePath.

‌

[David Sutton]

This is a duplicate (with more detail) of https://bitbucket.org/ausocean/av/issues/448/treatment-url-input-for-audio-file from the AV repo where these changes will likely be implemented (client side vs server side)

I have started implementing this feature, and currently I have made it that there is only 1 variable for audio path, and the path is determined to be either local, or online (based on the prefix) and this may reduce the complexity of the interface on the VidGrind side of things. (You can see the current implementation here)

As a side note, I don’t know how well we can handle “bad files” that are not proper audio files, or that are single channel (our sound card refuses to play single channel audio). The current implementation I have is to just check the MIME type, but this is definitely not perfect.

[Alan Noble]

The reason I thought we might keep a second variable is for persistence, i.e., to avoid the need to fetch the URL every single time. Essentially, AudioFilePath is a locally cached version of AudioURL. Perhaps you have an alternative approach in mind, though.

As for bad files, we have that issue even with the existing mechanism.

[David Sutton]

In my implementation the audio will get downloaded from the specified url to /home/pi/audio, from which the player will play the file from. This means that the file will only get downloaded when the url gets changed. It does mean that if you switch back to a url you used before the file would get redownloaded. However it does mean that if two urls contain a file with the same name (ie vidgrind calls everything audio.wav) that the file will actually get overwritten and not just assumed to be cached already because of a name match.

[David Sutton]

@Trek Hopton and I have discussed this and come up with the following:.

Given that we want the SCU to be usable without a network connection (after files have already been loaded), we need a way to be able to store the path to the file we actually want to play, as it will not always be in the default location (/home/pi/audio). To ensure that we know which file to play in offline mode, we will store a file (.txt or .conf) which treatment can read to determine where to play a file without getting vars in offline mode.
Additionally, we will store files downloaded from a URL in a path relative to that URL. eg. a file downloaded from “https://vidgrind.ausocean.org/audio/audio.wav” will be downloaded and stored in “/home/pi/treatment/vidgrind.ausocean.org/audio/audio.wav”, this way we can check the filepath of each URL to see if it has been downloaded previously and if so, we should use the cached value instead.
Hopefully this covers the use cases of online vs local, as well as network connected vs offline. Additionally, we only should need 1 var on vidgrind which should limit the amount of errors that a user could make during config (Trek said that this is not necessary if it adds too much complexity on the client, but with the current proposal, it should not add too much complexity)