You can also duplicate the play.module crash by selecting an iff soundfile in a lister and selecting a button or user menu that calls the "Play" command. I tested with WAV files and the crash doesn't occur. The play.module uses "audio.device" to play IFF sound files and Datatypes for other types of sound files. If the file isn't recognized as IFF or a Datatype then play.module plays it through audio.device as an 8 bit raw file at a default sample rate.
We can fix the crash by commenting out the audio.device sound play. All Amigas should have an 8svx and aiff datatype so they can still play those sound types if we disable audio.device sound playing. RAW files are 8 bit soundfiles that have no header info and can only be played at a default samplerate. RAW files were created by some early Amiga 8 bit sound samplers and are mostly 20+ years old. Not supporting RAW files is no big loss.
I'm going to disable (comment out) audio.device sound play in the play.module. If anyone wants to retain audio.device sound play for AROS or MOS please speak up. In that case we can use #ifdefs to allow audio.device sound play for specific platforms.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Xenic
Is commenting out audio.device related code fix those crashes with "next" and "abort" too ? I just tried before 2 files: both 8svx ones, just in one directory, and once i just load one of them, press "test", and do "abort" or "next" => have a crash. Is it because they plays via audio.device, but not via datatypes by default ?
Anyway, if commenting it out it fix issues, then of course commit it plz, one bug less ;)
Last edit: kas1e 2013-08-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is commenting out audio.device related code fix those crashes with "next" and "abort" too ? I just tried before 2 files: both 8svx ones, just in one directory, and once i just load one of them, press "test", and do "abort" or "next" => have a crash. Is it because they plays via audio.device, but not via datatypes by default ?
Commenting out the audio.device play seems to fix the "next and abort" crashes in OS3 & OS4 binaries. The play.module checks if files are IFF (8svx) and plays them through audio.device if they are IFF. If they're not IFF then it trys to play them with datatypes. I've just commented out parts that check for IFF so the module will play all sound files with datatypes. As soon as I test with the latest repository checkout, I'll commit my changes. The changes are in a single file (play.c) and can easily be changed back by removing the commenting. After thorough testing we can just remove the audio.device code and greatly simplify the play module.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Xenic
I do check our latest code of everyting (rev 533 at moment), and when i run everything in os4-native form, then go to environment, choice for sound system:prefs/presets/sounds/a1000.aiff, and while it playing hit emmidiately "abort", then i have crashed task called "Sound_ObjectHandler". Stack trace are sad one, and looks like this:
Through it seems minor crash, because "Ignore DSI" help, and i can load it again.
The same it crashes if i press "Next" while it plaing (with the same crashlog).
Also there is another new error: If i just (after hard reboot of course) go to enviroments, and again the same choice for sound , let's say "a1000.aiff", and press "test", it plays fine, but window with those buttons "Next and Abort" , never disappear and stays on screen. If i press "Next", then instead of plaing next sound in directory, it just close window. The same if i press on "abort" after sound is stops.
So i reopen ticket again and add all the new info there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
I can't reproduce your new crash on my X1000. No matter how fast I try to hit the Abort or Next button after the sound play starts, I don't get any crash. The play.module appears to be working correctly to me. What PPC Amiga are you testing with (X1000, SAM etc.)??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@xenic
i am on pegasos2 with onboard sound, debug kernel. will try to rest it more deeplt. btw, what happen for you when you press "next" button ? on os4 and mos it seems do nothing, while by logic it should abort previus play and star next one in dirrectory ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i am on pegasos2 with onboard sound, debug kernel. will try to rest it more deeplt. btw, what happen for you when you press "next" button ? on os4 and mos it seems do nothing, while by logic it should abort previus play and star next one in dirrectory ?
If you are testing sound play from "Settings/Environment/Sound Events", you can only select one sound file in the in the ASL requester that pops up when you select the "file select" button below the list of sound events. There can only be one sound file for each event in the list. There is no next file so clicking next just aborts the sound play.
If you test sound play by adding a "Play" button, you can select multiple sound files in a Dopus5 lister, click the Play button and clicking "Next" in the Play window will abort the current sound and start playing the next file. It is working correctly with OS4 binary and OS3 binary on my X1000.
It sounds to me like your crash may be a datatype problem or Pegasos sound play software issue. Are you using the default datatypes that come with OS4?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha, now i understand "Next" button. Just when its present when it called from Settings/Environment/Sounds Events, there is no reasons to have "Next" button at all, as there only "Abort" possible. Can we make it like this : when only one file in choice, only "abort" button in the middle of window, when more than 1 file is choicen, then Next/Play. That will be logical and understandable imho for everyone.
It sounds to me like your crash may be a datatype problem or Pegasos sound play software issue. Are you using the default datatypes that come with OS4?
Yes, i use default datatypes, and to say truth i never-ever have any issues on peg2 in terms of sound play. All the music apps which i use and try in last 3-4 years never cause any problems. Why you didn't have problems on x1000 : dunno, but maybe because you didn't use debug.kernel/munge/memguard for catch all the bugs ?
But now interesting stuff coming, i assume i found roots:
For the sake of tests, that what i do now , on original play.module (i.e. before your commented out parts):
use debug.kernel with "munge" option enabled, hard reboot
run dopus5
go to the System:Prefs/Presets/Sounds in the lister
There i have 4 files: A1000.aiff, Bells, Wind_1 and Wind_2.
I mark them all by mouse
I press "play" button in buttons bank.
All 4 sounds plays well, and exit.
So till that moment all ok.
Now, i again just select all those 4 files, press "play" and hit "Abort" button right after first sound starts to play. And have a crash:
DAR again point out on CCCCCCD0 , which mean that "munge" of debug.kernel works, and catch a bug. Ignore DSI cause a lot of :
Task 0x65A7BA40 (dopus_detached_player) bad access @ 0xCCCCCCD0, pc = 0x01820C14, lr = 0x01820D14,
Task 0x65A7BA40 (dopus_detached_player) bad access @ 0xCCCCCCCC, pc = 0x01820BF8, lr = 0x01820D14,
Task 0x65A7BA40 (dopus_detached_player) bad access @ 0xCCCCCCD0, pc = 0x01820C0C, lr = 0x01820D14,
And so on errors.
What mean its cleary bug was there. And exactly in the play_cleanup() function (which runs when we hit Abort or Next), but you can not notice actual crashlog because wasn't on debug.kernel/munge. And that play.c:907 line was : while ((msg=GetMsg(data->audio_port)));
So pretty possible that we only need to fix that part, and we even can keep previous "raw" play back (because iffs also plays ok after i comment out problematic part).
If we check the same previous version of play.module (i.e. the same one where you didn't do changes), on the usual user kernel (and without munge of course), it crashes differently, and point out on different, what can make you think that problem was in different place and go all of us by wrong way. I.e. it was:
Stack trace:
(0x6447CCD0) 0x6447CBEC [cannot decode symbol]
(0x6447CD00) 0x6447CBEC [cannot decode symbol]
(0x6447CD40) [init/aos4_ppc_libstub.c:16] libstub_L_Module_Entry()+0x28 (section 1 @ 0x39DC)
(0x6447CD50) [misc_proc.c:997] misc_procPPC()+0x984 (section 1 @ 0x30534)
(0x6447CFE0) native kernel module kernel+0x0005de4c
(0x6447CFF8) 0x0000FFF8 [cannot decode symbol]
~~~~~~
Which is not show us full info, while debug.kernel are, and that was just some shorted stack-trace. But real one catches pretty well by the debug.kernel with munge and which in reality is just in "free" of messages.
I even found a "hack" way how to fix all the problems. Just get previous play.c (without your changes), and comment out:
// Close message port
if (data->audio_port)
{
if 0
struct Message *msg;
// Flush all messages
while ((msg=GetMsg(data->audio_port)));
DeleteMsgPort(data->audio_port);
data->audio_port=0;
endif
}
~~~~~~
And you have no more crashes, not with abort, not with next , all is fine, raw plays sounds fine, and all ok.
So..
Then, i build version with your changes. And the same going to directory, choice 4 files, and press play. At this moment, it play only A1000.aiff, and play nothing else. And window with "Next/Abort" stays all the time there. So i need to press on "Next" manually to mak next sound works.
And if i press Abort or Next while one of sounds plays, then i have new crash which i didn't have with previous version and about which i told (in Sound_ObjectHandler).
Also, to point out, "Lenght" stop calculated with your changed too. I.e. for all the files window show just "????" in lenght.
So i see there 3 moments in terms of your changes:
Files didn't plays now automatically, user need to hit "Next" to be able to play next file (while originally it was automatically).
Length start to show ????
That bug which you can't reproduce which happens when one want abort already playng music and which can be catched by debug.kernel only and that one need to fix without removing raw_play stuff, etc (which in general works fine on morphos btw before).
All of which mean, that we need to move back previous version of play.c , and just fix crash again, but now, with having in mind real roots (which we catch by debug.kernel).
Maybe also add some code which will just check: if one file in pipeline to play, then only in the middle one button "Abort", if more than one, then buttons Next/Abort as it now.
Hope now it clear all our problems :) Just one bug to fix in previous version of play.c , and maybe add some new bits of code. I dunno through why this while ((msg=GetMsg(data->audio_port))); cause "free node twice" crash, but i assume there should be something done on message after or before doing what it doing. If i remember right, messages should be replied before doing getmsg, so maybe that is problems.
Last edit: kas1e 2013-09-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
suggest the same : all messages should be replied. I think that should fix the stuff instead of commenting of block.
There are no messages to clean up for datatypes sound play. I overlooked the cleanup when I commented out the audio.device sound play. I've now commented out some more IFF stuff and set the audio port to NULL so the message cleanup will be skipped. Please test the attached OS4 play.module to see if it crashes and let me know the result.
As for your other concerns:
Continuous play only occurs with audio.device sound play of IFF files because the raw audio data is extracted from the IFF audio files with IFFParse library and continuously copied into buffers for audio.device. Datatype sound play works the same as it did with original SASC Dopus5.
The sound length is calculated from the data length and play speed contained in the IFF file. That play.module datatype play doesn't calculate a length, which is why you see the ??? for length. I don't know if that's even possible with some sound formats that datatypes can play.
There are no messages to clean up for datatypes sound play. I overlooked the cleanup when I commented out the audio.device sound play.
I mean original play.c (without your changes, when not only datatypes but when also audio.device play have place). That one crashes on cleanup of things even before your changes.
Please test the attached OS4 play.module to see if it crashes and let me know the result.
Didn't crashes now, but sometime just skip the "next" sound and play nothing. I.e. if i choice those 4 files in the prefs/presets/sounds, press button "play" , and then hit "next" while any of modules plays, then next one in 50% of time just didn't plays and only silence here. Some time even 2 files in row didn't plays. But no crashes.
Anyway, i just build my own play.module, which are pure original , just with commented out "close message port" block: all works fine, length shows ok, no crashes at all, no "skips" when hit "next", etc.
Just check attach. If it will works for you without problems , then imho better use that one (just need to make correct cleanup or the same " set the audio port to NULL so the message cleanup will be skipped" as you do).
At least in that case it works as expected, "Next" works always, length shows, and i have no single crash with.
Just check attach. If it will works for you without problems , then imho better use that one (just need to make correct cleanup or the same " set the audio port to NULL so the message cleanup will be skipped" as you do).
Don't set the audio port to NULL if you are keeping the audio.device sound play. The port is used by the IFF sound play through audio.device. The only time the audio port should be NULL is if ONLY datatypes sound play is being used. Also, I don't think we need to eliminate the entire audio port cleanup. The message cleanup seems to be causing the crash. That could be because the "DoIo()" exec function is documented as cleaning up the messages. I don't know for sure because my system freezes and I can't access debug output.
I don't know why the datatype ONLY sound play works perfect on my X1000 but has skipping problems on your system. I don't like the IFF audio.device sound play because it violates the SDK documention. Read the DoIo() documentation in SDK:Documentation/AutoDocs/exec.doc. It specifically states that DoIo() should not be used with audio.device. A similar warning also exists in the official OS3 developer documentation. DoIo() is probably used in the play module because it is a simple way to allow for aborting sound play and didn't cause a crash on OS3.
If you insist on keeping the IFF audio.device sound play then I suggest we only comment out the message cleanup like this:
// while ((msg=GetMsg(data->audio_port)));
I've cleaned up and improved the datatypes ONLY sound.module and it's working perfect on my X1000. Please test the play.module and sound files included in the attached archive. I have no problem skipping sounds with my new play.module.
I've cleaned up and improved the datatypes ONLY sound.module and it's working perfect on my X1000. Please test the play.module and sound files included in the attached archive. I have no problem skipping sounds with my new play.module.
Yes, now all works fine !
More of it , its just show correct "legth" , and play files automatically when i choice more than one. I.e. everything as it should ! All your samples also plays well , as well as all the samples in the prefs:presets/sounds. "Next" button also works fine , as well as "Abort".
How did you fix that "length" problem ? And how you make that all files now plays without stop and no need to hit "next" after each one ?:)
Anyway, that version works very well and all is fine. Only if it can be possible to detect now if we have 1 sound to play, or more than one, and if it more than one then show window as it now, but if it only 1 file to play, then show no "next" button, but just "abort" in the middle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How did you fix that "length" problem ? And how you make that all files now plays without stop and no need to hit "next" after each one ?:)
By programming it to work the way we want. Just read the code when I commit it to the repository.
Anyway, that version works very well and all is fine. Only if it can be possible to detect now if we have 1 sound to play, or more than one, and if it more than one then show window as it now, but if it only 1 file to play, then show no "next" button, but just "abort" in the middle.
O.K. Try the attached OS4 play.module that works like you described. The window display objects (including buttons) are pre-defined in play_data.c. I took a shortcut and just duplicated the object list without the "Next" button and centered the "Abort" button. There is probably a way to get the same results without duplicating the entire object list but I'll leave that to someone else. I'm not to good with object oriented programming but someone like Trixie might know a better way.
In addition to stripping out the IFF audio.device sound play code, I also removed the inovamusic.library MOD playing. Since inovamusic.library is not public domain software or opensource, I don't think there is any way to create an "Interface" file for OS4 and it might not even work right on all of the Amiga platforms dopus5 will support. As far as I know, only people who actually purchased dopus5 or an Inovamusic product are legally entitled to use it. The old-time OS3 Magellan users may not like the inovamusic.library MOD playing removal but I don't think we can support it on all platforms. At some later date we might find an opensource or public domain MOD library that can be added. Users can also assign Dopus5 buttons to use one of the many MOD players that already exist.
Test the attached play.module to see if it works on your system. I still need to clean out some IFF stuff before I commit my changes.
EDIT: The inovamusic.library code is very small; it just opens the library and sends it a file to play and waits for finish or abort. If you want I can add that code back for OS3 (#ifdef __amigaos3__) because it might still work on a classic Amiga.
@Xenic
Checked, everything fine. Let's commit it !
As for inovamusic.library, i already write mail to Olaf, maybe Greg will give us source of it as well, so we can port it everywhere. But in meantime maybe all the "inovamusic.library" code should indeed go via ifdef amigaos4. That also include Library/filetype.c file, as one of os4 testers have crashes as he have it by some reasons intalled in LIBS:.
So while code will be there , it all still will works only for os3, but when (and if) we will have source, we can uncomment ready to use part.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
O.K. I'll add the inovamusic.library MODULE play code back into OS3 and commit the code as soon as possible. As I mentioned in the version topic, I'll also be commiting new versioning files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@xenic
Tested our latest on moment svn (624) : everything fine in terms of play.module, versions fine, all work as need it. So i close ticket for sure now , thanks !
EDIT: btw, i only think that inovamusic.library in play.module should be also not only for os3, but for morphos (where 68k libs works without external ppc-glue-stubs). Like i do in commit #625 for library/filetype.c today.
Last edit: kas1e 2013-09-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
Good. I think the inovamusic.library crashes with dopus5 OS4/PPC play.module because there is no Interface. I tested the dopus5 OS3 play.module on my X1000. It doesn't crash but the play window opens and nothing happens; no sound. It's possible that the inovamusic.library hits the OS3 hardware which won't work on OS4/PPC machines under emulation. So, even though MOS can use 68k (OS3) libraries it still might not work unless the MOS has better 68k emulation. Do you have inovamusic.library to test the play.module on MOS? If not, I'll just change play.module to include inovamusic.library stuff for MOS too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm ! If it indeed bang hw .. I can check tomorrow, but maybe indeed let's add there morphos also, and when itix will back he can check it for himself ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tested the dopus5 OS3 play.module on my X1000. It doesn't crash but the play window opens and nothing happens; no sound.
It depends on what version you try. If you try original sasc one : then it can be like this. But if you tried os3-gcc one (with new version), then ppc-glue stubs just will not works, as they need recompile.
I assume we still need to add those macroses about which Ikka says before for each call to module in the Program/Modules , not just open them as it, but open them via EmulateTags, so we will no need for ppc-glue stabs for any os3 modules, as well as any module will works (and os3 one, and ppc , because all of them threaten as 68k ones in end).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
O.K. I added MOS to the inovamusic.library MOD play. I'll commit it when I commit the changed version stuff. We can always change it back if there is a problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can also duplicate the play.module crash by selecting an iff soundfile in a lister and selecting a button or user menu that calls the "Play" command. I tested with WAV files and the crash doesn't occur. The play.module uses "audio.device" to play IFF sound files and Datatypes for other types of sound files. If the file isn't recognized as IFF or a Datatype then play.module plays it through audio.device as an 8 bit raw file at a default sample rate.
We can fix the crash by commenting out the audio.device sound play. All Amigas should have an 8svx and aiff datatype so they can still play those sound types if we disable audio.device sound playing. RAW files are 8 bit soundfiles that have no header info and can only be played at a default samplerate. RAW files were created by some early Amiga 8 bit sound samplers and are mostly 20+ years old. Not supporting RAW files is no big loss.
I'm going to disable (comment out) audio.device sound play in the play.module. If anyone wants to retain audio.device sound play for AROS or MOS please speak up. In that case we can use
#ifdefsto allow audio.device sound play for specific platforms.AROS has an 8svx datatype, so direct audio.device playback probably won't be missed. Good riddance.
@BSzili
O.K. I'll wait till tommorrow to commit the changes to be sure nobody else objects.
@Xenic
Is commenting out audio.device related code fix those crashes with "next" and "abort" too ? I just tried before 2 files: both 8svx ones, just in one directory, and once i just load one of them, press "test", and do "abort" or "next" => have a crash. Is it because they plays via audio.device, but not via datatypes by default ?
Anyway, if commenting it out it fix issues, then of course commit it plz, one bug less ;)
Last edit: kas1e 2013-08-31
@kas1e
Commenting out the audio.device play seems to fix the "next and abort" crashes in OS3 & OS4 binaries. The play.module checks if files are IFF (8svx) and plays them through audio.device if they are IFF. If they're not IFF then it trys to play them with datatypes. I've just commented out parts that check for IFF so the module will play all sound files with datatypes. As soon as I test with the latest repository checkout, I'll commit my changes. The changes are in a single file (play.c) and can easily be changed back by removing the commenting. After thorough testing we can just remove the audio.device code and greatly simplify the play module.
@all
I committed the play.module changes. Please test to be sure IFF sound files work with the changes I made.
@Xenic
I do check our latest code of everyting (rev 533 at moment), and when i run everything in os4-native form, then go to environment, choice for sound system:prefs/presets/sounds/a1000.aiff, and while it playing hit emmidiately "abort", then i have crashed task called "Sound_ObjectHandler". Stack trace are sad one, and looks like this:
Through it seems minor crash, because "Ignore DSI" help, and i can load it again.
The same it crashes if i press "Next" while it plaing (with the same crashlog).
Also there is another new error: If i just (after hard reboot of course) go to enviroments, and again the same choice for sound , let's say "a1000.aiff", and press "test", it plays fine, but window with those buttons "Next and Abort" , never disappear and stays on screen. If i press "Next", then instead of plaing next sound in directory, it just close window. The same if i press on "abort" after sound is stops.
So i reopen ticket again and add all the new info there.
@kas1e
I can't reproduce your new crash on my X1000. No matter how fast I try to hit the Abort or Next button after the sound play starts, I don't get any crash. The play.module appears to be working correctly to me. What PPC Amiga are you testing with (X1000, SAM etc.)??
@xenic
i am on pegasos2 with onboard sound, debug kernel. will try to rest it more deeplt. btw, what happen for you when you press "next" button ? on os4 and mos it seems do nothing, while by logic it should abort previus play and star next one in dirrectory ?
@kas1e
If you are testing sound play from "Settings/Environment/Sound Events", you can only select one sound file in the in the ASL requester that pops up when you select the "file select" button below the list of sound events. There can only be one sound file for each event in the list. There is no next file so clicking next just aborts the sound play.
If you test sound play by adding a "Play" button, you can select multiple sound files in a Dopus5 lister, click the Play button and clicking "Next" in the Play window will abort the current sound and start playing the next file. It is working correctly with OS4 binary and OS3 binary on my X1000.
It sounds to me like your crash may be a datatype problem or Pegasos sound play software issue. Are you using the default datatypes that come with OS4?
@Xenic
Aha, now i understand "Next" button. Just when its present when it called from Settings/Environment/Sounds Events, there is no reasons to have "Next" button at all, as there only "Abort" possible. Can we make it like this : when only one file in choice, only "abort" button in the middle of window, when more than 1 file is choicen, then Next/Play. That will be logical and understandable imho for everyone.
Yes, i use default datatypes, and to say truth i never-ever have any issues on peg2 in terms of sound play. All the music apps which i use and try in last 3-4 years never cause any problems. Why you didn't have problems on x1000 : dunno, but maybe because you didn't use debug.kernel/munge/memguard for catch all the bugs ?
But now interesting stuff coming, i assume i found roots:
For the sake of tests, that what i do now , on original play.module (i.e. before your commented out parts):
So till that moment all ok.
Now, i again just select all those 4 files, press "play" and hit "Abort" button right after first sound starts to play. And have a crash:
DAR again point out on CCCCCCD0 , which mean that "munge" of debug.kernel works, and catch a bug. Ignore DSI cause a lot of :
And so on errors.
What mean its cleary bug was there. And exactly in the play_cleanup() function (which runs when we hit Abort or Next), but you can not notice actual crashlog because wasn't on debug.kernel/munge. And that play.c:907 line was : while ((msg=GetMsg(data->audio_port)));
So pretty possible that we only need to fix that part, and we even can keep previous "raw" play back (because iffs also plays ok after i comment out problematic part).
If we check the same previous version of play.module (i.e. the same one where you didn't do changes), on the usual user kernel (and without munge of course), it crashes differently, and point out on different, what can make you think that problem was in different place and go all of us by wrong way. I.e. it was:
// Close message port if (data->audio_port) {if 0
struct Message *msg; // Flush all messages while ((msg=GetMsg(data->audio_port))); DeleteMsgPort(data->audio_port); data->audio_port=0;endif
~~~~~~
And you have no more crashes, not with abort, not with next , all is fine, raw plays sounds fine, and all ok.
So..
Then, i build version with your changes. And the same going to directory, choice 4 files, and press play. At this moment, it play only A1000.aiff, and play nothing else. And window with "Next/Abort" stays all the time there. So i need to press on "Next" manually to mak next sound works.
And if i press Abort or Next while one of sounds plays, then i have new crash which i didn't have with previous version and about which i told (in Sound_ObjectHandler).
Also, to point out, "Lenght" stop calculated with your changed too. I.e. for all the files window show just "????" in lenght.
So i see there 3 moments in terms of your changes:
Files didn't plays now automatically, user need to hit "Next" to be able to play next file (while originally it was automatically).
Length start to show ????
That bug which you can't reproduce which happens when one want abort already playng music and which can be catched by debug.kernel only and that one need to fix without removing raw_play stuff, etc (which in general works fine on morphos btw before).
All of which mean, that we need to move back previous version of play.c , and just fix crash again, but now, with having in mind real roots (which we catch by debug.kernel).
Maybe also add some code which will just check: if one file in pipeline to play, then only in the middle one button "Abort", if more than one, then buttons Next/Abort as it now.
Hope now it clear all our problems :) Just one bug to fix in previous version of play.c , and maybe add some new bits of code. I dunno through why this while ((msg=GetMsg(data->audio_port))); cause "free node twice" crash, but i assume there should be something done on message after or before doing what it doing. If i remember right, messages should be replied before doing getmsg, so maybe that is problems.
Last edit: kas1e 2013-09-18
@Xenic
Btw, Trixie on amigans.net: http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=5671&start=320
suggest the same : all messages should be replied. I think that should fix the stuff instead of commenting of block.
@kas1e
There are no messages to clean up for datatypes sound play. I overlooked the cleanup when I commented out the audio.device sound play. I've now commented out some more IFF stuff and set the audio port to NULL so the message cleanup will be skipped. Please test the attached OS4 play.module to see if it crashes and let me know the result.
As for your other concerns:
Continuous play only occurs with audio.device sound play of IFF files because the raw audio data is extracted from the IFF audio files with IFFParse library and continuously copied into buffers for audio.device. Datatype sound play works the same as it did with original SASC Dopus5.
The sound length is calculated from the data length and play speed contained in the IFF file. That play.module datatype play doesn't calculate a length, which is why you see the ??? for length. I don't know if that's even possible with some sound formats that datatypes can play.
@Xenic
I mean original play.c (without your changes, when not only datatypes but when also audio.device play have place). That one crashes on cleanup of things even before your changes.
Didn't crashes now, but sometime just skip the "next" sound and play nothing. I.e. if i choice those 4 files in the prefs/presets/sounds, press button "play" , and then hit "next" while any of modules plays, then next one in 50% of time just didn't plays and only silence here. Some time even 2 files in row didn't plays. But no crashes.
Anyway, i just build my own play.module, which are pure original , just with commented out "close message port" block: all works fine, length shows ok, no crashes at all, no "skips" when hit "next", etc.
Just check attach. If it will works for you without problems , then imho better use that one (just need to make correct cleanup or the same " set the audio port to NULL so the message cleanup will be skipped" as you do).
At least in that case it works as expected, "Next" works always, length shows, and i have no single crash with.
Last edit: kas1e 2013-09-19
@kas1e
Don't set the audio port to NULL if you are keeping the audio.device sound play. The port is used by the IFF sound play through audio.device. The only time the audio port should be NULL is if ONLY datatypes sound play is being used. Also, I don't think we need to eliminate the entire audio port cleanup. The message cleanup seems to be causing the crash. That could be because the "DoIo()" exec function is documented as cleaning up the messages. I don't know for sure because my system freezes and I can't access debug output.
I don't know why the datatype ONLY sound play works perfect on my X1000 but has skipping problems on your system. I don't like the IFF audio.device sound play because it violates the SDK documention. Read the DoIo() documentation in SDK:Documentation/AutoDocs/exec.doc. It specifically states that DoIo() should not be used with audio.device. A similar warning also exists in the official OS3 developer documentation. DoIo() is probably used in the play module because it is a simple way to allow for aborting sound play and didn't cause a crash on OS3.
If you insist on keeping the IFF audio.device sound play then I suggest we only comment out the message cleanup like this:
// while ((msg=GetMsg(data->audio_port)));
I've cleaned up and improved the datatypes ONLY sound.module and it's working perfect on my X1000. Please test the play.module and sound files included in the attached archive. I have no problem skipping sounds with my new play.module.
@Xenic
Yes, now all works fine !
More of it , its just show correct "legth" , and play files automatically when i choice more than one. I.e. everything as it should ! All your samples also plays well , as well as all the samples in the prefs:presets/sounds. "Next" button also works fine , as well as "Abort".
How did you fix that "length" problem ? And how you make that all files now plays without stop and no need to hit "next" after each one ?:)
Anyway, that version works very well and all is fine. Only if it can be possible to detect now if we have 1 sound to play, or more than one, and if it more than one then show window as it now, but if it only 1 file to play, then show no "next" button, but just "abort" in the middle.
@kas1e
By programming it to work the way we want. Just read the code when I commit it to the repository.
O.K. Try the attached OS4 play.module that works like you described. The window display objects (including buttons) are pre-defined in play_data.c. I took a shortcut and just duplicated the object list without the "Next" button and centered the "Abort" button. There is probably a way to get the same results without duplicating the entire object list but I'll leave that to someone else. I'm not to good with object oriented programming but someone like Trixie might know a better way.
In addition to stripping out the IFF audio.device sound play code, I also removed the inovamusic.library MOD playing. Since inovamusic.library is not public domain software or opensource, I don't think there is any way to create an "Interface" file for OS4 and it might not even work right on all of the Amiga platforms dopus5 will support. As far as I know, only people who actually purchased dopus5 or an Inovamusic product are legally entitled to use it. The old-time OS3 Magellan users may not like the inovamusic.library MOD playing removal but I don't think we can support it on all platforms. At some later date we might find an opensource or public domain MOD library that can be added. Users can also assign Dopus5 buttons to use one of the many MOD players that already exist.
Test the attached play.module to see if it works on your system. I still need to clean out some IFF stuff before I commit my changes.
EDIT: The inovamusic.library code is very small; it just opens the library and sends it a file to play and waits for finish or abort. If you want I can add that code back for OS3 (
#ifdef __amigaos3__) because it might still work on a classic Amiga.Last edit: xenic 2013-09-20
@Xenic
Checked, everything fine. Let's commit it !
As for inovamusic.library, i already write mail to Olaf, maybe Greg will give us source of it as well, so we can port it everywhere. But in meantime maybe all the "inovamusic.library" code should indeed go via ifdef amigaos4. That also include Library/filetype.c file, as one of os4 testers have crashes as he have it by some reasons intalled in LIBS:.
So while code will be there , it all still will works only for os3, but when (and if) we will have source, we can uncomment ready to use part.
@kas1e
O.K. I'll add the inovamusic.library MODULE play code back into OS3 and commit the code as soon as possible. As I mentioned in the version topic, I'll also be commiting new versioning files.
@xenic
Tested our latest on moment svn (624) : everything fine in terms of play.module, versions fine, all work as need it. So i close ticket for sure now , thanks !
EDIT: btw, i only think that inovamusic.library in play.module should be also not only for os3, but for morphos (where 68k libs works without external ppc-glue-stubs). Like i do in commit #625 for library/filetype.c today.
Last edit: kas1e 2013-09-23
@kas1e
Good. I think the inovamusic.library crashes with dopus5 OS4/PPC play.module because there is no Interface. I tested the dopus5 OS3 play.module on my X1000. It doesn't crash but the play window opens and nothing happens; no sound. It's possible that the inovamusic.library hits the OS3 hardware which won't work on OS4/PPC machines under emulation. So, even though MOS can use 68k (OS3) libraries it still might not work unless the MOS has better 68k emulation. Do you have inovamusic.library to test the play.module on MOS? If not, I'll just change play.module to include inovamusic.library stuff for MOS too.
@Xenic
Hm ! If it indeed bang hw .. I can check tomorrow, but maybe indeed let's add there morphos also, and when itix will back he can check it for himself ?
@Xenic
Btw ,
It depends on what version you try. If you try original sasc one : then it can be like this. But if you tried os3-gcc one (with new version), then ppc-glue stubs just will not works, as they need recompile.
I assume we still need to add those macroses about which Ikka says before for each call to module in the Program/Modules , not just open them as it, but open them via EmulateTags, so we will no need for ppc-glue stabs for any os3 modules, as well as any module will works (and os3 one, and ppc , because all of them threaten as 68k ones in end).
@kas1e
O.K. I added MOS to the inovamusic.library MOD play. I'll commit it when I commit the changed version stuff. We can always change it back if there is a problem.