u235 random missing samples

[Sporadic]

Hi, long time, no bug!

 

I recently tried swapping back to the u235 sound engine (from zeros player) as i'm considering using MODs instead of uLaw for music due to space constraints etc.

 

I've found when playing samples using u235 it tends to only play about 1 in 4 of them, the rest are just not played. This is in VJ and on actual hardware.

 

Thinking it might have been my code, i ran the Doger example and the same occurs, the death sound only plays occasionally.

 

I've also noticed that it wont play anything unless you specifically call SNDPLAY with a SNDFREQ directly after it.

eg.

SNDPLAY(1,5)

SNDFREQ(5,11025)

Is the non-playing sound likely to be an rB+ issue? I would have thought if the problem lay in u235 itself then someone would have mentioned it by now. Any help/pointers appreciated!

Thanks

Is this likely to be an rB+ issue? Any help/pointers appreciated.

[ggn]

Hi,

 

I had a quick look at commit logs, from what I can see the last time the u235 object file was changed was 16th of March 2015, and the most recent changes to the code that calls the audio code around February 2015. Time files, does it not?!

 

I do remember having all sorts of weirdness with sound fx missing. I remember sh3 telling me that he used to fire each sample twice so as to be sure it'd actually play. So that's certainly an option. Your sndplay/sndfreq might be the same thing as sh3 does - basically the audio code needs to be prodded twice due to some timing issues? Also if you check nyandodge project I also do some utter weird things with audio (just don't look at the mod playing, that was the best I could come up with to switch between modules).

 

Finally the only thing I could think of that could probably possibly might affect sample playing was my turning on gcc optimisations so more optimal basic code would be generated. If you would like to test this out, you just need to change -O2 to -O0 in build.bat in the two instances around this point: https://github.com/ggnkua/bcx-basic-Jaguar/blob/master/build.bat#L183

 

That's pretty much all I can do with a closed source library, sorry. I couldn't get any answers back then and in any case it's too complex of an issue to lay it to other people as there are many points of failure here, i.e. basic->c->assembly, interface with library running on Jerry which I'd have to disassemble. How do you even start to debug this?

Edited October 23, 2018 by ggn

[Sporadic]

Ok, thanks for the feedback. I'lI have a play with the above suggestions.

 

I agree it's certainly not the most straightforward thing to debug

[LinkoVitch]

I have never looked at the RB+ side of things. GGN, I am wondering if perhaps the SNDPLAY call is generating a command list with a single play instruction on it, that is then passed to the SE for processing? If so, then perhaps if there are multiple sounds played in a quick enough succession they may be overwriting the previous command before it is processed or sent?

 

When I initially created the SE, I was imagining a list of commands being generated covering all banks and those being sent for processing as a job lot, rather than individual sounds. Perhaps there is some requirement for a non-list approach for triggering sounds in the engine? For the current releases though, is there any way to build a list and send it over perhaps with a 2nd command? perhaps a SNDPLAY_DELAYED(arg, arg) and then a SNDSEND() type of arrangement?

 

Might be nice if it is possible to build a raw list and send it? So if new features are added, etc, RB+ user could build a custom list and issue an RB+ command to point that list at the SE? (or is that possible with some poke like actions?

[+CyranoJ]

The way do to it is to have SNDplay add to a list, then in the VBI interrupt process and reset the pointer.

[ggn]

I have never looked at the RB+ side of things. GGN, I am wondering if perhaps the SNDPLAY call is generating a command list with a single play instruction on it, that is then passed to the SE for processing? If so, then perhaps if there are multiple sounds played in a quick enough succession they may be overwriting the previous command before it is processed or sent?

 

When I initially created the SE, I was imagining a list of commands being generated covering all banks and those being sent for processing as a job lot, rather than individual sounds. Perhaps there is some requirement for a non-list approach for triggering sounds in the engine? For the current releases though, is there any way to build a list and send it over perhaps with a 2nd command? perhaps a SNDPLAY_DELAYED(arg, arg) and then a SNDSEND() type of arrangement?

 

Might be nice if it is possible to build a raw list and send it? So if new features are added, etc, RB+ user could build a custom list and issue an RB+ command to point that list at the SE? (or is that possible with some poke like actions?

Here's the code for sndplay - basically it can get called any time as the programmer has no notion of time besides 50/60Hz ticks.

 

Maybe we could issue a good engineering practice to execute only one SE command per vertical blank?

[LinkoVitch]

Here's the code for sndplay - basically it can get called any time as the programmer has no notion of time besides 50/60Hz ticks.

 

Maybe we could issue a good engineering practice to execute only one SE command per vertical blank?

 

If RB+ adds all SNDxxxxx's to a list, and then at the start of VBI if a list exists, caps it off and fires it at the SE I imagine that would work perfectly. Better than staggering individual calls (which could introduce unwanted echo effects as the sample playback would start at different times).

 

Leaving it to the game programmer to only fire off one effect per tick would work but would also be a bit naff, EG you want to have a shot effect from both Left and right channels, You do left in tick one, right in tick 2, on systems with mono output you would essentially create a reverb/echo effect of 16-20ms for the sample. Plus added complexity or time loss for the game loop, waiting a whole tick just to fire off another command.

[ggn]

If RB+ adds all SNDxxxxx's to a list, and then at the start of VBI if a list exists, caps it off and fires it at the SE I imagine that would work perfectly. Better than staggering individual calls (which could introduce unwanted echo effects as the sample playback would start at different times).

 

Leaving it to the game programmer to only fire off one effect per tick would work but would also be a bit naff, EG you want to have a shot effect from both Left and right channels, You do left in tick one, right in tick 2, on systems with mono output you would essentially create a reverb/echo effect of 16-20ms for the sample. Plus added complexity or time loss for the game loop, waiting a whole tick just to fire off another command.

PRs welcome! (not keen on hacking on this TBH!)

Edited October 24, 2018 by ggn

[LinkoVitch]

When I get a free moment I might have a poke see if I can add something workable.