Music through multiple speakers via wireless

[ISSY127]

I'm trying out CC:tweaks out for the first time, and after a while of messing around I've created a setup using rednet where a computer recieves decoded chunks of a song through broadcast and plays it on as many speakers as possible (only tried 2 for now though). I kind of understand the encode decode aspect, aside from the values provided in a table (which shows when printing), but what I would like to know is how these chunks actually work on a deeper level. This would help me for example understand how much of a song is playing, and I could implement a playbar on a monitor (just thinking ahead).

I am also confused on the frequency of broadcasts and receiving messages, as the music sometimes cuts out (I make the broadcast pc sleep for 2.7 seconds, which play's the song continuously at the right speed, but still has the cutout issue). I'm still doing research but any help would be greatly appreciated!

[SquidDev]

What I would like to know is how these chunks actually work on a deeper level. This would help me for example understand how much of a song is playing, and I could implement a playbar on a monitor (just thinking ahead).

I guess there's several layers here:

• DFPWM itself is documented on this page (slightly nicer typeset version here). Though the details should be largely irrelevant here — all you need to know is each byte of DFPWM data corresponds to 8 samples of audio, and thus $\frac{8}{48000} = \frac{1}{6000}$ seconds of audio.

• The raw audio data: This bit of the wiki is probably the best introduction — this explains the basics of how audio is represented (PCM audio, etc...).

• For the internals of audio playback, this is quite complicated, due to having to handle the client/server split and Minecraft's sound engine:

  1. When you call playAudio, the speaker stores the audio data.
  2. Every tick, if the speaker isn't currently playing anything, or if there is less than 0.5s of audio remaining, the speaker sends new audio data to the client.
  3. On the client, we then enqueue this new audio data, and OpenAL then plays that out.

Note that there's several intermediate buffers here (both on the client and on the server). This is designed to reduce stuttering (particularly if the server is lagging), but requires you to keep the buffers pretty full. I haven't seen your code, but if you're just sending one audio chunk at a time, I suspect you're never filling the buffers all the way, so what happens is the first chunk of audio is entirely exhausted, and then you send the next chunk!

If you can, it's better to rely on the speaker_audio_empty event, rather than just submitting audio periodically (as an aside, a full chunk of audio isn't 2.7s exactly, but rather $\frac{128 \times 1024}{48000} = \frac{1024}{375} \approx 2.73$). If you're doing this over the network, this would require each client to pull audio, rather than pushing it.

This all said, if you're trying to play audio across multiple speakers, that is really hard. If two speakers are out of sync by even a single tick, things can sound terrible, and there's some known but ill-understood issues with speakers (#1488, #2120, #1874), which doesn't help!

[ISSY127]

Thank you for taking the time to respond :)

The first link you included I did a read of both renditions (I'll look over them later to wrap my head around it), and your explination on the samples of audio that play is good. Currently my code goes something like:

--Host:

For chunk in io.lines("song_name", 16 * 1024) do
Buffer = decoder.decode(chunk)
-- music is what channel is called
rednet.boradcast(buffer, "music")

    --wait for response
    Repeat
           id, message = rednet.recieve()
    Until message == "finished"

End

--Reciever:

While true do
Buffer = rednet.recieve("music",5)

     If buffer then
             while not speaker.playAudio(buffer) do
                     os.pullEvent ("speaker_audio_empty")
             End
             rednet.send(HOST_ID, "finished")
      end

end

This works surprisingly well with filling the buffer's, I wrote this before your response, but your response does make sense rather than having a constant sleep timer (as I had before)

When I do io.lines(file_name, 16 * 1024), what exactly does that 16 * 1024 point to? Surely its not nearly 20k characters, and I know the chunk sizes have significance to fit as audio samples.

I think if I understand that element of the speakers, I can attempt to implement autoplaying other songs and looping the same one (etc).

[ISSY127]

Also sorry for the terrible written code I wrote this on my phone

[ISSY127]

Did some more research, still dont get the io.lines part but just a matter of time before I understand it, thank you for your help!

[SquidDev]

Sorry, had missed your message from last week!

what exactly does that 16 * 1024 point to? Surely its not nearly 20k characters, and I know the chunk sizes have significance to fit as audio samples.

Yep, we read 20k characters at a time. Once decoded, this maps to 128*1024 audio samples, which is the maximum number of samples the speaker can play in one go.

[ISSY127]

Wow, that number seems really high, thinking on it yeah it makes sense. Again thank you for taking the time to reply!