JTTL's Audio Plugin Work

[nmn]

I'm trying to do some work with JTTL's Audio Plugin. However I'm having some issues. So far in SVN I have some new features and fixes for it. An option for what resampler your using (None, Linear) and a new resampler option (libsamplerate Best Quality SINC). The new resampler is causing the problems. It seems to work, but I think its writing too much data and going past the allocated buffer. I tried cutting down how much it writes in various ways but it just makes it constantly skip (I'm guessing its half audio half nothing, would that be considered a buffer underrun?) and the other method it seems to be writing out of place because as soon as it underruns for the first time SDL's state seems to be messed up (Exiting after that point causes issues.)

So anyways, Anyone lend a hand? I've never used libsamplerate before, I had some issues at first but now the only serious issue is the memory one.

Besides this issue, kind of OT I guess, The default frequency seems to be wrong. Not the value itself but the fact that it seems to be used when it shouldn't be. For example, I think "The Corporation first intro by i_savant" is meant to play at 44100, but it ends up going to the default. This is a serious problem because other things have this issue also ("Eurasia Intro by STE" and other demos) Understood that its not aimed to get demos working properly, But I think that if we find out the issues with these it will fix some outstanding audio issues. Honestly I'm not sure where the problem is (Could be in the RSP code, I guess)

Even more so, the audio can get really skippy and I think the issue is not related to the power available ("Eurasia Intro by STE" is extremely skippy after a few moments in, but graphics play fine and the CPU usage never goes close to 50%). Any pointers on this issue? I've looked, but I've failed to find any reasons why.

I guess for now I'll work on something else, but all of the above are still issues that need to be fixed. If anyone knows anything, please post.

 

[Richard42]

Which API are you using? It appears to have 3. I presume that you understand that the input and output buffer sizes will be different as a function of the resampling operation. For example, if you are resampling from 22k to 44k and your input buffer is 4k samples, your output buffer will be 8k samples. But if you're going from 16k to 44k and your input buffer is 4k samples, then your output buffer will be 11k samples.

 

[nmn]

The Full API. I actually mixed them up and thought i was using the Simple API which would be impossible ... Yes, I do understand. It doesn't matter how many output frames I give it as long as its converting properly, does it? I think right now I'm giving it the right amount of inputs and outputs.

You may want to take note that since Libsamplerate uses floats I must do two per-resample conversions from float->short and short->float. Yuck. (Makes me wonder if I should write a floating point audio plugin using a more full featured API than SDL_Audio, which IMHO is very low level. Maybe just a tad too low level for me...)

 

[ebenblues]

Thanks for the work you're doing on the audio plugin. I updated my working copy, tried to build and it died because I don't have libsamplerate:

$ make all
Package samplerate was not found in the pkg-config search path.
Perhaps you should add the directory containing `samplerate.pc'
to the PKG_CONFIG_PATH environment variable
No package 'samplerate' found
pre.mk:62: *** No libsamplerate development libraries found!.  Stop.

I commented out the line in pre.mk that throws the error and it compiled fine. Since it compiles without libsamplerate, do we really need to throw an error or would a warning suffice? Also, it would help if the warning message explained what impact not having libsamplerate has on the plugin.

 

[nmn]

Well, The main thing is one condition in the resample function - Resampler == 2. That 's where it does all of its actual work. In addition some variables. Everything needed by libsamplerate is in ifdefs, about 3 or 4 sections.

I did not mean to throw out an error, I must have picked it up from the GTK pre.mk code. I just copied it, after all (dumb >_<)

 

[nmn]

*Bump*

Just posting to let you all know that skippiness in general has been resolved with any audio plugin - The problem was with Mupen64Plus's Speed Limiter, which stopped the audio plugin from speeding up the emulator even when it was necessary. To resolve this problem, I've added a new option to the emulation menu which should default to 'true'. If you swap it off, you will that it syncs to the audio plugin and only the audio plugin (as long as your not using Vsync in your video plugin.) You may notice the video speed up on occasions, but as long as you have enough CPU and graphics power, you'll also notice the sound is correct Never hits underflow in my limitted testing. If you think that the video plugin is limiting your speed after disabling 'Limit FPS', you can give the new 'No Video' plugin a go just to make sure.

Note that disabling this option is only necessary for a limited amount of things. However, I have to wonder if its ever necessary to limit speed from the emulator itself...

 

[okaygo]

*Bump*

Just posting to let you all know that skippiness in general has been resolved with any audio plugin - The problem was with Mupen64Plus's Speed Limiter, which stopped the audio plugin from speeding up the emulator even when it was necessary. To resolve this problem, I've added a new option to the emulation menu which should default to 'true'. If you swap it off, you will that it syncs to the audio plugin and only the audio plugin (as long as your not using Vsync in your video plugin.) You may notice the video speed up on occasions, but as long as you have enough CPU and graphics power, you'll also notice the sound is correct Never hits underflow in my limitted testing. If you think that the video plugin is limiting your speed after disabling 'Limit FPS', you can give the new 'No Video' plugin a go just to make sure.

Note that disabling this option is only necessary for a limited amount of things. However, I have to wonder if its ever necessary to limit speed from the emulator itself...

What exactly did you change, I didn't get to look at the SVN, but did you change something directly with the new_vi() function? Or was it something with the interrupts.

Edit: I read the code, I think we should make it so that audio sync is an option within the sound plugin. If we disable audio sync, we might be able to have an easier time with our fast forward features.

 

[nmn]

Hmm, I figured new_vi() was the only place TO change it, I looked around and didn't see anything else (granted it was a limited search)

 

[okaygo]

nmn, can you get on AIM. :3

 

[nmn]

I am now on AIM.

For anyone who did not notice I post this stuff on my profile...
AIM: notmyname06
MSN nmnnotmyname (at) gmail.com