HomeForumsWhat's newResources 
 
 
Getting started with ponèSound
Neosquid - Jan 6, 2024
  Neosquid Jan 6, 2024
I was looking to do some simple audio experiments on the Saturn, and ponut's ponèSound library ...seemed like the right tool for the job. While I was impressed with what the demo projects had to offer, I encountered more difficulty than expected while trying to edit them for my own purposes, specifically while changing the audio file names on lines 71-73 of main.c in jo_demo:
C: 
  
pcm16snd = load_16bit_pcm((Sint8 *)"DEF_FLAG.PCM", 15360);
pcm8snd = load_8bit_pcm((Sint8 *)"HAV_FLAG.PCM", 15360);
adx4snd = load_adx((Sint8 *)"NBGM.ADX");
The demo program only seems to work if each file is named DEF_FLAG.PCM, HAV_FLAG.PCM, and NBGM.ADX; altering any of these names (even if the files being loaded are otherwise identical) causes the built program to refuse to play any audio at all, even if the rest of the files have their original names. Editing the files themselves (including creating a new PCM file and renaming it to one of the 'legal' names) works fine, to the best of my knowledhe.

I tried scouring the project folder for any other file(s) where these names were hardcoded in, but to no success. Running clean.bat before compiling yielded similarly few results, and inspecting the IDs of the load functions indicated no errors while loading them, which only confused me even more.

Given my inexperience with this library (along with Jo Engine and Saturn development in general), I apologize if the solution to this problem is actually quite obvious and I'm just unable to see it. That being said, please let me know if I need to provide any extra information about my machine or files that could clarify my situation further.

 Neosquid Jan 6, 2024
As it turns out, the solution was exactly as simple as I imagined—the library will only play files whose names are 8 characters or less long (not including the .PCM extension), and all of my test samples exceeded this length thanks to being some variation on "HAV_FLAG_.PCM". I humbly apologize for any time you may have wasted reading these posts.

I'm not sure if this restriction is endemic to the Saturn's architecture or a specific quirk of the library, but neither the Jo Engine nor ponèSound mentioned it in their documentation.

 nando Jan 6, 2024
This is a good topic - because I also was unable to get my samples to play. However, mine appeared to play "something", but it was just noise. I haven't tried to see if my file names are too long, but I'm pretty sure it's because my file conversion is wrong.

FYI jo-engine in general doesn't like files longer than about 8 characters - not documented anywhere that I know of, but it will be obvious if you test the limits. This doesn't apply to stuff you have to compile (.c or .h files), but does to files that have to be loaded from the disc when the game is running.

Anyway, if you got it working - can I ask what did you used to make your samples? I tried Audacity and the FFMPEG commands in the ponèSound examples, but it's not exactly the same and I never got anything but static/noise sounds. I kind of gave up and focused on other things. I understand a little bit about programming and can do basic graphics easy enough, but music/sound is basically alien to me..

@Ponut... ?

 SuperReye Jan 7, 2024
The file length is not just about jo engine, the functions SGL/SBL/yaul (jo is build on top of SGL) uses to handle files on disk only support 8.3 file format (meaning max 8 characters in name + dot + 3 characters in extension). So all files you put on the CD should follow this DOS convention.

Furthermore when using jo-engine or any other lib/sdk, try to no use folders on CD, switching folders takes a bit of time and would make your loading times longer. If you want to use folders tho, their names also must be at most 8 characters in length.

 Neosquid Jan 7, 2024

nando said:

The 'noise' you're hearing is because pS interprets all 16-bit PCM samples with big-endian byte order, while Audacity (for reasons unexplainable by modern science) can only export little-endian audio. If you're struggling with the ffmpeg commands, the only to reverse the bytes is to either write your own script that does it for you or import the exported PCM data as big-endian and reexport it again. That being said, 8-bit PCM shouldn't run into these issues, so it's a separate problem entirely if those are giving you trouble.

I also noticed that playback also doesn't work (with similar results to the filename issue) if the number of individual samples (regardless of those samples' bit depth) is too large - the limit seems to be around 25,000.


Since other people could also have questions about the engine, I'll change the thread topic to something slightly more general.

 nando Jan 7, 2024
I actually was originally trying to do an 8-bit sample. but also, Audacity doesn't support .wav to .pcm signed-8 bit, it only supports unsigned.

I didn't really need Audacity for anything other than recording my original sample, so now I'm using the ffmpeg command line options - basically these two from the jo_demo example:
C: 
  
    /*
    To convert a sound to 16-bit
    ffmpeg -i %this%.wav -f s16be -ac 1 -ar (bitrate) %this%.PCM
    To convert a sound to 8-bit
    ffmpeg -i %this%.wav -f s8 -ac 1 -ar (bitrate) %this%.PCM
    */

