2019-05-09 18:22:33

So, since I made a pack file, where you can get a sounds data in bytes, I'd like a way to play it with sound_lib.
I tried to read through the classes and didn't find anything helpful.
Any ideas?
Thanks in advance.

2019-05-09 20:46:17

That's the problem I found with your pack, it either extracted or packed the file, it didn't just return unencrypted data. As far as I know, your pack file doesn't support that feature yet. Paul's pack does, but it requires the user to provide an Iv in addition to the key, and from what I understand of cryptography it is very easy to provide something that is not secure when dealing with that type of data.

2019-05-09 21:05:26 (edited by keithwipf1 2019-05-09 21:12:39)

Hi, it does, it's just isn't in function form though I can update that if you wish.
If you want the bytes of boom.ogg:
#assume file is the pack file object, and you loaded a pack file with a key
data=file['boom.ogg']


You index it like a dictionary.
I'm going to change that to a function called get_bytes, which works the same way.
Edit: Modified Pack, both the pack file and the documentation.
The previous example won't work any more once you re download the pack though any old pack files are still compatible, use pack.get_bytes() instead where pack is your pack object.

2019-05-10 02:25:45

Hi. What you need to do is use a ctypes string buffer. So import ctypes, then when loading:
string_buffer=ctypes.create_string_buffer(the_bytes)
string_buffer_address=ctypes.addressof(string_buffer)
handle=sound_lib_stream.FileStream(file=string_buffer_address, mem=True, length=len(string_buffer))

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-10 21:04:32

Hi, and thanks for that.
Not very familiar with CTypes, but now I have one less excuse!
Will give it a try!

2019-05-13 19:53:02

Hi again,
So, funny story, I tried it again yesterday and it didn't work, because I didn't copy your sample code and I forgot the length parameter in FileStream().
It does work now, but do I need to keep the string_buffer object around, in the sound object let's say?
The first time I didn't the sound played perfectly, and the second time I didn't it said something like OS.access violation error.
When I stored the buffer in a global object, the sound played again, but do I need to do that?

2019-05-13 21:11:15

Yeah you'll want to keep the buffer around while the sound_lib handle exists. Remember, you are streaming, not loading. So this means you are reading small chunks of that data during playback, so if you destroy the string buffer, sometimes it will continue to play because destroying the buffer doesn't necessarily wipe the memory from that address space and make it blank, it just makes it available for use again. So if you destroy the buffer in python and you don't allocate any other memory, the sound *may, continue to play. But hen if you destroy the buffer and you read a 200mb file, likely you will overwrite that address space containing the memory from the buffer, and then sound_lib will receive invalid data and fail to continue playing when it attempts to load the next chunk of data and reads part of your 200mb file instead of the audio data. Reading invalid memory like that will usually cause all sorts of issues like access violations or even crashes if you are unlucky. One time I destroyed the buffer for fun while the sound was playing and a second later the sound stopped playing with a loud squawking sound before failing entirely lol. The only reason it was able to make that sound was because I had loaded a wav sound into memory, and you can almost directly play back bytes as wav without running them through some decoding algorithm first, so for a while there was still valid audio to play back audio before it stopped. Even if you don't allocate any other memory but you destroy the buffer, the truth is that likely something else will internally allocate memory and overwrite the address space containing your audio data, sometimes within a couple ms, sometimes a few seconds and maybe if your lucky that memory won't be overwritten. So anyway TLDR, save a reference to the buffer while the handle from sound_lib is open. big_smile

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com

2019-05-13 21:57:38 (edited by keithwipf1 2019-05-13 22:01:00)

Thanks, I  understand what you are getting at.
Before I sort of got the concept that I was telling sound_lib and PYBASS where in memory the sound is, or where it starts.
I did a little test when I was playing with code to load the sound.
ctypes.string_at seems to take an address and return what's there, or at least that's what I think it does, and when I passed the length parameter of the length of my file, it returned gibberish. Not surprising, but my MP3 file ends with something like LAME 3.5 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
I didn't get that.
Maybe I should read up a bit on how memory, Python and computers work together.
Anyway, my code stores the buffer now. Let's just hope there is no error or...
By the way, sound_lib.output is for managing all sounds played by sound_lib, am I correct?
Thanks.

2019-05-13 22:24:22

Yes I believe so

I am a web designer, and a game developer. If you wish see me at http://www.samtupy.com