sciAudio - a new way to put sound in your games!

[gumby]

By the way, sciAudio is still having occasional problems where it'll either fail to play a sound or fail to exit when the game closes.  I think the failure to play is caused by not being able to write to the conductor file.

[Collector]

Are you closing the file after every write? Could it be an issue with UAC? What if the file was written in the temp dir? Another possibility, is the file getting locked by any other process?

[gumby]

Yeah, it could be any of those.  I haven't had a chance to troubleshoot very much yet, been just 'go-go-go' with getting Soulshade Asylum completed.

[Cloudee1]

I also see opportunity for one more additional feature.  Pausing the game should ideally pause the audio as well.  Not sure if I can pause the audio playback, but I'll take a look.

Have you had a chance to ponder this pause idea yet. I have found a use for it.

Now that I now had to add cue points to a midi track and actually code against them I can sync the music to the action in the game. However when a print dialog appears on the screen, the midi track is paused however the sciaudio is not. Thereby throwing off the synchronization.

[troflip]

For this other little project I was working on
http://sciprogramming.com/community/index.php?topic=1618.msg9332#msg9332

I thought about how to implement audio, and I was going to offer support for sciAudio (e.g. just make it work automatically, because why not? I could do so by intercepting file system calls and seeing if it's writing to the conductor file, etc....).

But looking at what it takes to set up sciAudio and how it works, it seems like it could be simpler. It looks like most of the functionality could be abstracted away in the Sound class itself, and you wouldn't need to special case "sci audio" sounds. Your wav/mp3 files (it looks like they need to be renamed to .sciaudio, but I'm not sure why that decision was made) could just be numbered (or prefixed with a number) and plopped in the main game folder. e.g. 104_GunShot.wav. Then when you play sound 104, it would check to see if there is a file corresponding to that number, and send the info over to sciaudio instead of calling the DoSound kernel. Or rather, calls to DoSound could be replaced with calls to DoSoundCustom, which either forwards to DoSound or sciAudio. Basically, it would mean supporting all the DoSound functionality and forwarding to sci audio instead.

Of course, there are some features like fadein/fadeout times that the Sound class doesn't support (though it could be extended to do so).

Anyway, I just thought of this as I was looking how to support sciAudio - and instead I realized it would be much easier to just support wav files in the DoSound kernel - it's a little more seamless to write scripts against (and it's basically what Sierra did when they started supporting digital audio). And then I thought why couldn't sciAudio do the same? But I haven't used it, so maybe I'm overlooking something? If Gumby pops in again, maybe he could comment? Or maybe someone wants to take this up on their own? It might only require changes to the sci scripts.

[Kawa]

Basically HD texture packs then, but for sound resources. Implementation-wise, that is.

[gumby]

Anyway, I just thought of this as I was looking how to support sciAudio - and instead I realized it would be much easier to just support wav files in the DoSound kernel - it's a little more seamless to write scripts against (and it's basically what Sierra did when they started supporting digital audio). And then I thought why couldn't sciAudio do the same? But I haven't used it, so maybe I'm overlooking something? If Gumby pops in again, maybe he could comment? Or maybe someone wants to take this up on their own? It might only require changes to the sci scripts.

If I understand correctly, your question is can we integrate the calls to sciAudio into the Sound class and removing the need for a separate script file (sciAudio.sc)?  I think that should be possible.

[troflip]

Correct. I think it could all be hidden inside the Sound class (or possibly even in a wrapper around DoSound kernel, although that might be more complicated), and then be seamless to integrate - people could just switch over their sounds one by one by removing the midi resource, and adding a mp3/wav file that somehow uses that same number.

Slight downside of course is that you're referencing a number from script instead of a meaningful name - but having it work just like digital audio works in SCI1.1 seems like it could be a good thing.

[Collector]

Of course now that we have SCI1.1 how much will people need or want to use sciAudio? It was a great thing when we were limited to SCI0 and people were struggling with Soundbox and the limitations of what small wav samples could be embedded in a sound resource. And it does not take ScummVM into account.

If we do expand support for it, would it change the usage of the conductor files? How would it affect the termination of sciAudio on exit as there has been a problem with continuing after the game has exited. I did an inelegant solution with the DOSBox launcher for sciAudio to kill the process on DOSBox exit. This was also inexact as I had no easy way to distinguish between two instances of DOSBox running at the same time.

[Kawa]

Kinda makes me feel like hacking ScummVM.

Kinda.

Just a little.

[Collector]

Bored again?

[troflip]

Hacking ScummVM for what? It already supports sciAudio. Nothing would change.

If we do expand support for it, would it change the usage of the conductor files? How would it affect the termination of sciAudio on exit as there has been a problem with continuing after the game has exited. I did an inelegant solution with the DOSBox launcher for sciAudio to kill the process on DOSBox exit. This was also inexact as I had no easy way to distinguish between two instances of DOSBox running at the same time.

Nothing would change with the conductor files.

[Kawa]

Hacking ScummVM not to use sciAudio or anything, but to intercept DoSound calls and play an external track where available. So if you do (gMusic number: 4 play:), and there's a track-4.ogg or whatever, it'll play that instead of sound resource 4. No sciAudio.

And yes I'm bored, but not (that) suicidal.

[troflip]

Ah, makes sense. It's probably not *that* difficult, given that it already has logic to do the exact same thing for Sierra's digital audio resources.

[Collector]

Also some of the SVM supported games that people did "enhanced" digital sound tracks to replace the original internal MIDI.