both worked and the PCM export appears to be valid, but I still get static (or the emulator crashes). I should try on real hardware next to be sure it's not just an emulation glitch, but the included samples in the demo play just fine.

EDIT: I actually got it to work. not sure why, but if I load both my sample and the pcm16 sample from the jo_demo example, it crashes. If I comment out the code for the pcm16 example, it works.

 SuperReye Jan 8, 2024

nando said:

hope this helps: SkyBlaster - ffmpeg wav to pcm 8bit...
command is:
C: 
  
\ffmpeg -i "mySound.WAV" -f s8 -ac 1 -ar 15360 "mySound.PCM"
to play the sound I use:
C: 
  
pcm_play(mySoundId, PCM_PROTECTED, 6);
The PCM_ macro ponut has is not descriptive of what it really does, so you can use these to better understand, the macro translates to some integer value, either positive or negative
C: 
  
/** @brief Sound effect will loop, playback direction will change when playback reaches its end
 */
AlternatingLoop = 3,

/** @brief Sound effect will play backwards in a loop
 */
ReversLoop = 2,

/** @brief Sound effect will play normaly in loop
 */
ForwardLoop = 1,

/** @brief Sound effect will play normaly
 */
Volatile = 0,

/** @brief Sound effect will play normaly, but when stopped, it wil not stop playing until its end
 */
Protected = -1,

/** @brief ADF format sound effect will play
 */
ADX = -3

  Neosquid Jan 18, 2024
Things have been going (relatively) swimmingly since my last post, but I've run into what appear to be memory issues long before I've exhausted the SCSP's RAM space. Adding enough additional variables to _PCM_CTRL's struct seems to cause pcmCtrlData (the _PCM_CTRL array) to bleed into the space used to decompress ADX audio, corrupting or outright disabling ADX playback altogether. Reducing PCM_CTRL_MAX rather predictably fixes the problem, but I'm simultanously worried that my later plans for the struct will render this fix unsustainable and confused as to why the problem occurs in the first place—neither main.c (in the PROJ folder) nor its linker script seem to specify any absolute positions for these variables, so the compiler should be able to correctly separate them.

As before, I'm still new to 68000-targeting C and linker scripts, so I'm sorry in advance if this is a trivial situation, and I'll be happy to provide my modified source code if it will be of assistance.

 SuperReye Jan 18, 2024

Neosquid said:

the ponesound c/h files are just a wrapper for the driver, if you want to edit the struct you would have to modify the driver it self as well

 Neosquid Jan 18, 2024

SuperReye said:

That's what I thought I was doing by editing the main.c file in the PROJ folder, since that's what builds sdrv.bin in the first place.

 Ponut Jan 18, 2024

Neosquid said:

Since you are editing the source code of the driver, you're venturing into territory where you are more and more dependent on the hardware manuals and your own ability to decipher my poorly written code.
However, I can help you in this case.

Look for the defined parameter called "DRV_SYS_END"
It is currently set to 47KB, which means the driver and its buffers consume 47KB.
If this variable is too low, the PCM_CTRL struct and the buffers will overrun into where the data is loaded, causing memory corruption and undefined behaviour.

So, to increase the size of any buffer, you must first increase the defined size of the driver and all of its buffers.
Line 71 of the driver's main.c
Now, PLEASE NOTE, the same variable exists in pcmsys.h
You, the progammer, must manually ensure that these are set to the same number.

As for changing the size of anything, you must also check for mirrors to structs in pcmsys.c/h and ensure that they are identical here and in the driver.

My other question is:
How are you running out of memory? How do you know you are running out of memory? How many sounds are you loading? How many are you trying to play simultaneously? What control type are you playing them by? Why are you loading that many sounds (just curious)? Are you loading a tone/sample bank? Soundfont?

 Neosquid Jan 19, 2024
Thanks for the help; I figured the solution would be right in front of me. Increasing the driver data size solved the problem handily.

To answer your other questions:


Ponut said:

Adding data to PCM_CTRL beyond (what I assume is) the memory threshold would corrupt sample playback, adding a 'fuzzy' sound to PCM and removing the low end from ADX audio; going even further beyond that would cause certain samples to not play entirely. This happened even if I never actually referenced the extra struct variables in the driver code, which is why I pegged memory issues as the culprit.

Ponut said:

I'm using just as many sounds as jo_demo did: three. The ADX sample is playing as a protected sound, the 8-bit sample is semi-protected, and the 16-bit sample is a small looping waveform.

 Ponut Jan 19, 2024

  
	
	

		
		

			I'm using just as many sounds as jo_demo did: three. The ADX sample is playing as a protected sound, the 8-bit sample is semi-protected, and the 16-bit sample is a small looping waveform.


Well, whatever. You said you were editing the driver. Not my problem anymore