It looks like they’ve finally added the ability to use built-in system sounds with roAudioResource! http://sdkdocs.roku.com/display/sdkdoc/roAudioResource
Wow! Finally. Thanks Endless for noticing. If only there was a place where Roku could, you know, let us know this sort of thing had happened, like a bulletin board or something.
Nice to have that “'deadend” sound, I never recorded that.
Awesome! I had to add it in manually for my channel.
Cool. 
That will save some space in the channel packages. When playing the default sounds, can we have them play at the volume the user has set on their roku box so it is standardized across channels without having to specify the 25/50/75 percentage volume trigger? Something like sound.trigger() would be the default volume based on the roku setting?
“destruk” wrote:
Cool. :)can we have them play at the volume the user has set on their roku box so it is standardized across channels without having to specify the 25/50/75 percentage volume trigger? Something like sound.trigger() would be the default volume based on the roku setting?
They do change with the system menu sounds setting, unlike user-recorded sounds. The docs show them set at 50 and thats what i tried and it seems correct.
Been using them since I joined this little party in 2012.
dang it. even typed up a big reply about this a few days ago in some thread, but didn’t hit submit after noticing the thread was over 5 years old. 
“squirreltown” wrote:
“destruk” wrote:
Cool. :)can we have them play at the volume the user has set on their roku box so it is standardized across channels without having to specify the 25/50/75 percentage volume trigger? Something like sound.trigger() would be the default volume based on the roku setting?They do change with the system menu sounds setting, unlike user-recorded sounds. The docs show them set at 50 and thats what i tried and it seems correct.
So if you change the setting in the roku menu, they’re at the new volume without needing to change the script? ie if you go to settings/audio and change it to “off” then with the script volume at (50) they don’t make any sound?
“destruk” wrote:
So if you change the setting in the roku menu, they’re at the new volume without needing to change the script? ie if you go to settings/audio and change it to “off” then with the script volume at (50) they don’t make any sound?
Yep.
Thanks!
“BradC” wrote:
Been using them since I joined this little party in 2012.
Way to hold out on us, man…
They were just added to the SDK docs on March 31st.
Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.
“TheEndless” wrote:
“BradC” wrote:
Been using them since I joined this little party in 2012.
Way to hold out on us, man…
They were just added to the SDK docs on March 31st.
I know, I got that happy feeling you get when you have an answer someone is looking for, then after I typed it, I saw it was you who asked, and I was like, “wait a minute… he must already know this.” then I stopped and looked at the date, and I was like, “…oh… this is a really old question, that’s why… it probably didnt’ even exist back when he asked. everybody probably knows it now and I’ll look like an idiot for acting like I think it’s new info in 2015.” Then I see this thread and am disappointed again that I didn’t share it, since it would have actually been useful to people. I’m just glad you posted the update.
The odd part is I must have gotten the info from the docs somewhere, unless it was in the sample code.
“malort” wrote:
Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.
See above…
I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.
“TheEndless” wrote:
“malort” wrote:
Just noticed this too while browsing the docs. The last question now is if we can pull the menu volume setting? Would be nice to ignore firing events if the menu volume is off. Either way, this is great news! Thanks Roku.
See above…
“malort” wrote:
I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.
I don’t know of any way to get the volume setting, but if the box handles that automatically I’m not sure why you’d need it, unless you’re wanting it for custom sounds.
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.
“TheEndless” wrote:
“malort” wrote:
I have read the thread, and maybe I missed something. I do understand the stock sounds will use the global volume, and if one sets the volume off, our trigger will be silent. I would just like to know if the volume is off so we can bypass unnecessary code.
I don’t know of any way to get the volume setting, but if the box handles that automatically I’m not sure why you’d need it, unless you’re wanting it for custom sounds.
“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.
It would still be useful to be able to query the volume setting - that way if the volume is “off” then we wouldn’t need to use memory loading a sample (custom or not) that won’t be played or heard.
Thanks for the feedback. The feature request is noted.
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.
