ID:2421974
 
Not a bug
BYOND Version:512
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 71.0.3578.98
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary: Before 512.1459, sound systems that rely upon the SOUND_UPDATE flag to continually update and repeatedly play long sounds or play looping sounds worked without issue, but now, the client plays no sound at all when the flag is present, regardless if you have file defined for the sound datum or not.

Numbered Steps to Reproduce Problem: Use the code snippet below and place the object defined within it on a simple map. Be sure to feed it your own sounds. On 512.1458 and earlier, the object will play the sound while continually updating its properties. However, more importantly, the object will also play the sound from the beginning for players that connect while the sound is being updated and looped on the client side, all without having to make any special accommodations for that behavior. On 512.1459 and later, the same object will do literally nothing, as the SOUND_UPDATE flag prevents it from playing any sound at all as of 512.1459, even though file is clearly defined.

Code Snippet (if applicable) to Reproduce Problem:
/obj/jukebox
name = "Jukebox"
var/S = 'sounds/juketune.ogg'

/obj/jukebox/New()
. = ..()
Soundloop()

/obj/jukebox/proc/Soundloop()
spawn while(1)
sleep(1)
var/sound/playing = sound(S, 1, channel = 5)
playing.status = SOUND_UPDATE
playing.y = 1
for(var/mob/M in world)
if(!M.client)
continue
playing.x = x - M.x
playing.z = y - M.y
M << playing


Expected Results: For the sound in the loop to start playing if there's no sound already playing on the channel, even for freshly connected clients, exactly how the SOUND_UPDATE behavior has been for years now.

Actual Results: The code snippet plays literally nothing on clients running 512.1459 or greater.

Does the problem occur: It occurs for every client running 512.1459 or greater.

When does the problem NOT occur? For clients running 512.1458 or older.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? Every single version that has the SOUND_UPDATE flag prior to 512.1459 features this behavior.

Workarounds: The only workaround I can think of is to axe the repeat flag and just play the sound without the SOUND_UPDATE flag for every client that meets the conditions to hear the sound, but this comes at the loss of seamlessness for the audio, has the issue of freshly connected clients being unable to hear the audio until the sound completes a loop, and can result in the audio cutting itself off since the SOUND_UPDATE flag is no longer capable of playing sounds.

Kaiochao resolved issue (Not a bug)
This is indeed a bug. The old behavior of playing audio if the channel has no audio already playing has been present for years now. The bug in that thread has to do with SOUND_UPDATE muting the channel if file is null, which was fixed but in a way that completely breaks the old behavior.
The old behavior was wrong, though. It should never have been done that way. The new behavior is consistent.
is it possible to get a version of SOUND_UPDATE that can play on empty channels?

right now BYOND's sound management is far removed from dev access and it's been bugging me for many years. Jukebox-like mechanics are impossible to have as a result, which merits its example in this report in my opinion.

if i'm overlooking something let me know, but we currently have no way to guarantee that a specific sound is currently playing on a specific channel or access how long it has left, if such client variables were made public then we could easily check the use-case for each client and use SOUND_UPDATE or another sound type as a result.

one workaround would be to set the sound's .wait var to 1, but that has hidden functionality and doesn't work the way you think it would and isn't specific to a client, so a player who walks into an area won't hear the sound at all or in the same way as other players. if a player's 1 minute into the song, a player just walking in will be hearing it from the beginning or not at all, there is no sync function that i'm aware of for a player being introduced to a sound that wasn't previously playing for their client.

in regards to the OP, it would be nice if we could have a radio playing in an area with some music, and if a player walks into the area 1 minute in, they can suddenly hear the music in the same way as every other player.

a sound's .wait and .volume aren't client-sided which makes them infeasible, and the sound's .channel isn't available for being locked to specific clients, we can't tell a client to only 'listen' to specific channels, so that's not a viable workaround either. sound management in BYOND has been a mess (and i've been a dev for a long time), so it'd be nice if we could get more clarity on how it works.

it's possible i'm wrong completely with this post, so if there's some post or article that completely explains byond's sound functionality please point me to it.
Being able to find out if a sound is currently playing is on a list of possible features to explore for 513. It involves the server asking the client about that, so that's the catch.

I'm not sure what you mean about channel not being available because it's locked to specific clients. Seems like if you manage channels well on the server end you should be fine.

Your idea for being able to offset into a song is a good one.
So, for those wondering what's up with sound update, I managed to get it working, basically what you have to do is play the sound on the channel and then immediately update that sound and resend it again.

listeners<<sound
sound.status=SOUND_UPDATE
listeners<<sound


This will get around the issue of not having a sound playing on the given channel.

Here's an issue I've found with this though: If you don't set a channel, SOUND_UPDATE still applies to all sounds even though a file is present. In the documentation it states:

"If you play a null sound (no file) on channel 0, the settings for the datum will affect all channels."

I've noticed that even if you have a file, if you use SOUND_MUTE|SOUND_UPDATE on a sound with channel 0, all sounds are affected, even though it states that this should only happen when there is no file present for the sound.

As a result of this, it's not possible to use SOUND_UPDATE on channel 0 at all, as the only thing restricting it from applying to all sounds seems to be overlooked (file).
In response to Lummox JR
Lummox JR wrote:
Being able to find out if a sound is currently playing is on a list of possible features to explore for 513. It involves the server asking the client about that, so that's the catch.

I'm not sure what you mean about channel not being available because it's locked to specific clients. Seems like if you manage channels well on the server end you should be fine.

Your idea for being able to offset into a song is a good one.

so why would you poll the client, as opposed to say retrieve the sound duration on the server and expose that?

honestly disappointed you never implemented freetype for maptext, too.
In response to Somepotato
Somepotato wrote:
Lummox JR wrote:
Being able to find out if a sound is currently playing is on a list of possible features to explore for 513. It involves the server asking the client about that, so that's the catch.

I'm not sure what you mean about channel not being available because it's locked to specific clients. Seems like if you manage channels well on the server end you should be fine.

Your idea for being able to offset into a song is a good one.

so why would you poll the client, as opposed to say retrieve the sound duration on the server and expose that?

The server does not load any sound libraries. If the server is running in Linux, it has no access to the routines the client uses to play sounds.

Plus, there are other good reasons to query the client. It's been generally requested that I add a way for the server to know if a sound is playing.

honestly disappointed you never implemented freetype for maptext, too.

I considered it, although implementing a third-party library is always a huge exercise in frustration. The main reason I didn't: There's still a possibility the font won't display the same way on the client, if the server owner forgot to include it in their resources or if the client for some reason didn't successfully install it, or possibly other unforeseen issues.