PS2 OPL SND TEST

Status
Not open for further replies.
I'm for a PR, without boot-sounds (currently), once the little issue @Krah mentioned (when exiting HDL Server) is resolved. :)

...and I suppose the missing (code-)'lines' (check and reload/relink?) are really small/short.


Edit: @Rival93: It gets even worse, how slower the device is (i.e. USB), even if we use a kind of 'ls/list'...
 
Last edited:
Let's just wait until it's ready.

I don't see what the rush is to issue a pull request when the majority of people don't even use beta builds, they're still on 0.9.3.

In my opinion having a boot sound is one of the best things about SFX. The code for it is already there and working, it just needs tweaking.
 
IMO the boot-sound might need more work, than the new more flexible pathing... and there are a lot people using newer Betas, but oh well... I hope for an official 0.9.4-build in a not too distant future anyway, lol.

A 'rush' after 3 months and after I ever voted for a good stable implementation/base (on multiple occasions and regarding multiple structures), before anything gets merged?! That argument does not really hold up, because it is exactly the structural implementation of the boot-sound-support, which is not yet ready for a merge (IMO) and thus should be left out until it is ready.

The base just became good and any extended features could be added later anyway...

The reason I ask for it is, that the theme-creators could already start working on it, those themes in turn can encourage more users looking up the newer builds (especially those who are interested in sounds) and this in turn leads to more testers...
 
Last edited:
Yes it's been 3 months so what's another week or 2 until the boot sound and the hdl server bug are sorted out.

I would also like to see a 0.9.4 release in the near future.

There aren't a lot of theme creators around at the moment but I already started working on a sound pack for a theme. The thing is the 'main' theme related sound would be the boot sound.

By the time I have the pack ready hopefully SFX will be completed ;)
Even if they aren't we can still test.

Off topic but you might be interested to know I made an updated and HiRes conversion of Sav3r's Batman theme. Only thing is it needs the fade animation to be glitch free.
 
Well, I can wait but honestly there are ever some new features/things which could be implemented... (BGM, different GUI-Changes, per-game-BGM/SFX, etc.) and we will never have it merged once the structure becomes too complex while there are remaining bugs... That's why I rather suggest a merge of the current stuff and updates can be pushed to it later anyway.

It doesn't stop development, but could only contribute to it, IMO.
 
Per game BGM/SFX is not going to happen because it would introduce too many bugs. BGM is unrelated to SFX because it's PCM not ADPCM.

The last 2 issues to fix in the SFX branch are the timing of the boot sound and the hdl server bug caused by per theme SFX. Both of those issues are not related to the structure of the SFX code.

Once they are sorted out we will probably see a pull request for SFX if no other bugs are found.
 
Regarding per game sfx/BGM? Have you tried it? Which 'too many bugs' which according to you 'would get introduced', are you talking about?
A claim has to be verified, or it is just that... an unverified claim...
The fault might lie in your approach/structure for it?!

Is it the same game like 'per theme SFX is not going to be happening/implemented soon'?


Most important would be BGM-Support for a background-sound and that's mostly, what I care about. Per game-sfx would be possible as well (for example when someone is on the info-page and starts the game, etc.), but not that much important IMO.


I was NOT talking about the structure/implementation of SFX itself - obviously -, or I would not have suggested a merge and I already said, that this implementation is finally stable, which is WHY I suggested a PR/merge...
The boot-sound-implementation however is not!


Regarding the boot-sound-implementation...
First off... If the implementation is done in a different way these issues probably woundn't even occur in the first place...
Second... Why can't we just have the working stuff merged, instead of bloating it all up with new non-ready experimental and not bug-free features? '2bugs... if no others are found'... Yes... Indeed...

Multiple features potentiate the possibility of new bugs emerging (especially if these multiple features are also bug-ridden per feature at that time), especially if people want to 'have it all at once' and cram every stuff into a project, without even thinking about the implementation beforehand and how this implementation will affect the overall structure and how things could be implemented in an easy; while efficient; while non-redundant way in a relative short amount of time as well...

I am not a fan of putting it all into a PR at once...

I think we could have multiple merges/PRs:
  1. SFX-Merge (which includes the new pathing for per theme SFX)
  2. Boot-Sounds
  3. BGM-Support
  4. Per game BGM
...instead of cramming it all into one, which could also ensure that every merge works as intended. Give @El_Patas a break! :)
He's also not a fan of ultra-big commits, AFAIK.
 
Last edited:
I'm going to try and keep this short.

TnA said:
Is it the same game like 'per theme SFX is not going to be happening/implemented soon'?
Click to expand...
To be fair, it's not that it was ever stated to be impossible. It's that I didn't want to spend my time on it and the only reason I did is because you kept insisting! on it.

In regards to boot sounds, they are an adpcm SFX played on voice channel 0 so will be included in the SFX pull request when completed.

Please be patient, I don't like hearing that I'm taking too long to do things (in regards to the 3 months comments). If people aren't happy with the progression pace it's open source, make a fork and work on it yourselves.

