Correct way to play sounds?

[kikito]

It will just add to the confusion (we already have enough sound-related classes as it is)

So we agree on the basic thing then: The current system is already confusing.

What I'm suggesting is something to alleviate that confusion. Maybe it'll be simpler to see with code.

Right now, people do this:

Code: Select all

mySource = love.audio.newSource(...)
...
love.audio.play(mySource)
...
love.audio.play(mySource)

...And expect the source to be played twice. But it doesn't work. Hence the confusion.

Now with a Sound object, the first thing would be (probably) to remove love.audio.newSource from the API and replace it with love.audio.newSound.

Code would now look like this:

Code: Select all

mySound = love.audio.newSound(...)
...
love.audio.play(mySound)
...
love.audio.play(mySound)

This would work, and it's the intuitive way. Sources would be returned by love.audio.play (in case that the user wants to tweak their volume while they play, or cancel them, for example). New people will simply ignore them, just like they ignore SoundData. Advanced users will be able to manipulate them if they want.

I really think this will make things less confusing. If you think otherwise, please provide some code.

[dreadkillz]

Being able to stop a sound is also equally important. With repeatable calls to the same object, how would one be able to stop a specific instance of that sound? Playing a sound would need to return a generated id which you can use to stop a sound.

[kikito]

Being able to stop a sound is also equally important. With repeatable calls to the same object, how would one be able to stop a specific instance of that sound? Playing a sound would need to return a generated id which you can use to stop a sound.

You would need the source for that. As I said, the source being played gets returned by love.audio.play:

Code: Select all

local mySound = love.audio.newSound(...)
...
local source1 = love.audio.play(mySound)
local source2 = love.audio.play(mySound)
...
love.audio.stop(source1) -- source2 keeps playing

It's just that now you don't have to mess with sources unless you need them.

[Dattorz]

I think part of the problem here is that "Source" is not a very good name. What is "Source" referring to - the origin of the sound's actual data, or the origin of the sound being played in 3D space? In LOVE's case, "Source" refers to the latter. I think a better name would be "SoundChannel".

I also don't think we should encourage the use of keeping persistent Sources on a per-SoundData basis. This isn't really what Sources are meant for. If we have new users creating a separate Source for every SoundData they load, and keeping these Sources around for the entire duration of the game, they will soon be shocked to learn that LOVE won't play all of their sounds because Sources are a finite resource. It is essentially stuffing all the available sound channels with sounds that, 95% of the time, won't actually be playing, and will just be wasting space. Any large project involving sound is guaranteed to hit the sound channel limit if Sources are managed like this.

It seems like the only justification for this method of Source management is performance reasons. This is an implementation issue and should be addressed as such. I strongly object to altering the API to work around this issue - it will add needless complexity and if the underlying implementation changes then we're stuck with an overly-specific API that is no longer necessary and will have to be deprecated. And legacy APIs are kind of gross.

[kikito]

I also don't think we should encourage the use of keeping persistent Sources on a per-SoundData basis.

AFAIK sources are stored in memory, not on the "Sound channels". The limit is the computer's RAM, unless I'm mistaken. Nevertheless, I agree that the source "pools" should not be kept indefinitely. Sources which have not been played in the last 20 seconds or so should be purged to avoid memory consumption.

I strongly object to altering the API to work around this issue

Well, I do think that if an API is not good enough, it must be changed.

[Dattorz]

AFAIK sources are stored in memory, not on the "Sound channels". The limit is the computer's RAM, unless I'm mistaken.

Wait, really? That might change things... I think I'll do some tests with this and then I'll get back to you.

[Boolsheet]

There is a limit of concurrently playing Sources. I think OpenAL Soft (used in the Windows and Linux build) defaults to 64, but is configurable by the user with a ini file.

Edit: LÖVE defaults to a hardcoded limit of 64 sources.

[Dattorz]

Oops. TIL. This whole time I've been simply creating a new Source every time I went to play an existing SoundData.

There is a caveat, however, that prevents me from adopting this method for my own purposes, and that is the large memory footprint that comes from having multiple preloaded Sources for the same SoundData. So far, I've found that dynamic creation of Sources is fast enough on my machine that I don't really see an immediate need to preload my Sources instead, so for now I'm going to favor memory footprint over a slight speed gain.