PS2 OPL SND TEST

[TnA]

Btw.: Does audsrv_quit() still freeze OPL, when it is called?
You might need to unhook some open 'handles'!

I can't wait for the feature to be merged into the main-repo! Hehe!

 

[Krah]

When I started messing around with audsrv I had SFX playing as PCM, that same/similar code is being used for BGM now as SFX are adpcm like they should've been from the get go.

However using the PCM code that was working before (although it had problems still played the file) I can't get any audio playback, I tried making the code a standalone function without an EE thread and linked to a key press just to test to see if I could get a wave file to play with the adpcm code already initiated but it fails.

@sp193
Is it possible there is a conflict in AUDSRV that is not allowing both ADPCM and PCM to be used concurrently? I had a quick look and noticed all PCM functions call rpc_1 and ADPCM functions call rpc_2 with the exception of audsrv_adpcm_init which calls rpc_1.
Could that cause a conflict, should it call 2 like the rest of the ADPCM functions or would that make no difference?

 

[sp193]

The RPCs are protected with a semaphore. Was it ever working, after I made those changes on Sunday? I did not actually test my work.

As for the state machine of BGM playback (i.e. sequence of states that the system will transit between), you should have an idea of what it should do.
Right now, I realize that it cannot actually stop playing the BGM because it has no exit condition for the loop within bgmPlay(). There may also be a need to synchronize with the main thread because you must never interrupt the BGM thread while it is calling any RPC functions (may leave the RPC blocked from further calls), and the main thread needs to know when the BGM thread is done before deinitialization is completed (done when OPL is closed, HDLoader server is started and when a game is booted).
If this seems too complicated, I can help you with this soon.

Regarding reloading the settings after the user changes settings: OPL calls applyConfig from the main thread, after the user selects "OK" from the config screen. This is different from what happens at initialization, whereby applyConfig is called by _loadConfig, which is run from the IO thread.
But then again, aren't you planning to add a sounds menu? So there is no need to change the applyConfig function. You can call the sound initialization functions after it.

The difference between rpc_1 and rpc_2 is just the number of arguments that we want to pass to the function on the IOP side.

There is no problem with ps2-packer anymore. At least, I have not seen a single bad file file generated, ever since the fix.

The SPU2 has memory of its own, which is known as local memory. The SPU2 will read the PCM data that is transferred there, with sceSdBlockTransfer(). There is no MMU for the IOP.

The volume functions on the EE always expected a volume parameter in the range of 0 to 100, but that was not how the EE-side MIN_VOLUME and MAX_VOLUME were defined.

 

[Krah]

Was it ever working, after I made those changes on Sunday?

