[00:05:58] *** barra_ has quit IRC
[00:05:58] *** juanmabc has quit IRC
[00:06:16] *** juanmabc has joined #openal
[00:06:16] *** barra_ has joined #openal
[00:06:16] *** irc.freenode.net sets mode: +vv juanmabc barra_
[00:14:20] *** angasule has quit IRC
[00:49:02] *** wild13_ has joined #openal
[00:49:02] *** ChanServ sets mode: +v wild13_
[00:49:16] *** wild13_ has quit IRC
[00:49:41] *** wild13_ has joined #openal
[00:49:41] *** ChanServ sets mode: +v wild13_
[00:55:11] *** angasule has joined #openal
[00:55:12] *** ChanServ sets mode: +v angasule
[01:00:53] *** wild13 has quit IRC
[01:04:24] *** angasule has quit IRC
[01:09:14] *** juanmabc has quit IRC
[02:36:28] *** kb1ooo has joined #openal
[02:36:28] *** ChanServ sets mode: +v kb1ooo
[02:46:15] *** Gigs has joined #openal
[02:46:15] *** ChanServ sets mode: +v Gigs
[03:13:24] *** barra_ has quit IRC
[04:00:28] *** wild13_ has quit IRC
[04:04:08] *** Proteus has joined #openal
[04:04:08] *** ChanServ sets mode: +v Proteus
[04:12:27] *** kb1ooo has quit IRC
[04:17:49] *** Proteus_ has quit IRC
[04:46:34] *** Proteus_ has joined #openal
[04:46:34] *** ChanServ sets mode: +v Proteus_
[04:54:58] *** kb1ooo has joined #openal
[04:54:58] *** ChanServ sets mode: +v kb1ooo
[05:03:18] *** Proteus has quit IRC
[05:10:02] *** angasule has joined #openal
[05:10:02] *** ChanServ sets mode: +v angasule
[05:30:00] *** Alam_Debian has quit IRC
[05:53:07] *** wild13 has joined #openal
[05:53:07] *** ChanServ sets mode: +v wild13
[06:58:58] *** wild13 has quit IRC
[08:15:08] *** Walt_ has quit IRC
[09:17:22] *** kb1ooo has quit IRC
[09:17:23] *** neric has quit IRC
[09:17:24] *** qknight has quit IRC
[09:17:24] *** Mazon has quit IRC
[09:17:36] *** kb1ooo has joined #openal
[09:17:36] *** neric has joined #openal
[09:17:36] *** Mazon has joined #openal
[09:17:36] *** irc.freenode.net sets mode: +vvv kb1ooo neric Mazon
[09:17:56] *** qknight has joined #openal
[09:17:56] *** irc.freenode.net sets mode: +v qknight
[10:17:27] *** Proteus_ has quit IRC
[10:19:07] *** Proteus has joined #openal
[10:19:08] *** ChanServ sets mode: +v Proteus
[10:31:01] * KittyCat is away: sleep
[10:58:21] *** angasule has quit IRC
[10:58:37] *** angasule has joined #openal
[10:58:37] *** ChanServ sets mode: +v angasule
[10:59:57] *** Walt_ has joined #openal
[10:59:57] *** ChanServ sets mode: +v Walt_
[11:32:04] *** barraAway has joined #openal
[11:32:04] *** ChanServ sets mode: +v barraAway
[11:34:18] *** barraAway is now known as barra_
[12:15:10] *** Alam_Debian has joined #openal
[12:15:10] *** ChanServ sets mode: +v Alam_Debian
[12:46:47] *** mattelacchiato has joined #openal
[12:46:47] *** ChanServ sets mode: +v mattelacchiato
[12:46:55] <mattelacchiato> hi
[13:03:24] <Rain|code> hi
[13:03:37] <Rain|code> mattelacchiato...are you italian?
[13:04:01] <Rain|code> your nick sonds like an italian word trick
[13:04:15] <mattelacchiato> hi Rain|code
[13:04:25] <mattelacchiato> nope, i'm from hamburg
[13:04:44] <Rain|code> how did you get to your nick?
[13:04:45] <mattelacchiato> earlier, my favourite drink was latte macchiato
[13:04:50] <Rain|code> hahahaha
[13:04:53] <Rain|code> I see
[13:05:02] <Rain|code> that's what I meant
[13:05:05] <Rain|code> :)
[13:05:20] <mattelacchiato> some friends called me "matte", so i developed "mattelacchiato"
[13:05:56] <Rain|code> :)
[13:12:14] <mattelacchiato> please tell me, i'm stupid
[13:12:41] <mattelacchiato> my format parameter for alBufferData is -for shure- 4353
[13:12:56] <mattelacchiato> which is in hex 0x1101
[13:13:13] <mattelacchiato> which stands for AL_FORMAT_MONO16
[13:14:38] <mattelacchiato> but alBufferData jumps in the "switch(format)"-command to AL_FORMAT_51*
[13:15:52] <mattelacchiato> even the eclipse debugger tells me, that format = 4353
[13:32:41] <mattelacchiato> looking in the alext.h to find that the AL_FORMAT_51*-constants are from 0x120A to 0x120C (4618 to 4620), but NOT 4353...
[13:45:22] *** kb1ooo has quit IRC
[14:52:43] *** mattelacchiato has quit IRC
[15:17:49] *** Alam_Debian has quit IRC
[15:18:21] *** Alam_Debian has joined #openal
[15:18:21] *** ChanServ sets mode: +v Alam_Debian
[15:43:54] *** Proteus_ has joined #openal
[15:43:55] *** ChanServ sets mode: +v Proteus_
[15:47:55] *** Proteus has quit IRC
[16:06:13] *** juanmabc has joined #openal
[16:06:13] *** ChanServ sets mode: +v juanmabc
[16:22:06] *** mattelacchiato has joined #openal
[16:22:06] *** ChanServ sets mode: +v mattelacchiato
[16:22:17] <mattelacchiato> re
[16:23:46] *** jvalenzu has joined #openal
[16:23:47] *** ChanServ sets mode: +v jvalenzu
[16:28:45] *** juanmabc has quit IRC
[16:47:04] *** juanmabc has joined #openal
[16:47:04] *** ChanServ sets mode: +v juanmabc
[16:47:25] *** Rivorus has joined #openal
[16:47:26] *** ChanServ sets mode: +v Rivorus
[16:49:10] <Rivorus> is it possible in openal to separate a multichannel buffer into a separate source for each channel (each at a different location) and then play them in a way that makes them guaranteed to be in sync
[16:51:25] <Rivorus> for example, can i simulate a room that has a "virtual" 5.1 setup that a listener can move through
[16:58:14] <Rivorus> or as a simpler example, simulate a stereo boom box that a listener can move around where the virtual boom box's left speaker plays the left channel of a stereo buffer and the boom box's right speaker plays the right channel of the same buffer in synchronization
[17:08:52] *** wild13 has joined #openal
[17:08:52] *** ChanServ sets mode: +v wild13
[17:18:46] <mattelacchiato> hmmm, interesting questions, Rivorus
[17:19:11] <mattelacchiato> but i wouldn't know how to implement this
[17:20:38] *** wild13 has quit IRC
[17:48:04] *** jvalenzu has quit IRC
[18:03:20] *** wild13 has joined #openal
[18:03:20] *** ChanServ sets mode: +v wild13
[18:05:51] *** Gigs has quit IRC
[18:06:20] *** Gigs has joined #openal
[18:06:20] *** ChanServ sets mode: +v Gigs
[18:16:51] <lgp-michael> Rivorus: speaking just as someone that uses it and knows linux, I doubt a LOT that it could be done, as openAL uses a second thread for scheduling and playing and threads arent guaranteed realtime
[19:08:33] *** makr has joined #OpenAL
[19:08:33] *** ChanServ sets mode: +v makr
[19:43:25] *** Pepperoni has quit IRC
[19:56:44] *** Setien has joined #openal
[19:56:44] *** ChanServ sets mode: +v Setien
[20:00:37] *** juanmabc has quit IRC
[20:13:03] *** Setien has quit IRC
[21:07:26] <KittyCat> Rivorus, it can. but you'd manually need to split the 5.1 buffer into 6 seperate streams
[21:07:48] <KittyCat> alSourcePlayv is gauranteed to start a specific number of sources at the same time
[21:11:20] <KittyCat> also note that the center and sub-woofer channel aren't part of the 3D spatialization, so you could never get the center to play on the center speaker, and the LFE channel would be generated by the overall output
[21:23:30] * KittyCat is back.
[21:28:22] <KittyCat> mattelacchiato, you're sure it's jumping to the AL_FORMAT_51* case? the mono and 51chn formats do the same thing and call the same code.. just with a different parameter for LoadData
[21:34:06] <mattelacchiato> KittyCat: Yes, MONO_16 and 51 are complete different cases. when eclipse's debugger is correct, it's jumping to AL_FORMAT_51* case
[21:34:39] <KittyCat> did you add a trace to right before the switch() and see what the value is?
[21:34:57] <mattelacchiato> jepp
[21:35:01] <lgp-michael> mattelacchiato: point to be sure, make certail you are using the source code to match the library, as you can still get seemingly sane results from source code that doesnt quite match
[21:35:45] <lgp-michael> so if its using the openal system library instead of the one you built...
[21:36:20] <KittyCat> or if it's looking at old source code and getting the line wrong..
[21:36:25] <KittyCat> old or new
[21:36:34] <lgp-michael> exactly
[21:38:07] <mattelacchiato> the sourcecode is for shure the openAL-soft-code
[21:39:24] <KittyCat> but is the lib being used the same exact one compiled from that source code? was the source code changed afterward? or is the lib otherwise a different version than the source code?
[21:42:11] <mattelacchiato> to be shure, i'll compile the lib and the complete projekt new
[21:42:23] *** jvalenzu has joined #openal
[21:42:23] *** ChanServ sets mode: +v jvalenzu
[21:50:44] <mattelacchiato> no change...
[21:51:12] <mattelacchiato> it's still jumping in the wrong case, KittyCat an lgp-michael
[21:53:40] <KittyCat> I'd have to say there's memory corruption somewhere, then. the case is a constant compiled-in value, and can't just change where it goes without something really wrong
[21:53:51] <KittyCat> try running the app with valgrind and see what it says
[21:54:19] *** Pepperoni has joined #openal
[21:54:19] *** ChanServ sets mode: +v Pepperoni
[21:55:07] <Pepperoni> anyone know where I could find some meteor flyby and impact like sounds?
[21:56:02] <KittyCat> http://www.findsounds.com/  is probably where I'd start looking
[21:56:20] <mattelacchiato> http://www.kvraudio.com/forum/viewtopic.php?t=37272&start=0&postdays=0&postorder=asc&highlight=
[21:56:30] <Pepperoni> thnx
[22:00:38] <mattelacchiato> okay, here's valgrind's tail output: http://sprunge.us/RSNB
[22:02:16] <KittyCat> need to see a bit more
[22:03:24] <mattelacchiato> sry, was the wrong usage of valgrind, too
[22:06:15] <mattelacchiato> here's the whole output: http://rafb.net/p/bkskm953.html
[22:08:36] <KittyCat> ==26759== Source and destination overlap in memcpy(0xBD4B318, 0xBD4B318, 4096)
[22:08:36] <KittyCat> ==26759==    at 0x4C2508B: memcpy (mc_replace_strmem.c:402)
[22:08:41] <KittyCat> should use memmove there
[22:09:40] <mattelacchiato> me?
[22:09:50] <mattelacchiato> i?
[22:09:50] <KittyCat> if that's your source file, at least
[22:10:34] <KittyCat> hmm
[22:11:01] <mattelacchiato> i'm actually using Vectors instead of int-arrays
[22:11:28] <KittyCat> how are you calling alBufferData?
[22:12:11] <mattelacchiato> alBufferData(2, 4353, 0x7fefff5a0, 16680, 44100)
[22:12:21] <KittyCat> I see that, b ut wh at's your code?
[22:12:27] <KittyCat> *but what's
[22:12:39] <mattelacchiato> alBufferData(buf, soOal->getFormat(), &data, data.size(), freq);
[22:12:48] <KittyCat> &data[0]
[22:12:58] <KittyCat> &data is a pointer to the vector object, not the memory
[22:13:32] <mattelacchiato> alBufferData(buf, soOal->getFormat(), &data, data.size(), freq);
[22:13:36] <mattelacchiato> sry
[22:13:43] <mattelacchiato> DEBUG: alBufferData(2, 4353, , 16680, 44100)
[22:13:54] <KittyCat> alBufferData(buf, soOal->getFormat(), &data[0], data.size(), freq); is what you want to do
[22:14:07] <mattelacchiato> yes, i thought so, too
[22:14:15] <mattelacchiato> but as you see, its empty
[22:14:36] <KittyCat> it's not a string, it's just raw byte data
[22:15:02] <mattelacchiato> oh.....
[22:15:08] <KittyCat> if you're using iostreams, you need to use (void*)&data[0] to print it
[22:15:16] <mattelacchiato> i've just stopped there in the debugger
[22:15:29] <mattelacchiato> it's working now
[22:15:39] <mattelacchiato> thank you!
[22:16:00] <KittyCat> no problem :)
[22:16:24] <mattelacchiato> can this problem cause the false case-jump?
[22:16:46] <KittyCat> if 'data' is local, it can mess up the stack
[22:16:58] <KittyCat> well..
[22:17:09] <KittyCat> no it couldn't, actually. I dunno
[22:19:39] <mattelacchiato> it's still jumping in the wrong case.
[22:20:06] <mattelacchiato> but properbly the different cases are useless.
[22:20:09] <mattelacchiato> LoadData(ALBuf, data, size, freq, format, AL_FORMAT_61CHN16);
[22:20:30] <mattelacchiato> or why is the format-variable still in the LoadData-function?
[22:21:14] <KittyCat> it uses the original format so it knows how to convert to 16-bit (eg. 8->16, 16->16, 32->16)
[22:21:24] <mattelacchiato> ah, allright
[22:21:40] <mattelacchiato> so everything will be converted to 16bit...
[22:21:48] <KittyCat> yeah
[22:21:52] <mattelacchiato> k
[22:22:00] <KittyCat> makes the mixing simpler if it can assume signed 16-bit samples
[22:24:28] <mattelacchiato> i see
[22:27:02] *** jvalenzu has quit IRC
[22:27:04] <KittyCat> the audio sounds wrong when played back?
[22:28:39] <mattelacchiato> not so far...
[22:28:48] <makr> Is it a bad idea to stream sound effects?  (maybe ranging from 2 seconds to 8seconds)
[22:28:51] <mattelacchiato> i will test it later
[22:29:04] <makr> I'm trying to keep memory consumption down on the iPhone, and my sfx weigh in at ~12mb.
[22:29:28] <makr> I figured I could perhaps stream audio files if they are larger than 2 seconds, cpu-intensity willing
[22:30:12] <KittyCat> makr, it's not a bad thing, no. processing might get a little heft with all the polling and refilling you need to do, though
[22:30:19] <makr> :/
[22:30:20] <KittyCat> *hefty
[22:31:07] <makr> That is what I figured.  I'm testing the implementation out now to see if it kills my frame rate.
[22:31:16] <KittyCat> how much memory and cpu power does an iphone have?
[22:32:17] <makr> the phone has 128mb.  some websites claim you get about ~64 for your app
[22:32:42] <makr> with a lot of that being shared for textures, according to other websites.
[22:33:27] <KittyCat> depending on the quality of the iphone's output speaker, you can reduce the frequency to keep memory use down (take out every other sample and halve the specified rate)
[22:34:02] <makr> I will keep that in mind.
[22:34:58] <makr> everything is 16bit 22hz mono at the moment
[22:35:41] <KittyCat> I don't quite know how apple's openal implementation works
[22:35:57] <KittyCat> or if the iphone one is much different from the osx one
[22:36:45] <makr> how do you mean?
[22:37:29] <makr> i guess i mean, to what issue are you concerned with, in terms of their impl
[22:37:46] <KittyCat> memory use, or any conversions i t may do
[22:37:51] <makr> ah
[22:38:16] <makr> there didn't appear to be that much overhead when i statically loaded all sfx
[22:38:16] <KittyCat> iirc, apple's version has a static_buffer extension, which lets it use your data pointer and not make a copy
[22:38:29] <makr> i believe you are correct
[22:39:26] <KittyCat> "ALC_EXT_STATIC_BUFFER : Support for buffers at a static memory location ("no copy buffers")."
[22:39:33] <KittyCat> there doesn't seem to be any info on it, though
[23:24:53] <wild13> KittyCat
[23:25:09] <KittyCat> ?
[23:25:26] <wild13> you said something aabout if there was no more data to be feed into the buffer
[23:25:31] <wild13> it would seem like it would loop right
[23:26:07] <KittyCat> if you kept feeding/queueing the same data, it would
[23:26:24] <wild13> well how do i stop it from being feed data
[23:26:37] <wild13> after teh file was played
[23:26:55] <wild13> http://www.file-upload.net/download-999166/test.tar.bz2.html
[23:27:01] <wild13> theres a example project with the problem
[23:27:02] <KittyCat> stop calling the update functions when ov_read returns 0
[23:27:09] <wild13> ahh
[23:30:51] <makr> In regards to my previous inquiries about streaming .wav in OpenAL on iPhone:  I haven't noticed any slow down.
[23:31:00] <makr> So... sweet :)
[23:34:19] <wild13> http://pastebin.com/m5033100b
[23:35:38] <wild13> KittyCat is there a reason that owuld continue to loop?
[23:38:17] <KittyCat> not that I can see
[23:38:44] <KittyCat> but if you unqueue, call stream(), then requeue, it'll just queue up the old data again
[23:38:57] <wild13> so reverse it?
[23:39:22] <KittyCat> reverse what?
[23:39:36] <wild13> hmm
[23:39:42] <wild13> update unques the buffer
[23:39:44] <wild13> calls stream
[23:39:46] <wild13> the reques
[23:39:51] <wild13> and update is constantly called
[23:40:00] <wild13> so it would continue to collect old data?
[23:40:04] <KittyCat> if stream() fails, just don't requeue the buffer
[23:40:23] <wild13> so if stream = false ?
[23:40:52] <KittyCat> if(stream(buf) != false) alSourceQueueBuffers(...);
[23:40:59] <wild13> kk
[23:45:17] <wild13> thanks kitty :)
[23:45:41] <KittyCat> np
[23:46:38] <wild13> lol you just saved me a lot of time again
[23:58:31] <mattelacchiato> good night and nice dreams :-)
[23:58:42] *** mattelacchiato has quit IRC





top