Can we please keep this to bug reports related to the latest test build as I only put it up last night.

All the best.
 
Naw, you are not taking too long... You just have started a lot of projects and getting them all done is a bit much... That's even another reason, for merging the working stuff, lol.
In fact for all those stuff you began you are progressing quite fast.


Not impossible but 'not anytime soon' was essentially the premise...
I can look up the posts if you want to...


Btw.: I solely said that the more flexible pathing would be a dependency for 'per theme SFX' and 'per game BGM/SFX' and that it's easier to implement than the other stuff you are working on (like the ring-buffer and steaming for BGM) and you even have proven that this statements were correct! So I solely stated some facts ...and I talked about a structure which would work and could be implemented in a quite fast and easy fashion.

I did not insist on anything regarding implementing it (no force at all... to the contrary, I ever write this is a hobby...), but I had insisted that it is factually easier to implement than the other things and that the idea I posted ('more flexible pathing') is one of the easier approaches, which would work and that has been proven by yourself to be true, hehe... :)

On another note: Don't tell me you don't like the per-theme-SFX, especially for the amount of work which had to be put into it (of course still a bit but less and easier than other stuff, IMO) to work, compared to BGM and stuff!
You started out as a theme-guy/-creator/graphic-artist on OPL... I can't believe you (or your bro, lol) don't get excited about it and 'solely implemented it, because of my persistence' (but if you did, I've got to be more persistent once in a while, haha...)!:D


Regarding HDLsrv-bootsound-issue...
I am not yet sure what causes it (only skimmed the newest commit).

I suppose it reloads the internal SFX instead of the theme's SFX, due to the 'GUI' not 'noticing'or'knowing', that the theme's SFX have to be reloaded after terminating the HDL-server.
I can give a more qualified idea for a fix later.
 
Last edited:
Krah said:
@jolek
Sorry I didn't mean to sound like I was shooting down your suggestion, I will be looking into the LOGO display times related to SFX soon. I think yourlself, @sandungas & @Tupakaveli made some good suggestions related to that.
Click to expand...

It's not like that.

In short.
You wrote that currently there can't be no logo delay, because...
I wrote, let's do it another way...
Also others have other way to do it (delay)...
After few test, this suggestion is not working, or this suggestion can make trouble, is not needed...
Eventually this suggestion didn't make it in the repo.

No one is complaining, because mostly devs have final words, but...

It was fun to contribute\make feedback.

Thanks.

Best regards.
 
jolek said:
After few test, this suggestion is not working,
Click to expand...
Nah I hadn't actually tested yet, I was just thinking out loud. Did some tests last night, it's definitely possible just want to tinker with it a little more when I get some time.

None of my previous post was directed at you and perhaps I'm mistaking others enthusiasm for impatience idk...I just don't want to make a PR before things have been properly tested. If I make a PR and it gets merged and then a bunch of issues pop up on GitHub it's going to be harder and harder to get the powers that be to accept my PRs.

Until v1.0 hdl svr had been broken by SFX but I was unaware of it, yet a suggestion for a PR several times before then had already been requested.

It should only be a day or two from now to get the delay timing right depending on how much time I get to myself so provided no other bugs are found there should be a PR coming within a few days.

Thanks guys.
 
Just a suggestion from an "external observer", at this point (after krah decided the coldboot sound is going to be included in his commit), it seems you are at the point where is needed to make a list with the critical factors that are causing that bug in the coldboot sound sequence, tupakaveli mentioned a few in this post... but this was not intended as an accurate list, it was mostly his first impressions
Tupakaveli said:
I think the amount of time the logo is displayed for varies depending on whether you have a device set to automatically start, what device it is and also the size.

E.g. When I boot OPL with my 2Tb main internal HDD the logo is displayed for longer than when I boot it with my 40Gb test internal HDD.

EDIT: Well I tested it and it scans the device for games before the modules are loaded and the sound is played so it should always play it at the same point before the logo fades.

2 sec delay should do the trick.
Click to expand...
The common thing in my suggestions was to use a delay with variable lenght, first i said to allow the user to change that delay (bad idea probably), next i suggested to automatize that calculation based in a timer function meassuring the boot times (meh), but now i think the solution is to use a formula that include the critical factors

In short... it seems the number of games is a critical factor, right ?, and it seems OPL is scanning the games at boot time
So you can calculate the delay time based on the number of games, lets say... for every 10 games you can add 200 miliseconds to the delay, some examples
9 games = delay of 0 seconds
10 games = delay of 0.2 seconds
200 games = delay of 1 seconds
220 games = delay of 1.4 seconds
400 games = delay of 2 seconds
and so on...

Also, it at some point you realize there are other critical factors (such device capacity, or weight of images)... then you can add this to the formula that calculates the delay lenght
 
Last edited:
sandungas said:
In short... it seems the number of games is a critical factor, right ?
Click to expand...
Originally I thought this was the case but no I was incorrect, it seems the boot sound is the same across the board regardless of number of games or boot device (I only have 5 games @Tupakaveli has 200+ yet it's the same on both consoles) so really that just makes things simpler :)

All that needed to be done was add a short delay to keep the logo displayed, currently 1100ms works fine for the default sound.

Question is, should that time be customizable to support varying length boot sounds? And then I guess, am I going to be able to do that in an efficient way, if the user needs to scroll through one millisecond at a time to increase or decrease the delay...That would be a hassle for them :-p
 
Hmm, but then which are the critical factors ?.... the PS2 model/chasis ?, in that case maybe could be added some functions from PSident to know the PS2 model at the first boot (only one time), then store it in the config... and calculate the delays based on it

Anyway... the reason why i been insisting (a bit, lol) in using a variable lenght is because it will be nice, is like if OPL was autoadjusting itself (or like a training), and the delay times "should" be optimal

About allowing the user to configure the delay manually... i think should not be needed (incase what i was saying works at some point)

But i think adding a setting to disable the coldboot sound is something good to add
I know, if someone wants to use all the other SFX sounds but not coldboot... the only thing they have to do is delete coldboot sound file
But the poblem is people that is going to publish OPL themes probably are going to include all sounds... so in the first test of the theme the coldboot sound will be there, and some of them could not be aware of that, also the need to delete/rename the coldboot file with a filemanager is a bit pita
 
Last edited:
Why should we be concerned about how long the hardware takes? It is a bad idea to assume that the hardware will surely take a certain amount of time to become ready, as the parts installed may be different, part wear may cause mechanisms to take longer to become ready etc.

If there is interest in cueing the end of bootup (i.e. sound fade out), you can get the end of initialization event signalled (with a flag, semaphore etc) from the GUI_INIT_DONE event of guiHandleOp() of gui.c. This event is issued by the deferredInit() function of opl.c, which will execute after all initialization is done because it will be queued after all the initialization requests.
 
There seems to be a little confusion as to how the boot sound is playing (due to me not explaining it very well), I'll try clear that up. I may be off with some details but this is my understanding of it (please correct me if I'm wrong some where).

ok so the init process for OPL is like sp193 said earlier.
sp193 said:
It's all done within opl.c:
  1. main()
  2. init()
  3. _loadConfig()
  4. applyConfig()
  5. initAllSupport()
  6. initSupport()
Click to expand...
the audio lib and sfx are all being loaded after _loadConfig() (it cannot be done any earlier otherwise we won't get the theme path from the config), in order to keep things simple I've got the boot sound playing as soon as possible (directly after audio lib is init and sfx are loaded).

Once the call to playback the boot sound has been made the other processes continue to run, all the heavy lifting up to this point seems to have already been done so the LOGO begins to fade into main very quickly after the call to playback the boot sound.

Since the LOGO isn't staying up very long for the boot sound to be played (because the call is after everything else has been loaded) @jolek suggested extending the LOGO time if SFX enabled to help sync the fade to main better, I just finished making it an option so the fade delay can be adjusted accordingly depending on the length of the themes boot sound..value is in deci-seconds so increments of 100ms essentially.
 
Ok this should be the FINAL test version for SFX (I know I've said that a few times but I'm pretty confident there are no bugs this time) :-p

Changes since last update:
  • added option to disable boot sound (as suggested by @sandungas )
  • added boot sound volume control (as suggested by @TnA)
  • added fade delay to the logo at init if boot sound & sfx enabled (as suggested by @jolek & @Tupakaveli)
  • added option to make the fade delay customizable (defaults to 12 for default theme boot sound 12 = 1.2 seconds) maximum of 50 ie 5 seconds which is HEAPS of time.
NOTE 1: when using the fade delay busy icons are not drawn to avoid the appearance of a 'stalled' console.

NOTE 2 : upon exiting hdl server and returning to the GUI, OPL reverts to the default theme in order to avoid the custom theme/sfx bug (literally takes about 10 seconds to turn your custom theme back on if you so choose).

Thanks to:
dekkit, jolek, NewFile, RivalK93, sandungas, svotib, sp193, TnA, Tupkaveli, VeditaBR.
For your support.
 

Attachments

Last edited:
As requested, here is an archive containing some code for streaming in the background: https://www.sendspace.com/file/ij9snr

Krah said:
Since the LOGO isn't staying up very long for the boot sound to be played (because the call is after everything else has been loaded) @jolek suggested extending the LOGO time if SFX enabled to help sync the fade to main better, I just finished making it an option so the fade delay can be adjusted accordingly depending on the length of the themes boot sound..value is in deci-seconds so increments of 100ms essentially.
Click to expand...

Ah okay, that makes sense now. I might have written a reply for some older comments, since I was telling myself to do it... and it might have been done too late.

The Sony opening themes are also like that. There is a fixed animation length, which gets lengthened if the console takes longer to get ready.
 
Last edited:
Status
Not open for further replies.

Similar threads

Back
Top