[FEATURE] Provide a way to force stop sounds

[aburkowsky9]

Is your feature request related to a problem? Please describe.
For various reasons there are instances of the device continuing to play sounds like the Incoming ringing sound after answering, ending, or rejecting a call. The only remedy I am currently aware of outside of a larger refactor is to access the private property _soundcache on the Device and stop the sound using something like the following:

  const stopIncomingCallSound = useCallback(() => {
    const soundCache: Map<Device.SoundName, { stop: () => void }> | undefined =  state.device?._soundcache;
    soundCache?.get(Device.SoundName.Incoming)?.stop();
  }, [state.device]);

Describe the solution you'd like
This is clearly undesirable since the _soundcache property is private and should be inaccessible. Im sure direct access is not a stable feature. It would be much better to have an exposed method on the Device or Call instance to force change in play state of a sound.

Describe alternatives you've considered
Clearly there are other issues causing this kind of behavior. Largely there are some architectural concerns that will take time to implement on our side, but there is also the possibility of an existing bug in the SDK itself, but this seems like a reasonable feature to provide as an escape hatch.

device?.audio?.incoming(false);

While the method on the audio property is available to disable sounds is available this method doesn't seem to work with my specific case and it's also problematic in that I would have to reenable the sound at some point.

Additional context
None

[charliesantos]

@aburkowsky9 thanks for reaching out. We will consider this feature request.
Regarding the issue where sometimes the sounds won't stop playing, do you have any reproduction steps so we can take a look at?

[aburkowsky9]

@charliesantos thank you.

I think it would be pretty difficult for you to reproduce but Im happy to schedule a screenshare session with a dev if you'd like. Im currently facing a bug when a user attempts to change their worker activity to Offline through the task router SDK when they have a pending reservation. The task router SDK receives an error to which I am able to handle properly. I cannot identify any real effect on the voice SDK Device or Call instances so I'm not sure where things are going wrong there. The only oddity I have identified is occasionally in this case I see the incoming event get triggered on the Device several times, but just as often its triggered only once as during normal flows. In either case, I only ever see one Call instance in calls array on the Device.

[charliesantos]

@aburkowsky9 this complicates things since there's a task router SDK involved. To better isolate the issue, can you try to reproduce using our Voice JS SDK quickstart https://www.twilio.com/docs/voice/sdks/javascript/get-started?

[aburkowsky9]

@charliesantos I will give it a shot if I find sometime next week, but im not necessarily looking for help identifying a fix for the bug. Im not sure that it would be easily replicable in a quick start app and it could just become its own wormhole. Largely, I just think this feature request could help the user experience of this SDK.

[charliesantos]

@aburkowsky9 I understand. The feature is being considered.
Please let me know how it goes once you're able to try the quickstart.

[ealexseen]

Can you add two methods for Device class?

Because _soundcache have private

I need public methods to change the audio state (stop or play)

// types
soundCachePlay(key: Device.SoundName): void;
soundCacheStop(key: Device.SoundName): void;

// methods for Device
soundCachePlay = (key: Device.SoundName) => {
   if (key) this._soundcache.get(key).play()
}
soundCacheStop = (key: Device.SoundName) => {
   if (key) this._soundcache.get(key).stop()
}

[charliesantos]

Closing this now. We're tracking this feature request internally. Please feel free to follow up if needed.