Closed gabryelreyes closed 1 month ago
mControllerDir
cannot be updated in the case of external controllers given that it may be located in a remote machine.
The only possibilty for the sounds to reliably work would be for them to be located relative to the world file, as this would ensure the files are in the same machine as the simulation or as URLs to be downloaded.
Otherwise, we can also modify the protocol to send the sound file to the server together with the speaker sound play command.
I do not know how easy/difficult it is to implement such a feature to handle files that are a couple hundred of kBytes. Caching would be required, as if it was a web resource.
Yes, if implementing such a feature, we should also implement some caching functionality.
Add a new speaker API to upload sound data to speaker devices from external controller. Speakers will then cache the data and a later call to play the file will work, regardless of what the path was (as long it is the same string used during the upload).
On controller side it will look like this:
...
const char[] LOCAL_SOUND_FILE="c:/foo/bar/x.wav";
wb_speaker_upload_sound( left, right, LOCAL_SOUND_FILE, balance);
....
wb_speaker_play_sound(... LOCAL_SOUND_FILE, ....);
The upload sound API will stream the data to the Webots instance together with the filename for caching.
This may result in large messages if we embed the content of eventually several wav files inside it.
Will this work or is there a message length limit to consider ? Is backward compatibiliy between controllers and Webots version an issue if we extend the speaker protocol ?
Yes, that would work. However, I believe we can probably implement this without modifying the API: When passing a sound file to wb_speaker_play_sound
, we could simply upload this sound file to the Webots server if it was not already uploaded and play it. This means that we have to maintain, in the libController, a list of sound files which have already been uploaded to avoid uploading them several times.
@omichel Ok, I'll embed the sound data upload logic into existing wb_speaker_play_sound() as suggested above..
Describe the Bug
Using a external controller: using the Speaker to play a WAV file that is found relative to the controller executable results in the file not to being found.
This should be possible according to the documentation: https://cyberbotics.com/doc/reference/speaker#description
Root cause
robot->controllerDir();
returns an empty string, asmControllerDir
is not updated if the controller is<extern>
. This results inQFile::exists(mControllerDir + filename)
returningfalse
for the WAV file.Steps to Reproduce
<extern>
controller.Speaker
device.pathToFile = "sounds/CoolSound.wav"
Expected behavior
Expected to hear the sound.
Observed behavior
System