Based on #1229 and after looking at

Looks like the speaker playAudio function takes in raw 8 bit signed mono PCM samples but then immediately converts them to DFPWM. Having read the discussion, this makes perfect sense, because otherwise the audio bandwidth for servers would be quite unreasonable.

I propose that a new function playDfpwm be added, which allows you to pass DFPWM samples directly to the speaker. This cuts down on processing costs in game, which could help servers, as we won't have to needlessly convert audio from DFPWM to PCM and then back again.

In addition, it might be nice to add a config option, disabled by default and commented to note bandwidth implications, that allows the playAudio function to actually play raw PCM samples directly, for those singleplayer users and willing multiplayer servers who would prefer the higher bandwidth but better quality where they can support it. This would be a non-breaking change in "userspace".

I also suggested this in a comment on 1229 but got no response. Speakers' initial development implementation did accept DFPWM, but, after a Twitter comment, it was later changed to accepting PCM from Lua code because it "possibly feels more natural than our speaker 'hardware' consuming DFPWM data", and it being "invisible to players" (I don't exactly get this part, since (human) players still have to encode their music to DFPWM - did this mean music player programs?)

since (human) players still have to encode their music to DFPWM

They don't have to. It's the native format supported by the speaker program, but it's perfectly fine to play raw PCM audio (for instance, from WAV files).

Really, the use of DFPWM on the Java/network side is an implementation detail. As mentioned in #1229, its there as an aesthetic choice (I want the audio to be a little tinny), but there's other ways that could be implemented.

I think exposing a separate playDFPWM feels a bit ugly. Right now there's one way to play raw audio, and everything else composes around that, which all feels quite nice.

since (human) players still have to encode their music to DFPWM

They don't have to. It's the native format supported by the speaker program, but it's perfectly fine to play raw PCM audio (for instance, from WAV files).

Really, the use of DFPWM on the Java/network side is an implementation detail. As mentioned in #1229, its there as an aesthetic choice (I want the audio to be a little tinny), but there's other ways that could be implemented.

I think exposing a separate playDFPWM feels a bit ugly. Right now there's one way to play raw audio, and everything else composes around that, which all feels quite nice.

I feel like the multiple rounds of encode/decode have been completely ignored here. What's your reasoning for ignoring it on this basis?

Ahh, sorry! I was trying to cover the multiple encode thing, but possibly that got a bit muddled.

The fact that DFPWM is used internally (and thus multiple encodes happen) is entirely an implementation detail and I don't want to shape the API around that.

Ahh, sorry! I was trying to cover the multiple encode thing, but possibly that got a bit muddled.

The fact that DFPWM is used internally (and thus multiple encodes happen) is entirely an implementation detail and I don't want to shape the API around that.

No worries! Hmm, right... How much processing impact would this multi encode have on a server, realistically? If it isn't that bad, I could understand this, but if its actually reasonably significant, I'd be concerned that form is being put before function

On the Java side? It's negligible. On the Lua side, it's a little worse, but it all happens on the computer thread, so isn't going to cause lag or anything.

concerned that form is being put before function

I'd argue that the very essence of CC is putting form before function. It has always aimed for a very specific style, and has avoided many features which would compromise on that.

On the Java side? It's negligible. On the Lua side, it's a little worse, but it all happens on the computer thread, so isn't going to cause lag or anything.

concerned that form is being put before function

I'd argue that the very essence of CC is putting form before function. It has always aimed for a very specific style, and has avoided many features which would compromise on that.

Okay, sounds good! I was most concerned about the Java side.

When I said form over function I was aiming at the form of the API, which if it had an impact on the server, would be (in my opinion) silly. I still feel like accepting DFPWM would be both good form and function, because it gives CC it's own format/feeling when it comes to audio, but that is again just an opinion and if the processing is negligible, it doesn't matter too much.