wololo.net/talk

Posted: **Wed May 16, 2012 7:54 am**

I just read on the blog that R150 contains a fix for audio playing and that it involves hooking non-blocking audio functions with blocking ones.

This really makes me wonder if the implementation of the PSP audio API is not just bugged regarding blocking functions and that this might actually cause some trouble for homebrew. Blocking audio functions should only return after the audio has completely finished playing, not immediately. But this seems to happen on the Vita from the description. Of course this invalidates the whole point about the blocking functions.

Does anyone have more insight on this?

Posted: **Wed May 16, 2012 10:07 pm**

There was clearly a performance impact when doing this hook on the PSP.
I didn't see this impact on the vita (I can make a video one of these days). I initially assumed that this was because the vita hardware was better, but you're right, it doesn't make sense since it doesn't depend on the hardware but the length of the sound.

Are you sure that blocking means "return once the sound has been played? it could be "return once at least one sample has been played" ?

Posted: **Thu May 17, 2012 5:56 am**

I am very sure. This is the relevant playback function from PSPdisp:

Code: Select all

void audioPlaybackThread(SceSize args, void *argp)
{
  l_lastPlaybackPosition = 0;

  while (l_runAudioThread)
  { 
    // Check if the playing position advanced over the filling position, mute sound if so
    if ((l_lastPlaybackPosition <= g_comAudioWritePosition) && (g_audioPlaybackPosition >= g_comAudioWritePosition))
      audioResetPlaybackBuffer();

    if (g_audioPlaybackPosition + (g_audioCurrentFrameSize * 2) > g_audioCurrentBufferSize)
      g_audioPlaybackPosition = 0;

    sceAudioSRCOutputBlocking(PSP_AUDIO_VOLUME_MAX, &(g_comAudioReceiveBuffer[g_audioPlaybackPosition]));

    l_lastPlaybackPosition = g_audioPlaybackPosition;
    g_audioPlaybackPosition += (g_audioCurrentFrameSize * 2);
  }
}

The thread depends on the blocking behaviour. If it wouldn't block until the whole buffer is played, it should stutter horribly.

Edit: Okay, to be absolutely sure I measured the amount of ticks the function takes before returning. The result was

Code: Select all

~200000 for 11 kHz with 2240 samples
~100000 for 22 kHz with 2240 samples
~60000 for 44 kHz with 2688 samples

q.e.d.

wololo.net/talk

Hooking sceAudioOutput with sceAudioOutputblocking?

Hooking sceAudioOutput with sceAudioOutputblocking?

Re: Hooking sceAudioOutput with sceAudioOutputblocking?

Re: Hooking sceAudioOutput with sceAudioOutputblocking?