I just compiled an old build of the source code I had on my pc with your updates to AUDSRV and can confirm working PCM audio (if I don't also use ADPCM)

If this seems too complicated, I can help you with this soon.

This does sound a bit complicated to me but I'll still try myself until you have free time, although using the code in my statement above with the working PCM code copied into the current build along side the working ADPCM code; PCM stalls the console.

But then again, aren't you planning to add a sounds menu? So there is no need to change the applyConfig function. You can call the sound initialization functions after it.

void guiShowAudioConfig(void)
{
    const char *AudioPaths[] = {"<not set>", "MC 1", "MC 2", "HDD", "USB", NULL};
    diaSetEnum(diaAudioConfig, CFG_AUDIOPATH, AudioPaths);
    diaSetInt(diaAudioConfig, CFG_SFX, gEnableSFX);
    diaSetInt(diaAudioConfig, CFG_BGM, gEnableBGM);
    diaSetInt(diaAudioConfig, CFG_AUDIOPATH, gAudioPath);
    diaSetInt(diaAudioConfig, CFG_SFX_VOLUME, gSFXVolume);
    diaSetInt(diaAudioConfig, CFG_BGM_VOLUME, gBGMVolume);

    int ret = diaExecuteDialog(diaAudioConfig, -1, 1, &guiUpdater);
    if (ret) {
        diaGetInt(diaAudioConfig, CFG_SFX, &gEnableSFX);
        diaGetInt(diaAudioConfig, CFG_BGM, &gEnableBGM);
        diaGetInt(diaAudioConfig, CFG_AUDIOPATH, &gAudioPath);
        diaGetInt(diaAudioConfig, CFG_SFX_VOLUME, &gSFXVolume);
        diaGetInt(diaAudioConfig, CFG_BGM_VOLUME, &gBGMVolume);
        applyConfig(-1, -1);
        setVolume();
    }
}

Is this the call to applyConfig you mean? The one in the audio settings menu, if so adding a call to setVolume() works as intended allowing for runtime adjusting of the adpcm volume (probably pcm too but I cant test that yet) but if I call sfxInit() again to reset pathing and re-read sfx files or even just call audsrv_adpcm_init() to clear the spu2 buffer of samples; the console stalls.

The volume functions on the EE always expected a volume parameter in the range of 0 to 100, but that was not how the EE-side MIN_VOLUME and MAX_VOLUME were defined.

From what I've tested your changes to the volume control in AUDSRV work perfectly, thanks for taking the time to do this.

 

[sp193]

I just compiled an old build of the source code I had on my pc with your updates to AUDSRV and can confirm working PCM audio (if I don't also use ADPCM)

What exactly happens? So if you tried to play PCM, would this totally prevent any ADPCM samples from being played?
Or is it unable to play PCM audio at all, once you played ADPCM sounds?

What do you mean by "don't also use ADPCM"? Do you still initialize the ADPCM half of AUDSRV as usual, or did you remove all traces of ADPCM code?

void guiShowAudioConfig(void)
{
    const char *AudioPaths[] = {"<not set>", "MC 1", "MC 2", "HDD", "USB", NULL};
    diaSetEnum(diaAudioConfig, CFG_AUDIOPATH, AudioPaths);
    diaSetInt(diaAudioConfig, CFG_SFX, gEnableSFX);
    diaSetInt(diaAudioConfig, CFG_BGM, gEnableBGM);
    diaSetInt(diaAudioConfig, CFG_AUDIOPATH, gAudioPath);
    diaSetInt(diaAudioConfig, CFG_SFX_VOLUME, gSFXVolume);
    diaSetInt(diaAudioConfig, CFG_BGM_VOLUME, gBGMVolume);

    int ret = diaExecuteDialog(diaAudioConfig, -1, 1, &guiUpdater);
    if (ret) {
        diaGetInt(diaAudioConfig, CFG_SFX, &gEnableSFX);
        diaGetInt(diaAudioConfig, CFG_BGM, &gEnableBGM);
        diaGetInt(diaAudioConfig, CFG_AUDIOPATH, &gAudioPath);
        diaGetInt(diaAudioConfig, CFG_SFX_VOLUME, &gSFXVolume);
        diaGetInt(diaAudioConfig, CFG_BGM_VOLUME, &gBGMVolume);
        applyConfig(-1, -1);
        setVolume();
    }
}

Is this the call to applyConfig you mean? The one in the audio settings menu, if so adding a call to setVolume() works as intended allowing for runtime adjusting of the adpcm volume (probably pcm too but I cant test that yet)

Yes, indeed.

but if I call sfxInit() again to reset pathing and re-read sfx files

If you want to get it to load new sound files, you might want to split off the logic for initializing AUDSRV itself from the logic that initializes the paths. Then it would not need to call the RPC-initialization functions, when it does not actually need to.

or even just call audsrv_adpcm_init() to clear the spu2 buffer of samples; the console stalls.

But do other functions work? Did you stop playback of
(or simply avoid playing) all sounds first?

From what I've tested your changes to the volume control in AUDSRV work perfectly, thanks for taking the time to do this.

Sure, no problem.

 

[Krah]

What exactly happens? So if you tried to play PCM, would this totally prevent any ADPCM samples from being played?
Or is it unable to play PCM audio at all, once you played ADPCM sounds?

What do you mean by "don't also use ADPCM"? Do you still initialize the ADPCM half of AUDSRV as usual, or did you remove all traces of ADPCM code?

PCM works if I remove all traces of ADPCM code, if I keep the ADPCM code in and add PCM code; ADPCM plays fine but when I trigger PCM the console freezes. (Even if ADPCM just initializes loads files into the buffer but never plays them if PCM is triggered the console stalls.)

If you want to get it to load new sound files, you might want to split off the logic for initializing AUDSRV itself from the logic that initializes the paths. Then it would not need to call the RPC-initialization functions, when it does not actually

Will do, Don't I need to call audsrv_adpcm_init again to clear the buffer? It's just audsrv_init that doesn't need to be called again right.

But do other functions work? Did you stop playback of
(or simply avoid playing) all sounds first?

Edit: Other functions do work, yea; setVolume() for example works so volume is now adjustable during runtime.

I didn't stop all playback but no sound was playing, I guess maybe it's because it's trying to play the confirm sound when clicking 'OK' at the same time as I'm trying to clear the buffer and reinit; never thought of that. Not sure of a way around that but I'll try think of something. (To test first I think I'll just remove the sound call for gSelectButton to make sure that's the problem) I'm not sure of any other way to stop playback other than audsrv_quit but then I'd have to reinit the whole lib

Edit: had a quick look, reading the comments the call to audsrv_adpcm_init is meant to also stop all playback.

Edit After tests:
Removing the sound call from selecting 'OK' in the settings menu did not stop the console from freezing, it seems as though anytime i try call audsrv_adpcm_init more than that one time at startup the console hangs.

@TnA
to quickly test I called audsrv_quit() with a key press on the main page (down) not only did it not stall the console it didn't close the lib functions, sound continued to play at all other sound calls...weird
Yet if i try call it in the settings menu upon selecting OK OPL doesn't even boot

 

[sp193]

PCM works if I remove all traces of ADPCM code, if I keep the ADPCM code in and add PCM code; ADPCM plays fine but when I trigger PCM the console freezes. (Even if ADPCM just initializes loads files into the buffer but never plays them if PCM is triggered the console stalls.)

This is strange. If you want to try something else first, you can try to load LIBSD from rom0 (instead of loading the homebrew libsd), to see if it is caused by our homebrew LIBSD module being bugged.

SifLoadModule("rom0:LIBSD", 0, NULL);

Will do, Don't I need to call audsrv_adpcm_init again to clear the buffer? It's just audsrv_init that doesn't need to be called again right.

You have to call audsrv_adpcm_init, but at least you do not need to reinitialize the whole AUDSRV library.

Edit: Other functions do work, yea; setVolume() for example works so volume is now adjustable during runtime.

Hence it should be that the audsrv_adpcm_init() function that is not working right, although it does not do much. It does call sceSdInit(), which means it actually tears down and re-initializes the state of libsd (and the SPU2) as well.

I didn't stop all playback but no sound was playing, I guess maybe it's because it's trying to play the confirm sound when clicking 'OK' at the same time as I'm trying to clear the buffer and reinit; never thought of that. Not sure of a way around that but I'll try think of something. (To test first I think I'll just remove the sound call for gSelectButton to make sure that's the problem) I'm not sure of any other way to stop playback other than audsrv_quit but then I'd have to reinit the whole lib

I mean to ask if you actually stopped your own code from playing sounds. Since all these functions are RPC function calls, they will block each other from running. Calling a function that waits for a long time, like audsrv_wait_audio, will also prevent all other function calls for extended periods of time until that function returns.

Anyway, I think we should establish if it is a LIBSD problem first.

 

[Krah]

@sp193
Partial success, using LIBSD instead of FREESD like you said fixes the problem with multiple calls to audsrv_adpcm_init.

The problem with PCM code along side ADPCM still remains, PCM stalls the console. However this could just be a coding problem on my side?

I thought the easiest way to test before dealing with threading would be to use the sample code for playwav

void pcm_test(void)
{
    int ret;
    int played;
    int err;
    char chunk[2048];
    FILE *wav;
    struct audsrv_fmt_t format;

    format.bits = 16;
    format.freq = 22050;
    format.channels = 2;
    err = audsrv_set_format(&format);
    printf("set format returned %d\n", err);
    printf("audsrv returned error string: %s\n", audsrv_get_error_string());

    audsrv_set_volume(MAX_VOLUME);

    wav = fopen("mass0:SND/up_down.wav", "rb");
    if (wav == NULL)
    {
        printf("failed to open wav file\n");
        audsrv_quit();
    }

    fseek(wav, 0x30, SEEK_SET);

    printf("starting play loop\n");
    played = 0;
    while (1)
    {
        ret = fread(chunk, 1, sizeof(chunk), wav);
        if (ret > 0)
        {
            audsrv_wait_audio(ret);
            audsrv_play_audio(chunk, ret);
        }

        if (ret < sizeof(chunk))
        {
            /* no more data */
            break;
        }

        played++;
        if (played % 8 == 0)
        {
            printf(".");
        }

        if (played == 512) break;
    }

    fclose(wav);

    printf("sample: stopping audsrv\n");
    audsrv_quit();

    printf("sample: ended\n");
}

and call it at a key press, so i commented out the ADPCM call for KEY_UP on the main page and put in a call to pcm_test(), scrolling down ADPCM plays fine but scrolling up (triggering pcm_test) stalls the console just like before.
But for all I know this is not the 'correct' way to test the PCM code.

 

[sp193]

It may not be your fault. There is actually one programming sin that AUDSRV commits anyway, which is to call multiple sound functions simultaneously without thread locking. I do not have my documentation at hand, so I cannot tell if it is illegal to use the block and voice functions simultaneously... although I think it is.

EDIT: I think its lack of thread-locking is fine, as long as one does not make multiple function calls via the IOP. From the EE, AUDSRV is protected from concurrent access because of the SIF RPC client semaphore.

The block and voice transfer functions do not share data either, so it is probably okay to perform simultaneous voice and block transfers.

New changes to the PS2SDK, to fix existing issues:

• Changed libsd's SD_SWITCH_KEYDOWN and SD_SWITCH_KEYUP to SD_SWITCH_KEYON and SD_SWITCH_KEYOFF respectively
• Fixed AUDSRV clearing the block transfer handler with sceSdInit() whenever audsrv_adpcm_init() is called.
• audsrv_adpcm_init() will no longer call sceSdInit(), but will stop playing ADPCM sounds by setting SD_SWITCH_KEYOFF.
• audsrv_adpcm_init() will now initialize the volume for voice channel 0 as well.
• Standardized the DMA channel numbers throughout AUDSRV.
• audsrv_quit() will now call audsrv_adpcm_init() to stop voice playback and will terminate the playback thread before deinitializing the RPC client - to avoid a RPC call with an invalid RPC client.

 

[Krah]

New changes to the PS2SDK, to fix existing issues:

• Changed libsd's SD_SWITCH_KEYDOWN and SD_SWITCH_KEYUP to SD_SWITCH_KEYON and SD_SWITCH_KEYOFF respectively
• Fixed AUDSRV clearing the block transfer handler with sceSdInit() whenever audsrv_adpcm_init() is called.
• audsrv_adpcm_init() will no longer call sceSdInit(), but will stop playing ADPCM sounds by setting SD_SWITCH_KEYOFF.
• audsrv_adpcm_init() will now initialize the volume for voice channel 0 as well.
• Standardized the DMA channel numbers throughout AUDSRV.
• audsrv_quit() will now call audsrv_adpcm_init() to stop voice playback and will terminate the playback thread before deinitializing the RPC client - to avoid a RPC call with an invalid RPC client.

This is great, its impressive you were able to fix things so quickly. Thanks again haha
The problem with multiple calls to audsrv_adpcm_init while using FREESD (LIBSD) is fixed.

I was able to get PCM to play once along side ADPCM using the above method but calling it again stalled the console, highly likely due to the code I'm using as I don't think PCM is meant to be used that way but it was enough for a test.

I am curious, in the PS2SDK there is freesd.irx and libsd.irx I know recently freesd was renamed libsd so are these two irxs the same just alternate names? I'm using the freesd.irx currently.

 

[sp193]

There may still be some issues with the homebrew libsd module, but I removed the call to sceSdInit because that erased the block transfer callback, which prevented AUDSRV from updating PCM playback progress.

In the early days of the homebrew PS2SDK, people sometimes tried to avoid naming their copied modules after the Sony originals. Usually going as far as changing the names of the functions.
So the homebrew libsd module used to be called freesd.irx, until not too long ago. It was renamed to reflect its true name, but is sym-linked to freesd.irx for compatibility. On filesystems that do not support symbolic links (like FAT32), it may turn up as a duplicated file.

If you ran the sample code as it is, it might be causing further calls to AUDSRV functions to fail because it calls audsrv_quit().

 

[Krah]

<deleted post> spotted some things, I need to improve. Currently working on it.

 

[Krah]

As BGM is still a WIP and might take some time, I thought I'd put out another test if people are interest in seeing how far SFX has improved.

Thanks to @sp193 s updates to the PS2SDK we now have:

• run-time adjustable volume control
• run-time adjustable device control
• default sfx volume has all been equalized to around -17 lufs
• a bunch of additional sound calls

as always feedback is appreciated

 

[jolek]

It's fun thanks.
SFX are also fine.

 

[Krah]

Got BGM working alongside SFX, code still has a couple issues I need to try sort out but hopefully within a few days I'll have a bgm test build.

 

[TnA]

I haven't tried external sounds/SFX (or even BGM with the newest commit) yet!

Runtime-Volume-Control is working great! ~70% seems to be a good default volume btw.!

The errors with the numbers are still playing the normal sound, instead of 'error'... Yes, they look like the Exit to OSDSYS and PowerOff 'Warnings'!
Sorry that I forgot the video... :-/

 

[Krah]

All good thanks, was thinking of just adding the sound whenever one of those msgboxs pops up..Haven't come to a decision though.

Bgm issues are disabling/reenabling, sleeping the thread is fine but waking it up can result in a frozen console if calling audsrv_stop_audio before sleeping the thread but if leaving out that call the audio constantly stutters until bgm is reenabled..It's a bit weird, I'm still playing with it but the actual playing of the bgm without affecting fps of the GUI is working.

Bgm is also going to be external only, trying to come to a consensus on which bgm should be compiled in would be near impossible. Like @Berion said about GUIs and boot animations, it would need to be neutral and not a specific genre.. Probably easier to just leave it as external only IMO.

 

[Krah]

Ok so this is test 8, from my tests BGM is working fine..enabling/disabling I wasn't having any issues. I was streaming a 21Mb file so there shouldn't be a file size limit either.

Put your bgm.wav file in the normal SND folder Enable BGM in settings ..run-time adjustable volume should be all good for BGM also.
BGM is external only.

As always big thanks to @sp193 for all his help with the audio. Feedback / bug reports are appreciated

P.S. I am not claiming this to be merge ready yet, just another test

 

[jolek]

I've trouble with this new commit (0.8).
I've copied it onto my HDD, when I launch it through FHDB menu, it is freezing at PS2 logo:

Even "working" icon:

is not responding.


BTW I've to copy "bgm.wav" into "SND" folder on the Root Directory in the USB device?
E.g "mass:/SND/bgm.wav"?

 

[TnA]

I ran into the same problem as jolek... It freezes even faster, if no config is found (I unplugged the MC) which means it is a function which is usually called after it... I even had the BGM in mass:/SND/bgm.wav, but it didn't help...

I (then replugged the MC and) disabled the theme (Korium HD Beta v1) and BGM via Test7 and then Test8 worked...

However... The BGM I tried sounded like a slow playing vinyl...
Either the USB-Device is slow, or the WAV I used, has some wrong specs... (but it was ~100MB, so that size is certainly convincing that it should work with big files)

Unplugging the USB-Device leads to a replayed sample, instead of terminating the playback! Replaying the file (from the beginning) - once the USB-Stick is connected again, already works.



Edit: Well, I converted the WAV to 22.05Hz and the 47MB-file works well...


Sooo... Essentially it is

static int bgmFormat(void)
{
 int ret;
 struct audsrv_fmt_t bgm_fmt;
 bgm_fmt.bits = 16;
 bgm_fmt.freq = 22050;
 bgm_fmt.channels = 2;
 ret = audsrv_set_format(&bgm_fmt);
 if (ret != 0)
 {
 printf("Error setting audio format %d\n", ret);
 }
 return ret;
}

which needs to be changed, to derive the sample-rate, bitrate, channels, etc. directly from the Audio-file.


Edit.2: Btw.: Would you mind increasing the BGM-Transfer-Buffer a bit? It (current size) causes a sample to be replayed (like a 'stutter') during it loads art(s) for games... it could be the thread-priority, compared to another thread related to loading arts as well...