ARCed Audio Player

Started by ForeverZer0, November 19, 2011, 03:50:58 pm

Previous topic - Next topic

Ryex

November 26, 2011, 06:18:25 pm #40 Last Edit: November 26, 2011, 06:22:22 pm by Ryex
well I was a bit stupid when wrapping the getPitch method and returns the offset instead (copypaste you kill me) but it should other wise work. even if you set it before playing. but if it doesn't work until you start the file playing just set the pitch right after calling the play method and it should work for now but that is probably a bug and needs to be fixed.

I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

Yeah, I already made it like that and committed. Its not really a critical bug, simply calling it right after works well enough.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

also it seems you forgot to commit a file

ExpGrip_Dialog.py ?
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

Oops. You are correct, I'm committing them now.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

So basically you are experiencing a memory leak when you play files as if the old ones haven't been destroyed? I'll take a look at it in XAL and if I can't find anything, I'll see if I can give some suggestions what should be checked in PyXAL.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

November 26, 2011, 08:47:07 pm #45 Last Edit: November 26, 2011, 08:48:29 pm by Ryex
also it seems that the value returned by getOffset is only updated when the sound is paused or otherwise stopped AND it returns the bytes into the buffer not seconds as expected but the float type of the value

I like how we are acting as a debug team for your company's systems :) ARC's as well I suppose but the irony is delicious. you've roped in freelacers that arn't getting paied a cent to test and help you refine a system created by your company! you sneaky bastard you. your awesome.

and yes somewhere in the process of creating and destroying sounds there is a significant memory leak roughly equivalent to the size of loading a file. the wrapper can't be involved because it is treated as a python object and garbage collected. the wrapper only keeps a pointer to the XAL object. a pointer that becomes invalid when the object is destroyed via the xal::mgr.destroy[Sound/Player] call.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

Here's some other things to check, some bugs, some just wish lists. (Not all of these are in the C++ implementation, but just making a small compiled list)


  • getOffset's return value is in bytes

  • Changing the pitch without the audio actually playing does nothing (not tested with volume)

  • Return value for getPitch() is always 0.0

  • The memory leak

  • The offset value is not set until playback is paused. I would really love for this to be kept updated for providing the scrollbar functionality



That's all I can think of for now.

EDIT: Ryex posted while I wa typing, but I am posting anyways :P
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

November 26, 2011, 09:05:54 pm #47 Last Edit: November 26, 2011, 09:09:18 pm by Blizzard
Thanks for the list. It will make it easier to check everything. I can explain a few things right away.


  • This actually depends on the audio system. On Mac OS in OpenAL somebody messed up badly and when using OpenAL's internal function to get the byte offset and it actually returns the time offset. That's why it's a float value. ._. Generally, you are not supposed to use Offset. I can't remember why I made that public getter in the first place. I'll check, maybe I should remove it as it's mostly something used internally to determine where a "paused" sound has stopped.

  • That's because of how the audio system works. You first have to play the sound, then you have to set the volume and the pitch. While it should be possible to change the pitch of a sound while it's playing, RMXP handles pitch change by restarting the played sound (if you want to play the same sound with a different pitch). I think this is intentional and while it works that way in the engine, I'm not sure if you need that in the editor.

  • Must be a bug. I'll look into it.

  • As I said, I'll check that.

  • Again the problem with offset. I can see if I am able to implement a getPosition function for that.



@Ryex: A little bit. :V:
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

November 26, 2011, 09:07:45 pm #48 Last Edit: November 26, 2011, 09:17:11 pm by Ryex
I just fixed the getPitch function earlier. as I said it we returning the offset not the pitch. update and you'll see.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Ah, right. xD Then I'll take care of the rest.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

ForeverZer0

Here's a little test I made to demonstrate the memory leak. Apparently the leak is in sound, but only when a different file is loaded. Loading the same file does not cause an increase in memory.

http://pastebin.com/2nXMjjeK
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Ryex

