what does this error msg look like?? Is it just a msgbox like selecting power off for example? I've never seen/had this error as I have and have always had a HDD.
Something like 'Error 203: HDD not found', or similar... I make a short video, when I am at home.
I don't think it's necessary to control each individual voice channel.
Well, I suppose the 'fading' between BGM and any 'per-game-music' (if ever implemented), could also be realized via turning the master-volume down in steps (but still within milliseconds) and turn it up to the specified value (maximum or what's specified in a/the config), just before the 'per-game-sound' would be played.
But it is definitely of less importance! At least some kind of control about the volume - preferably during runtime (which is now possible for the master-volume) - is something crucial (as a 'base' regarding the implementation) for various features!
A setting to control all 24 voice channels volume would be fine. Something like audsrv_adpcm_volume() as set_volume() already handles the pcm master volume.
You are referring to the master-volume (which changes all channels simultaneously), correct?
Yes, that's definitely more than enough for quite a lot new sound-related features (or at least giving it a very good base to expand on). Like I said: Even the fading and BGM-to-'other'-sound-transition and other things would already work with it, so that's fine.
Anyway, with its current design, it isn't possible to control each of the 24 channels as volume levels for 24 unique ADPCM samples. AUDSRV will currently pick a free channel to play any ADPCM sample that you tell it to play, as long as it is loaded into SPU2 memory.
Oh, so it just chooses the next free channel, when any SFX is meant to be played? Soooo... Since we currently have only one sfx/sound running simultaneously, that would be the first... Ever... {^.^} lol
This dynamic channel-choice is quite good (i.e. for demos, or where it is not really needed to 'know' on which channel something is), IMO... But without an implementation to control on which channel it is played on, the 'backend' of - OPL - would need to track, which channel it (sounds/SFX) is/are played on (if there are ever more than 1 playing simultaneously) and then it could call (RPC) the lib to lower the volume for the channel it is meant to be played on (which would entirely depend on the implementation of a per-channel-volume-control).
Your function to define on which voice-channel it is played on (libside-extension and controlled from EE via RPCs) is better and can be reused (in other Homebrew-Projects as well as for new features related to sounds in OPL).
However... Control about all voice-channels (individual volume-control) is just NOT very important (but some volume-control during runtime IS important).
That (individual voice-channel-control for volume) is far less important, than any of the other things I posted in my previous post!
@sp193
I've been playing around with a bgm thread
That's great! THX for trying to implement it.
but I'm not having much luck, I tried to split the code into multiple functions so only the playing part is the actual running thread.
Yes, that's a good idea (IMO).
Code:
//bgm gubbins
static int wav;
static int bgm_thread_id = -1;
static int gEnableBGM = 1; //this is here for testing until an option is made in settings
static unsigned char bgm_stack[0xA00] ALIGNED(128);
extern void *_gp;
static int bgmFormat(void)
{
int ret;
struct audsrv_fmt_t bgm_fmt;
bgm_fmt.bits = 16;
bgm_fmt.freq = 22050;
bgm_fmt.channels = 2;
It would be nice, if bgm_fmt could derive it's values from the audio-file itself, to properly support 1 up to 5.1-voice-channels, with 8 or 16 Bit and varying Frequency.
Btw.: 'gubbins' hehe...
Code:
if ((ret = audsrv_set_format(&bgm_fmt))!= 0)
{
printf("Error setting audio format %d\n", ret);
}
else audsrv_set_volume(MAX_VOLUME);
return ret;
}
So 'MAX_VOLUME' now needs to be changed (not here, but at the location, where it points to), to use the specified volume-value and the new audsrv-function
@sp193 implemented.
So basically this quoted part does not need a change, but it is a reminder to implement audsrv_adpcm_set_volume(), at those other places in the source (where it is 'meant to be placed'/needed).
Code:
static int bgmLoad(const char *bgm_path)
{
wav = fileXioOpen(bgm_path, O_RDONLY);
if (wav >= 0) {
printf("Failed to open wav file \n");
return -ENOENT;
}
return 0;
}
Well, like
@sp193 already pointed out...
I left the other stuff out, because
@sp193 already mentioned it (as I have seen now).
I made bgmInit part of the deferredinit, I thought that would be the best place for it?
Code:
static void deferredAudioInit(void)
{
int ret;
ret = sfxInit();
if (ret >= 0)
LOG("sfxInit: %d samples loaded.\n", ret);
else
LOG("sfxInit: failed to initialize - %d.\n", ret);
ret = bgmInit();
if (ret >= 0)
LOG("bgmInit: bgm loaded.\n");
else
LOG("bgmInit: failed to initialize.\n");
}
Yes, it should work from there.
Are there any major problems you can see straight off the bat? I'm not sure if the chunk size needs to be smaller as some sram is already taken up by sfx.
I really don't know, how big it should be.
I have made some changes to AUDSRV:
- MIN_VOLUME and MAX_VOLUME on the EE will now be defined as 0 and 100 respectively, to fit the local functions.
- audsrv_play_adpcm was changed to audsrv_ch_play_adpcm, so that the channel can be specified.
- Added audsrv_adpcm_set_volume().
Great (and quite fast)! I haven't expected it so soon (+ the additional stuff).
- Interesting and good idea. That makes it more 'standardized' (if another app will use the lib) and quite obvious (in human readable form) to handle/control it.
- Oooooh! So now we can say the one and only simultaneously played file (currently) can even be played on channel 9 (or whatever)? That's great! That's indeed greeeaaat! That's very useful (especially once we play multiple sounds simultaneously)!
- That's the function to call (during runtime), to set/control the master-volume, right?
These are all very good additions and reusable updates, to a PS2SDK-Library!
Doing that during only a few days is quite (-dare I say it -)... impressive, because it is a milestone regarding sound-control in Homebrew! I suppose you invested quite some time (since all of it [implementation + structural ideas]) would need it.
Thank you for this update!!!
By the documentation, the memory for ADPCM begins at address 0x5010 of local memory. The documentation also states that the ring buffers for PCM audio begins at the start of local memory (0x4000-0x4FFF). The hardware will access that region of memory. So there should be no need to worry about PCM.
Oh, that's good and makes it a bit easier to handle. So basically the hardware (MMU?) will take care of the stream?! THX for the info!
