I may have managed to fix both issues.
I first added a "Start" button to the listener route, which would activate both the HTTP music stream, and the new AudioStreamer call.
Then, I realised that if you listen in after starting the voice broadcast, even though the server sends the buffer header to the listener client, that header is not later passed to the AudioStreamer instance.
The solution was to create a state variable in the route component for the listener page that would store the buffer header, in the event that the server sends the header to the client before initialising the AudioStreamer.
I then passed this buffer header state variable into the useAudioStreamer file.
Finally, when the AudioStreamer is ready to initialise, the header it receives as a parameter can be applied to the AudioStreamer instance.
Below I have linked the updated code.
github.com/WoolDoughnut310/radio-broadcast/commit…
Hey! Solid work! I have a situation where if I start a voice broadcast first and I try to listen in, I don't hear anything, but if I start listening in and then I start a broadcast, it works.
I use the word start because I had to wrap the new AudioStreamer in an event listener because Chrome kept saying "The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page."
I suspect this is happening because mid-stream, I can't get the bufferHeader which means audio stream won't start.
do you have any suggestions on how I can fix this?