Volume bug with Sound action

[vertigo]

I often use the Sound action to play various sounds at different points in flows for troubleshooting, so I know what's going on without having to watch it or look at the logs, but I've noticed some strange behavior. In one of my flows, I have it run through a few conditions and actions, then play a sound on the notification channel, then continue through the flow for a bit, then play one of two sounds, based on a condition. One of those sounds is the exact same as the first (same notification, same channel, which is typically turned all the way up so I can hear it better, though that's not really relevant here since they're both set exactly the same, and there's nothing in the flow between them, or otherwise, to modify the channel's volume), yet the first one always plays much quieter, whereas the second one is much louder. The other sound that plays off other branch of the condition is also always loud, similar in volume to the other (second) sound. Based on what was between the first and second sound, I hypothesized it had something to do with the sleep action, so I tried placing one before the first sound, and, if it's long enough, it results in the first sound being loud as well. I'm not sure what exactly "long enough" is, though, since it varies. I was able to get it to make a difference as low as 999ms, but it isn't consistent under 1900ms. At 1900 and above, it was loud every time I tried, though obviously I didn't spend a great deal of time repeating the test. I also tried different actions besides sleep, but that was the only one to make a difference. I have the sleep actions set to allow device sleep, though I doubt that matters, since it seems unlikely the device is going to sleep within a couple seconds.

[vertigo]

I just discovered this also appears to affect the TTS (Speech Output) action. I made a short flow to speak the battery percentage at varying intervals when charging (BTW, stuff like this would be a whole lot easier if multiple levels could be specified within one trigger, though I suspect that would have the issue of bloating the xml), and the first part of it is quiet. I have it say "Battery level is at {battery_level} percent" and I can hear "percent" loudly, but the rest is very quiet. In fact, I can even hear it ramping up, so the percentage (e.g. 81) is a little louder, "per" is louder still, and it's at full volume by the time it says "cent." And if I make it longer, the rest is also loud. I tried adding a hard/carriage return as well as a bunch of spaces before it, but that didn't help. Neither did "a Battery level..." It appears to need to ramp up the volume for some reason. Thinking maybe prolonging the period between flow and action execution (since sleeping helps, which has that effect), I tried using a loop with the Execution Count condition, making it loop anywhere from a few to ~15 seconds before executing the TTS action, but that didn't have an effect.

[Desmanto]

This seems to be audio focus problem. Other app or maybe previous flow/action is creating sound and haven't finish yet. The sound is quiet maybe because the app interrupting is using Audio Focus - Transient may duck. (duck in here means the volume become lower). After the sound finish at about 1900 ms, the volume become normal again.

Try to copy both notification sound to new flow and execute it normally from there, check if the volume still duck or not for the first one. I can't reproduce the problem here.

[vertigo]

It happens in multiple flows. As I said, I made a different flow to speak the battery level, which is very short, so the TTS action is right at the start. It still does it. It always ramps up the volume at the same time into when it starts, so consistently that I ended up making it say "The battery level is at {battery_level} The battery level is at {battery_level} percent." I tried all the different audio focus options, which didn't change it at all. It happens every, single time, and there is definitely nothing else playing, at least not audible (not even quiet, but it would have to be silent, because I'm holding it quite close while testing). The only thing I can think is that maybe when AM starts executing a flow, it takes a bit before it can fully access the audio, i.e. play at full volume, which is why using a sleep action fixes it, as that delays the audio output until AM has the access it needs. But it's definitely quite strange.

[Desmanto]

If it happens globally, then it might be as you have guess, the audio starting is slow. There is option in the Automagic settings > workarounds > Reduce text to speech delay. You may try to tick that to see if it helps.

[vertigo]

I didn't expect this to work and, unfortunately, it doesn't. If anything, I'd think it might make it worse, since if it started playing the audio even sooner, it would take even longer into the audio before the volume got where it should be. But there was no difference. Also, remember it happens with notification sounds, too, not just TTS.

[Desmanto]

Oh, yes, you are right. Reducing the delay might make it even worse.

Since when do you observe this kind of behaviour? Is it already like this since beginning?
Do you have other phone to test it out?
Test with all different kind of audio stream, to see if it still get the same low volume at the beginning
Try also to plug in 3.5 mm headset, speaker or bluetooth headset/speaker.

[vertigo]

The results are kinda all over the place:

Music, notification, and voice call streams work properly, though the notification stream is what I use in the other flow to play notification sounds, where I first discovered the problem. So in this flow it works, in that flow it doesn't. And in this flow, executing the action on its own behaves the same as executing the whole flow for all the streams, whereas the other flow works properly if I execute just the action, it's only if the flow runs that it doesn't (again, this is for the notification stream).

System stream works properly, though is much quieter.

Alarm and ring streams both exhibit the problem.

I also tried the different streams in the other flow, with the notification sound. Alarm and ring streams don't play at all (or it's so quiet I don't hear it), music and voice call streams work correctly, and system works but, again, is quieter.

So it seems music and voice call streams always work, alarm and ring streams never work, and notification stream is hit-and-miss. I'd like to be able to use the alarm stream, since that's the only one that's always turned all the way up. But, of course, they should all work, so the question is why aren't they.

[vertigo]

Ok, so I found the issue with the notification stream and why it works sometimes and not others. When the proximity sensor is covered, that's when the sound is quiet. If I run the first flow, the one that just plays a notification sound, while covering the proximity sensor (which is required for the flow to progress to the point where the sound is), the sound is quiet. If I change the flow so it will go there without the sensor covered and run it, it's loud. If I execute the sound action by itself, it does the same thing: quiet when covering the sensor, loud when not.

As if that's not strange enough, though, the second flow, which does TTS, isn't affected in this way. Well, I take that back. It wasn't when I first switched back to it to test it, but then I disconnected that part of the flow and added a sound one identical to the one in the other flow, and it had the same problem, showing it wasn't related to something in the first flow, and when I then disconnected that and reconnected the TTS portion, it's quiet now, too, when I cover the sensor. Though it doesn't seem as quiet, but it's hard to say. And strangely, it's quiet the entire time, not just the first second or two.

So three streams work, two don't, and one does only when the proximity sensor isn't covered.

[Desmanto]

If some of the stream doesn't work reliably, then you should avoid using it. I usually only use alarm and music stream only for the TTS. I never do all the try and error though. You might want to test it on other phone to see if this is ROM/device specific problem.