Super super useful info. Something now Ryan can probably speak to. 
Sound NOT going through Discord is going to be def a good thing!
1 Like
Thanks! I had the idea when I was watching your Nova Q&A, you mentioned Discord, so I chatted here, then Steve was like âbut it compresses the soundâ, and I was like âbut what if it doesnât have to?â
Also, Ryan (nice to meet you) if you can tell me anything about:
-
how the sound is coming through the webapp, like WebAudio API or it is simple HTML Media Elements.
-
Is the final audio mix produced client-side or is it a ready made mix audio file(s)
If I get this to work, maybe we can talk about a step further of having an endpoint the app could tap into and then it will be efficient and not need to fake up an entire invisible browser, capture the audio, and pipe it to the bot, the bot could just simply play the audio from the endpoint. But that is future thinking.
Sorry @james, I didnât realise there was someone waiting for a response from me on here 
Firstly, what youâre trying to do sounds fun, and I would love to see something like that working. Iâm no expert with Discord bots, but from what I know of our Web Player, the âClick to Startâ button isnât just a feature for the user to only start sounds when they want, but a sneaky way for us to capture a genuine user interaction. As best as I understand, the Web Audio API by design, refuses to actually make any sound without a genuine user interaction, to prevent websites auto playing sounds, which would be very annoying. This is why the button exists, and I donât know of any way to avoid having at least one real click from the user somewhere on the page.
There might be some way to configure your botâs Chromium browser to bypass this restriction, in which case I think you can actually click anywhere on the page to trigger the sounds, the button is just there to prompt the user to click on something.
So I think that answers question 1) - we use Web Audio API to make the sounds.
And the reason we use Web Audio API is the answer to 2) - the Web Player locally fetches the original Sample files, and then uses a network of Web Audio nodes to mix the sound client side.
If you can convince some user agent to support running Web Audio API without any user interaction, then I think we can get somewhere, it should just be a matter of executing some JavaScript
2 Likes
Thank you @ryan.cassar,
So, yes⌠maybe it is a matter of rather than running the Web Page (playerâs) Basic Player in a browser (because that ALSO needs a response to the Cookie Question, right?)⌠instead run the embedded player (info in docs), and fake an interaction with some JavaScript?
The point of the interaction is that it is genuine - i.e. the browser knows the difference between a user clicking on a thing, and the code saying thing.click(), which if allowed, would of course defeat the purpose of requiring the genuine user interaction in the first place.
That said, IIRC even some regular popular browsers allow whitelisting some domains so they do not require this, or even learn when users frequent a page and stick around with it playing sound and automatically trust it (which is why sometimes we do not show the âClick to startâ button and just start playing). We however can not rely on users digging around their configuration, so we try to support the standard default settings.
But as I said, if James can find a pretend âbehind the scenesâ browser that lets them ignore that genuine user interaction by configuration - then it should just be a matter of opening the share audio page, or, if something on that page is still stopping playback (I donât know if the Cookie consent popup would or not), then using the Javascript Player directly, as per our docs should be a possibility 
2 Likes
Cool. Thank you. This helps. I am going to play around with this a little to see if I can get anything to trigger.
This is my first Discord bot, but that part was kind of easy. I first made a command for /ping and it returns âpongâ. Once I got there, I was able to trigger js (which I am more used to) with a command.
I was guessing on how the audio was distributed, but now this helps me get on the right track.
I will let you all know if I get anywhere.
2 Likes
ok. I am very close. If I turn on debugging and let the browser open it plays and sounds great, but if I keep the browser headless, it will not start the music. I think this may be an obstical I will not be able to get around by myself.
2 Likes
In that you suspect us making a change could remove the obstacle? Or that a working headless Web Audio output is not possible? One other thing the Web Player needs before it will make sound is a WebSocket connection to our servers to receive the instructions. Perhaps that connection isnât happening before the page is rendered. Can you follow the instructions in our API docs for the JS Player to make your own player that can work headless? It is still not really âdesigned to be run headlessâ, but it should give you the maximum flexibility we currently officially support
Let us know how you go and if you have anything specific you think we could do to make this work - excitement! 
1 Like
I wouldnât ever suspect you all to make a change on my behalf. Maybe if we get to a place where I have it working, then we can work together to get it across the finish line.
I will have to mull over the idea of making my own player. That could work. Maybe it is nothing in the Web Audio API, but in the page itself, and making my own would expose the piece I need.
Let me rebuild with this in mind and I will get back with you
2 Likes
No problems, I was just trying to clarify your previous comment about obstacles. If you do come up with something where it seems like we are the obstacle in your way, then be sure to let us know. No guarantee we will immediately do anything about it, but we might have some ideas or at least give us something to think about
2 Likes
Iâm certainly exciting to see even a partially broken version of whatever you manage to build! 