quick question do I need to call free on the data pointer passed to the readRawData function? I wouldn't think it was dynamically allocated memory but if it is that would account for part of the memory leak but not all of it it's still there even when you go through a loop of only creating and destroying sounds.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

November 26, 2011, 10:26:33 pm #52 Last Edit: November 26, 2011, 10:30:13 pm by Blizzard
Quote from: Blizzard on November 25, 2011, 12:23:05 pm
I implemented Sound::readRawData. It takes an unintialized "unsigned char**" as argument and returns the size of the array it created. If the return value is greater than 0, make sure you use "delete []" later to avoid memory leaks. If the return value is 0, then no data will have been created and the pointer will be set to NULL.


The reason why it works like this is because some sounds (such as streamed sounds) won't have the whole audio data loaded. That's why I have to load the whole data manually and assign the double pointer argument to that data. Rather than dealing with inconsistencies when the data should be deleted and when not, I simply made it so you always have to use "delete []" on the data you get. What you do with the data before you destroy it is up to you, but you have to delete it yourself.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

November 27, 2011, 02:05:25 am #53 Last Edit: November 27, 2011, 02:07:32 am by Ryex
ok so that was DEFIANTLY a memory leak. I called free on the array after I have gotten the python string and the memory usage dropped dramatically in my test.
if you have time blizz you might want to do a test of your own in strait C++ and see if you can see a memory leak because I'm no longer sure if it exists. for me the memory usage isn't rising decernably when changing sounds.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

We haven't had a memory leak in XAL for ages. I don't think there is one, because I checked and tested the code many, many times.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

November 27, 2011, 03:42:23 am #55 Last Edit: November 27, 2011, 03:45:10 am by Ryex
just in case could you take a look at the pyx file and see if you can see any other places where memory might be leaking or where I'm doing something wrong (like deleting the 'hstr's that I'm passing that I create from python strings)? Cython takes a knowledge of C++ and python and I only have a passable knowledge of the former
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

hstrs don't need any cleaning.
I suggest you manually use "del" with PyXAL objects. This skips the garbage collector and might remove the problem. Or maybe you should implement the __del__ function in the PyXAL objects (instead of dealloc or whatever it is called).
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

I see
what should I put in the __del__ method then? it seems counter intuitive to destroy the sound or player there as the manger interface should still theoretically be able to find and wrap those objects again.
and id I do make it so that the __del__ method destroys the sound or player I need to make sure that I either remove access to the MGR.findPlayer method or make it keep track of wrapper instances so that two wrappers both of which would call destroy when garbage collected don;t exist at the same time. as the second call to destroy would fail.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Actually this all depends on how you want to implement things. If you are making a 1:1 implementation of the C++ implementation, then no, you don't need __del__. But if you are wrapping every class separately, you do need it.
Keep in mind that Python 2.5 has problems with the garbage collector if you have a recursive object reference (IDK if 2.6 has it as well, I think it wasn't fixed until a much later version). That's why you should use "del sound" either way.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

November 27, 2011, 04:08:49 pm #59 Last Edit: November 27, 2011, 05:24:08 pm by Ryex
how about this. in the player object I'll keep a reference to the sound object that created it. the del statement works by removing the reference to the object in the local scope so that garbage collection would pick up and dispose the object so the deletion of the sound object would only dispose the sound if no player that used the sound were still around in the players delete method I'll destroy the player and delete the reference to the sound object. and in the sounds delete method I'll destroy the sound.

Also I think I'm going to look into implementing this binding with the python ctypes library. that way we don't have to worry about rebuilding pyxal for other operating systems we would just need to build XAL for them and the ctypes would take care of the rest.

EDIT: Nevermind, ctypes can only talk to c function so if we wanted to use it we would need to provide a flattened extern c interface dll to XAL Cython is much better for our uses.

also a hstr created with 'hstr* string = new hstr(char*)' does not need to be deleted later?
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />