RFC: Reworking sound sub-system

[calris]

OK, I've pushed sound-core into angband.o - hopefully the auto builder likes it. Commit is in my sound-devel-clean branch

There is an #ifdef SOUND in sound-core.c I don't really like, and in reality it could be removed. Removing it will mean that the sound preferences parser will always be compiled into angband whether there is a front-end sound module or not. I guess that's the price we pay to keep an auto builder happy

[calris]

Um Nick, I just noticed you pulled in all the patches from my (Very) dirty sound-devel branch instead of the cleaner patches sound-devel-clean

EDIT: The end result _should_ be the same though

[Nick]

OK, autobuilder is happy now.

One minor issue: unit tests don't compile unless ./configure is run with --disable-sdl-mixer (which is what the autobuilder does), because now init_sound_sdl is missing from angband.o. I couldn;t see an obvious fix, but I also couldn't see much harm.

[Nick]

One minor issue: unit tests don't compile unless ./configure is run with --disable-sdl-mixer (which is what the autobuilder does), because now init_sound_sdl is missing from angband.o. I couldn;t see an obvious fix, but I also couldn't see much harm.

Well, there was a fix - add a stub of init_sound_sdl to the test suite, and now everyone is happy. I think we can regard this as successfully integrated

BTW, I also worked out what was wrong with the birth tests - you had removed the -s option which the test script was using

[calris]

Well, there was a fix - add a stub of init_sound_sdl to the test suite, and now everyone is happy. I think we can regard this as successfully integrated

Is there any reason not to run the tests with --disable-sdl-mixer? If we want to test the parsing of the sound configuration etc., we could just add a dummy test sound module (which is essentially what you have done)

BTW, I also worked out what was wrong with the birth tests - you had removed the -s option which the test script was using

I just had a look through the commit history and can't figure out where I did that

And does sound work in Widnows? As I said, I never got a chance to test it

[Nick]

Is there any reason not to run the tests with --disable-sdl-mixer? If we want to test the parsing of the sound configuration etc., we could just add a dummy test sound module (which is essentially what you have done)

It's partly for my own convenience, so I can configure with SDL sound in my build environment, and don't have to keep reconfiguring.

I just had a look through the commit history and can't figure out where I did that

And does sound work in Widnows? As I said, I never got a chance to test it

Well, everything seems to work OK for now (I may have tested windows sound - I can't recall). I'll test more fully at some stage.

[PowerWyrm]

I've started to implement this for PWMAngband (the SDL part). I don't remember how it was working before (because I'm mainly using the Windows client), but the result doesn't seem to work as intended:
- long sounds are not reset (for example when stairscumming between two dungeon levels that don't have the same ambient theme -- first part of theme 1 is played, then first part of theme 2, then second part of theme 1...)
- some sounds seem to play two samples at the same time (for example when killing stuff -- 5 samples are available)

I need to check that in more details, especially compared to the Windows client.

[calris]

There should be no difference to the way sound is played - the core sound interface wasn't changed, I just moved the processing of the sound preferences into a standardised module common to all platforms.

- long sounds are not reset (for example when stairscumming between two dungeon levels that don't have the same ambient theme -- first part of theme 1 is played, then first part of theme 2, then second part of theme 1...)

SDL sound has always played samples over the top of each other which I quite like - for example if something summons undead as you hot something, the moaning can still be heard in the background

- some sounds seem to play two samples at the same time (for example when killing stuff -- 5 samples are available)

If there are multiple sounds, it randomly picks one - again, this is as it always was

I need to check that in more details, especially compared to the Windows client.

I don't play the Windows version, but a friend of mine does. He turned on sound and I noticed the sounds were seriously messed up - he got the 'thud' of hitting a wall once, and then it changed to thing 'ting' sound. Hopefully my patches will make Windows consistent with Linux

[PowerWyrm]

Ok, further investigation: the two problems mentioned are actually the same problem. When a sound is played and there's a request to play another sound, the second sound interrupts the first one, but the position is not reinitialized. When the first sound is played again, the system plays the end of the sample from the saved position, then plays the whole sample again, giving the impression that two samples are played.

Note: when I try the SDL client from PWMAngband prior to the system change, sounds are played properly from the start. I'll have to see what causes the new behavior.

On a side note, the SDL client with the new sound system crashed upon quitting the first time I enabled sound for a character. It seems that the SDL mixer didn't launch properly (sounds were not audible), so there's probably a memory error somewhere.

[PowerWyrm]

Found it. In PWMAngband, when loading a sound, I was doing:

if (mp3) Mix_FreeMusic(mp3);
mp3 = Mix_LoadMUS(filename);

This should be added back in load_sample_sdl():

if (sample->sample_data.music) Mix_FreeMusic(sample->sample_data.music);
sample->sample_data.music = Mix_LoadMUS(filename_buf);

[calris]

Found it. In PWMAngband, when loading a sound, I was doing:

if (mp3) Mix_FreeMusic(mp3);
mp3 = Mix_LoadMUS(filename);

This should be added back in load_sample_sdl():

if (sample->sample_data.music) Mix_FreeMusic(sample->sample_data.music);
sample->sample_data.music = Mix_LoadMUS(filename_buf);

Well that is very odd... This is basically forcing a reload of a sample that has already been loaded...

There is not code like this in V

[PowerWyrm]

Hmm that's not working because now the sound is loaded once and played from memory... And it seems that Mix_PlayMusic() isn't working as intended, as the doc says it should play any sample from the beginning... which is clearly not the case. Compatibility problem between SDL music system and Windows? Probably...

As a result I'll have to reimplement the old PWMAngband hack and trigger a reload each time a sound is played.

[PowerWyrm]

Well that is very odd... This is basically forcing a reload of a sample that has already been loaded...

There is not code like this in V

Yes. Mix_PlayMusic(sample, loop) is supposed to play "loop" times the "sample" sound from the beginning, but it's not the case... it restarts from where the sound was interrupted, finishes and then plays from the beginning. Probably a Windows issue.

[calris]

As a result I'll have to reimplement the old PWMAngband hack and trigger a reload each time a sound is played.

Hmm - have you had a look at how I've implemented sound for Windows?

Take a look at:

https://github.com/calris/angband/commits/sound-devel-clean

It's a much cleaner version (but in the end identical end result) to what Nick pulled. It's much easier to see what is going on

[PowerWyrm]

Alright... adding a "data->loaded = false;" after playing a sound did the trick for me. It's very ugly, but it works