Roku Developer Program

[squirreltown]

"malort" wrote:
I am not assuming anything the firmware does. I am only talking about the logic I have to use when I need to calculate the right sound. If the user chooses to mute the feedback, then there is no reason for me to iterate through any audio feedback logic I have employed. Either way, as I did mention, it's probably not a big performance hit at all.. it just seems like the right way to handle it.

No, i agree it would be nice to have. Personally there are things I'd put ahead of it, like being able to query the amount of free graphic memory.

[TheEndless]

"malort" wrote:
I am not assuming anything the firmware does. I am only talking about the logic I have to use when I need to calculate the right sound. If the user chooses to mute the feedback, then there is no reason for me to iterate through any audio feedback logic I have employed. Either way, as I did mention, it's probably not a big performance hit at all.. it just seems like the right way to handle it.

I understand what you're trying to do, but it seems to me that you'd be over complicating your code. If the volume is handled automatically, then why riddle your code with if/then logic to avoid triggering the sound? Even if you encapsulate it in a separate function, the new logic would probably have an equivalent performance impact, which I imagine is negligible anyway.

[malort]

I completely agree with you, in regards to more important features. I was only mentioning it would be nice to know. Thanks for the discussion all 🙂

"squirreltown" wrote:

"malort" wrote:
I am not assuming anything the firmware does. I am only talking about the logic I have to use when I need to calculate the right sound. If the user chooses to mute the feedback, then there is no reason for me to iterate through any audio feedback logic I have employed. Either way, as I did mention, it's probably not a big performance hit at all.. it just seems like the right way to handle it.

No, i agree it would be nice to have. Personally there are things I'd put ahead of it, like being able to query the amount of free graphic memory.

[TheEndless]

"malort" wrote:
I am not assuming anything the firmware does. I am only talking about the logic I have to use when I need to calculate the right sound. If the user chooses to mute the feedback, then there is no reason for me to iterate through any audio feedback logic I have employed. Either way, as I did mention, it's probably not a big performance hit at all.. it just seems like the right way to handle it.

"squirreltown" wrote:

"malort" wrote:
The box does not handle the sounds automatically when using the 2d api. Yes, it will handle the volume accordingly when using the built-in sounds, so that is great, really great. The fact is we have to add our own code to trigger the events. If the user has disabled the menu volume, then why not bypass any logic used to trigger the sound clips. It's not really a big issue, and it's probably not much of a performance hit to just trigger vs checking if the volume is off.

You are assuming that the box with zero volume set is doing trigger(0) but we don't actually know if thats how the firmware handles it. Performance-wise I'd bet it's un-measurable.

FYI, they just added this to the documentation:
"Note that system sound effects are played at the volume selected in the user's settings, or not played at all if the user has turned sound effects off."