[00:09:15] *** kb1ooo has quit IRC
[00:40:52] *** prophile has quit IRC
[01:20:28] * KittyCat is away: sleep
[01:22:58] *** wild13_ has quit IRC
[01:30:41] *** barra_ is now known as barra_fife
[01:38:59] *** wild13 has joined #openal
[01:38:59] *** ChanServ sets mode: +v wild13
[02:02:52] *** juanmabc has joined #openal
[02:02:53] *** ChanServ sets mode: +v juanmabc
[02:10:23] *** lgp-michael has joined #openal
[02:10:23] *** ChanServ sets mode: +v lgp-michael
[02:11:16] <lgp-michael> greetings
[02:11:47] <lgp-michael> anyone in here involved in the openalsoft project - or maybe, if Im lucky, owns the project?
[02:12:52] <wild13> KittyKat is the creator :)
[02:12:55] <lgp-michael> aha
[02:13:20] <lgp-michael> then the pertinent question is, how often does KittyCat unidle {:-)
[02:13:36] <wild13> what time is it were you live?
[02:14:04] <lgp-michael> oh, Im timezone neutral {:-) 00:14UTC
[02:15:13] <wild13> its 12:14 am?
[02:15:19] <lgp-michael> yup
[02:16:01] <wild13> o
[02:16:08] <wild13> around your time from
[02:16:18] <wild13> 12pm to 6pm
[02:16:22] <wild13> he should be here
[02:16:38] <lgp-michael> so in 12 to 18 hours from now
[02:16:59] <lgp-michael> marrrvelous
[02:17:24] <wild13> why what was the question?
[02:17:52] <lgp-michael> oh, I have an issue with openalSoft calling its init finction from its dl unloader function
[02:18:02] <lgp-michael> and I wanna propose a small 3 line patch
[02:18:07] <wild13> ahh
[02:19:04] <lgp-michael> as, if no openal function has ever been called, it makes sense to not init what has never been inited just for the sole purpose of de-initing it
[02:19:30] <lgp-michael> if you see what I mean {:-)
[02:22:42] <wild13> yeah
[02:22:58] *** kb1ooo has joined #openal
[02:22:59] *** ChanServ sets mode: +v kb1ooo
[02:27:04] *** kb1ooo has quit IRC
[02:40:37] *** barra_fife has quit IRC
[02:59:10] *** wild13 has quit IRC
[03:27:10] *** makr has quit IRC
[04:32:38] *** wild13 has joined #openal
[04:32:38] *** ChanServ sets mode: +v wild13
[04:37:20] *** wild13 has quit IRC
[04:40:04] *** wild13 has joined #openal
[04:40:04] *** ChanServ sets mode: +v wild13
[04:47:25] <wild13> hey
[05:36:42] *** Proteus_ has quit IRC
[05:37:13] *** Proteus_ has joined #openal
[05:37:13] *** ChanServ sets mode: +v Proteus_
[05:52:37] *** wild13 has quit IRC
[05:56:17] *** wild13 has joined #openal
[05:56:17] *** ChanServ sets mode: +v wild13
[06:29:07] *** angasule has joined #openal
[06:29:07] *** ChanServ sets mode: +v angasule
[07:13:17] *** Walt_ has quit IRC
[07:27:13] *** wild13 has quit IRC
[07:27:36] *** wild13 has joined #openal
[07:27:36] *** ChanServ sets mode: +v wild13
[07:44:07] *** wild13_ has joined #openal
[07:44:07] *** ChanServ sets mode: +v wild13_
[07:59:59] *** wild13 has quit IRC
[09:12:30] *** juanmabc has quit IRC
[10:02:23] *** wild13 has joined #openal
[10:02:23] *** ChanServ sets mode: +v wild13
[10:19:05] *** wild13_ has quit IRC
[10:37:02] *** angasule has quit IRC
[11:07:24] * KittyCat is back.
[11:14:36] *** Walt_ has joined #openal
[11:14:36] *** ChanServ sets mode: +v Walt_
[11:18:30] *** prophile has joined #openal
[11:18:30] *** ChanServ sets mode: +v prophile
[11:34:40] <wild13> its 4:34am here 0_0\
[11:34:52] <wild13> im heading to bed see ya in teh morning
[11:35:32] <KittyCat> seeya
[11:35:52] *** wild13 has quit IRC
[12:15:52] <lgp-michael> KittyCat: aha, hi, apparently you are the one to talk to about OpenALSoft
[12:16:14] <KittyCat> hi
[12:16:57] <lgp-michael> Just wanted to run a couple of things past you
[12:17:25] <KittyCat> sure, what's up?
[12:18:07] <lgp-michael> firstly, There is an issue thats causing us a ton of grief, in that when the .so is unloaded (Linux platform) it un-units the openal system even if its never been used
[12:18:18] <lgp-michael> and Im planning on just putting in a quick patch to prevent that
[12:18:37] <lgp-michael> and just wanted to run past you if you would be happy to add the patch into the main tree
[12:19:36] <KittyCat> as long as it's not prone to causing crashes or something, sure
[12:19:46] <lgp-michael> heh, no it wouldnt {:-)
[12:21:14] <lgp-michael> secondly, as my company makes commercial game ports for Linux, we've been using openal for years but we're getting close to our first release that moved over to OpenALSoft and we just realised, we've got the OpenAL logo on the box and instead we should have something representing OpenALSoft - do you have some kind of logo of yourown?
[12:21:47] <lgp-michael> we wanna give credit where credit is due {:-)
[12:23:00] <KittyCat> not really any logo. openalsoft is simply intended to be the linux openal implementation.
[12:23:38] <lgp-michael> ok, fair enough.
[12:24:19] <KittyCat> a mention in the docs saying that it's openal soft and such would be nice. but logo-wise, it's just openal
[12:25:09] * lgp-michael nods
[12:28:33] <lgp-michael> wats your patch submissionprocess, just mail you?
[12:28:50] <KittyCat> yeah
[15:30:29] *** angasule has joined #openal
[15:30:29] *** ChanServ sets mode: +v angasule
[15:34:40] *** angasule_ has joined #openal
[15:34:40] *** ChanServ sets mode: +v angasule_
[15:36:03] *** angasule has quit IRC
[16:09:12] *** Rain|code has left #openal
[16:16:15] *** Rain|code has joined #openal
[16:16:15] *** ChanServ sets mode: +v Rain|code
[17:21:15] *** Proteus_ has quit IRC
[17:21:48] *** Proteus_ has joined #openal
[17:21:48] *** ChanServ sets mode: +v Proteus_
[17:29:54] *** kb1ooo has joined #openal
[17:29:54] *** ChanServ sets mode: +v kb1ooo
[17:39:17] *** jvalenzu has joined #openal
[17:39:17] *** ChanServ sets mode: +v jvalenzu
[17:52:32] *** barra_away has joined #openal
[17:52:32] *** ChanServ sets mode: +v barra_away
[17:54:37] <Rain|code> could anybody suggest a clear tutorial for the use of openal with ffmpeg?
[17:55:08] <Rain|code> I'm trying to playback a video and for images it's ok...but I'm having a hard time with sound
[17:55:09] <Rain|code> :(
[17:55:35] <KittyCat> hmm, not sure if there's a tutorial for that
[17:55:57] <Rain|code> or at least some cue on the major steps to follow
[17:56:41] <lgp-michael> Rain|code: I had a pain of a time syncing audio and video, ended up taking 2 streams from the video and reading one for audio and one for video
[17:57:05] <Rain|code> I imagine
[17:57:12] <lgp-michael> Rain|code: beyond that, you're just looking at reading the frames you've detected as audio streams
[17:57:24] <lgp-michael> and putting them into buffers and then alqueuebuffer them
[17:57:25] <KittyCat> a/v sync'ing is pretty tricky
[17:57:45] <lgp-michael> the data you extract with ffmpeg is already raw IIRC
[17:57:50] <KittyCat> generally though you'd just stream audio through openal, and use the audio position to determine what video frame you're supposed to be playing
[17:57:55] <lgp-michael> so you can just slam it in there with no processing
[17:59:31] <Rain|code> mmm
[17:59:41] <Rain|code> yeah, I got the main concept
[18:00:17] <Rain|code> but still doubtfull ...maybe I'm just too tired...but you know time is running and the deadline is approching...:((
[18:00:48] <lgp-michael> heh, Ive done exactly what you're doing a few years ago, cant give you the source was part of a commercial product but I can answer questions
[18:01:03] <Rain|code> :)
[18:01:25] <Rain|code> (consider I started with openAl and ffmpeg this mornig)
[18:01:36] <lgp-michael> ahh
[18:01:46] <lgp-michael> are you using them for a reason?
[18:01:54] <lgp-michael> you could use something like smpeg
[18:02:02] <lgp-michael> and its all pretty much there for you
[18:02:11] <Rain|code> mmm
[18:02:49] <Rain|code> well...I wouldn't messup with the engine I'm using...
[18:02:55] <lgp-michael> then again, it only really handles mpeg data
[18:03:24] * lgp-michael nods, well, just a thought {:-) Less of a learning curve {:-)
[18:03:54] <KittyCat> gstreamer makes it easy to "just play" an audio+video file. though getting it to play in an already-open audio device with a pre-created surface may be hard
[18:04:05] <KittyCat> never really got into learning gstreamer, though
[18:05:09] <lgp-michael> Rain|code: but anyway, if you need to use ffmpeg/al so be it {:-) Do you have any specific issues
[18:05:15] <Rain|code> well I'm working on a demo for a videogame
[18:05:19] <Rain|code> for a presentation
[18:05:40] <Rain|code> so I have to render the video in the scene
[18:05:44] <lgp-michael> right
[18:05:55] <lgp-michael> in that case yeah
[18:05:57] <Rain|code> (for this it's ok I already done with it)
[18:06:07] <lgp-michael> Its the audio thats killing ya {;-)
[18:06:15] <Rain|code> ya
[18:06:26] <lgp-michael> so youve set up an al source and set its position and listener?
[18:06:30] <Rain|code> it is the first time I'm dealing with audio
[18:06:39] <Rain|code> yea
[18:06:49] <Rain|code> I already got a file played
[18:06:54] <lgp-michael> oh, ok
[18:07:02] <lgp-michael> so, whats the specific issue
[18:07:36] <Rain|code> the specific issue is that I'm missing something about how should I read and store data from the stream
[18:07:45] <Rain|code> well store, more then read
[18:07:54] <lgp-michael> ok so its extracting from ffmpeg thats the issue?
[18:08:25] <Rain|code> I'm blocked exactly there
[18:08:34] <lgp-michael> ok
[18:08:49] <KittyCat> I have some code that simplifies reading audio data from ffmpeg
[18:09:07] <Rain|code> I'm realizing that I'm so confused about the problem, that I can't even explain well where it is
[18:09:16] <KittyCat> easy to extend to video as well (I just haven't had a need to implement such yet)
[18:09:37] <Rain|code> well for the video it's ok...
[18:10:31] <lgp-michael> Rain|code: ok, so in ffmpeg for video you are reading the data in frames yeah?
[18:10:40] <Rain|code> exactly
[18:10:51] <lgp-michael> ok, now, you are doing the same for audio?
[18:10:56] <Rain|code> then I put the decoded data to a texture
[18:11:04] <Rain|code> exactly
[18:11:28] <lgp-michael> ok, so you have the packet youve read using av_read_frame
[18:11:40] <Rain|code> yeah
[18:11:53] <Rain|code> if you want I can past the code...
[18:11:53] <lgp-michael> and you can convert that using avcodec_decode_audio
[18:12:05] <KittyCat> avcodec_decode_audio2
[18:12:12] <KittyCat> avcodec_decode_audio is deprecated (according to the docs)
[18:12:23] <lgp-michael> ok, Im using ffmpeg from a few years ago
[18:12:24] <Rain|code> I'm blocked exactly there
[18:12:26] <Rain|code> since
[18:12:36] <lgp-michael> I havent needed to touch my code in 3 years {:-)
[18:12:51] <Rain|code> 1) I don't know if the audio initialization I did is good also for streaming from ffmpeg
[18:13:31] <lgp-michael> ok, so you have done the avcodec_decode_audio[2] and it puts raw data into a buffer
[18:13:38] <Rain|code> 2) I don't exactly know what I have to do with the data I got from decodding...
[18:13:47] <Rain|code> not yet
[18:14:11] <lgp-michael> ok, so thas your first step
[18:14:32] *** wild13 has joined #openal
[18:14:32] *** ChanServ sets mode: +v wild13
[18:14:44] <lgp-michael> once youve used avcodec_decode_audio it is in a playable format you can use to put into an openal buffer
[18:15:00] <Rain|code> http://rafb.net/p/fAzAdd27.html
[18:15:39] <lgp-michael> ok, youd ont need to worry about frames being complete or not
[18:15:45] <lgp-michael> the data is just streamed
[18:15:46] <wild13> mornin
[18:15:54] <Rain|code> mmm
[18:16:07] <lgp-michael> its in order, what you get will be a byte-boundry correct set of data
[18:16:07] <Rain|code> you mean for audio or for video?
[18:16:11] <lgp-michael> for audio
[18:16:16] <Rain|code> ah ok
[18:16:27] <Rain|code> mmm
[18:16:30] <Rain|code> ok
[18:16:35] <lgp-michael> its one less concept to worry about
[18:16:41] <Rain|code> yeah
[18:16:50] <Rain|code> ok let me work on this first step then
[18:17:00] * lgp-michael nods
[18:18:59] <KittyCat> probably what I'd do is set up a packet queue.. one for video and one for audio. so when you go to get a video frame, you first check if there's any video packets, and if not, search for the next one from av_read_frame. any audio packets you find first go into the audio packet queue.
[18:19:05] <KittyCat> then vice-versa for audio
[18:19:31] <lgp-michael> KittyCat: the problem there is that audio and video arent synced in mpeg
[18:19:44] <lgp-michael> they have index references and stuff which you can get
[18:20:07] <lgp-michael> but if yuou just play audio when you get it and keep it synced with video you get stuffering and slowness
[18:21:30] <lgp-michael> when I did was 2 streams, open the mpeg file twice, just read out the audio until Ive filled up two al buffers, queue those, then start the video and a clock. You know what frame you should be on so you just read another frame from the video stream when you need one, and fill the next al buffer when one becomes free
[18:22:25] <lgp-michael> they keep in sync then - it MAY start to lose sync after around 2-3 minutes of play, depending on if your audio is playing at full speed and not pausing at all
[18:22:38] <lgp-michael> but Ive played videos of 30 minutes with no problem
[18:23:22] <KittyCat> the worst-case scneeria with using a packet queue is buffering all compressed audio (or video) data. but more than likely they'll be interlaced packets so you won't have much in the queue before it gets used
[18:23:27] <KittyCat> *scenerio
[18:23:31] <lgp-michael> you CAN do some bitrate calculations to ensure you are sending the right amount of data to the stream and drop some or slow the video frame counter if you need to, but for short videos its irrelavent
[18:24:07] <KittyCat> and I'd pretty much just read the audio position to tell me what "time" it is (and thus which video frame I should be displaying)
[18:24:08] <lgp-michael> KittyCat: agreed, the problem I had tho was the audio was behind the video, and so you have to buffer video frames
[18:24:30] <KittyCat> audio playback position (AL_SAMPLE_OFFSET from the AL source)
[18:24:49] *** barra_away is now known as barra_
[18:24:57] <lgp-michael> huh, I didnt know you could do that on a source that was playing multiple buffers
[18:25:20] <lgp-michael> what does it do, keep track of previous buffers and skip to where it can in existing buffers?
[18:25:27] <KittyCat> you can. though it'll be from the start of the buffers. so you'll have to keep track of a "base" time you increment every time you unqueue a buffer
[18:25:39] <lgp-michael> right thats what I was wondering
[18:25:47] <lgp-michael> yeah I knew you could in a single buffer
[18:26:03] <KittyCat> so you'd get 'curr_play_time = base_time + current_offset;'
[18:26:12] * lgp-michael nods
[18:26:37] <KittyCat> as long as the AL buffers are filled with the same amount of data each time, it's easy to calculate the base time
[18:26:48] <KittyCat> otherwise you'll have to keep track of how much you put into each buffer
[18:26:58] * lgp-michael nods, yeah
[18:27:18] <lgp-michael> thats not too hard to do, but ffmpeg doesnt give you a uniform sample size each time IIRC
[18:28:20] <KittyCat> I have some code that handles that. as well as sets up the aforementioned queues
[18:29:12] <KittyCat> the only real problem is that linux openal 0.0.8 doesn't handle the AL_*_OFFSET properties. openal-soft (which is in the process of replacing the old linux version) does, though
[18:29:58] <lgp-michael> thats a point, is it just me or is every single openal implimentation of cones on linux broken>
[18:30:15] <lgp-michael> or has that been fixed in *soft now
[18:31:10] <KittyCat> openal soft is a new implementation, based off the old windows version (which creative developed and also uses as a base for the now-closed-source windows drivers)
[18:31:33] <Rain|code> http://rafb.net/p/xaZTxs79.html
[18:31:35] * lgp-michael nods, yeah I know {:-)
[18:31:44] <Rain|code> (I'm slowing down and down...:( )
[18:31:54] <lgp-michael> I checked out cones a few months ago and no joy tho
[18:32:26] <KittyCat> hmm.. what's cones?
[18:33:09] <KittyCat> Rain|code, you need to set the outBufferSize to the size of the output buffer. the function will change it ot the amount it actually wrote
[18:33:33] <lgp-michael> KittyCat: AL_CONE_INNER_ANGLE, AL_CONE_OUTER_ANGLE, AL_DIRECTION
[18:33:55] <KittyCat> oh. they should work. though I admit I've not really tested
[18:34:12] <lgp-michael> KittyCat: basically so that you have 2 cones, say at 30 and 60 degrees from the source of the sound
[18:34:18] <lgp-michael> ok {:-)
[18:34:39] <Rain|code> KittyCat: you mean like that? int outBufferSize = packet.size;
[18:34:49] <KittyCat> no
[18:34:51] <lgp-michael> well, I'll give them another go, if they dont, I'll poke you about it, I wouldnt have a hope in hell of fixing it, but at least I can find out if they need it {;-)
[18:35:12] <KittyCat> Rain|code, you need to allocate some data for outBuffer. and set outBufferSize to that size
[18:35:37] <KittyCat> AVCODEC_MAX_AUDIO_FRAME_SIZE is the amount of bytes to allocate for the output buffer
[18:35:45] <lgp-michael> ahh, I was wondering that cos I know that the first one you have to
[18:35:50] <Rain|code> ha....so I din't undestand at al the avcodec_decode_audio2 function... :(
[18:35:55] <lgp-michael> I was thinking that in 2 you didnt
[18:35:58] <KittyCat> after the function returns, outBufferSize will be changed to the amount of data actually filled
[18:36:54] <Rain|code> ah...I thought that avcodec_decode_audio2 would have done it for me
[18:38:05] <Rain|code> http://rafb.net/p/fLSvKn72.html
[18:38:07] <KittyCat> nah. functions allocating memory for you is actually bad form (since there's multiple ways to allocate stuff.. malloc, new, HeapAlloc (windows), mmap.. could even have different heaps)
[18:38:37] <KittyCat> you're not passing outBuffer to the function :)
[18:38:37] <Rain|code> infact it sounded strabge
[18:39:06] <KittyCat> (context, outptr, outsize, inptr, insize)
[18:40:06] <Rain|code> ok infact I realized it compiling
[18:40:26] <Rain|code> so it should be ok now right?
[18:40:51] <KittyCat> you'll also need to output the decoded data somewhere, otherwise you'll leak like mad
[18:40:52] <Rain|code> http://rafb.net/p/XEvJ3a34.html
[18:41:12] <Rain|code> I guess that's the next step right?
[18:41:16] <KittyCat> use AVCODEC_MAX_AUDIO_FRAME_SIZE for the size of the output buffer, not packet.size
[18:41:27] <Rain|code> ok
[18:41:34] <lgp-michael> Yeah I have packet size as AVCODEC_MAX_AUDIO_FRAME_SIZE*3 for some reason
[18:41:38] <lgp-michael> I must have got that from somewhere
[18:42:02] <lgp-michael> erm, buffer size I mean
[18:42:04] <Rain|code> *3?
[18:42:09] <lgp-michael> dont ask me wny
[18:42:18] <Rain|code> is it a secret?
[18:42:20] <lgp-michael> I dont remember where I got *3 from
[18:42:20] <Rain|code> :P
[18:42:24] <Rain|code> hehehe
[18:42:28] <lgp-michael> but, it works {:-)
[18:42:44] <lgp-michael> I may have got it looking at sample code somewhere or other
[18:42:49] <lgp-michael> no idea where tho
[18:42:54] <Rain|code> ok ok
[18:43:40] <Rain|code> now the point is wehere do I put the decoded data?
[18:43:44] <Rain|code> into a queue?
[18:43:52] <lgp-michael> into a buffer and then queue it
[18:44:17] <Rain|code> let me undestand somthing
[18:44:33] <Rain|code> in the class Video I have a m_buffer[2] member
[18:44:54] <lgp-michael> alBufferData , alSourceQueueBuffers
[18:45:08] <lgp-michael> they are your alBuffers?
[18:45:15] <Rain|code> yeah
[18:45:19] <lgp-michael> ok
[18:45:38] <Rain|code> so I put the data there and then I enqueue?
[18:45:59] <lgp-michael> you buffer the data using alBufferData
[18:46:10] <lgp-michael> into one of those 2 buffers
[18:46:21] <Rain|code> ok
[18:46:23] <KittyCat> the buffer has to be unqueued before you can call alBufferData on it
[18:46:27] <lgp-michael> and then wnen you do that you then queue it to play on the source using alSourceQueueBuffers
[18:46:35] <KittyCat> and you can't unqueue it 'til after the source is done playing it
[18:47:16] <lgp-michael> then you look for finished buffers by alGetSourcei(yoursource, AL_BUFFERS_PROCESSED, &processed)
[18:47:35] <lgp-michael> and then you unqueue those finished buffers using alSourceUnqueueBuffers and its ready to fill again
[18:48:54] *** jvalenzu has quit IRC
[18:53:57] <KittyCat> http://rafb.net/p/0ln2qq91.html  here's the code I wrote to cleanly read data from an av file without worrying about packet sizes and what not
[18:54:45] <KittyCat> simply open a file and get a handle to it, then get an audio stream handle, get the audio info (channels, rate, etc), then get the data however you want
[18:55:08] <KittyCat> should be simple to add functions to handle the video data side
[18:55:15] <Rain|code> thanks
[18:55:22] <Rain|code> a lot
[18:55:41] <KittyCat> then use the source playback position to say when it's ready to get the next video frame
[18:56:54] <Rain|code> before taking a look to your code I would prefer to end with this because my concentration is smaller and smaller :(
[18:57:10] <Rain|code> http://rafb.net/p/7FOm2E61.html
[18:57:13] <KittyCat> it'll give you the exact amount of bytes you ask for (only less when it gets to the end of the stream, or there's an error)
[18:58:39] <KittyCat> you'd need to make sure m_buffer[0] is unqueued before calling that function, then (and there'll be issues if you get multiple audio packets in one call)
[18:59:36] <Rain|code> ...mmm....
[19:00:03] <Rain|code> I'm not sure to have understood correctly the Queue and Unqueue process then
[19:00:42] <KittyCat> basically when you queue a buffer on a source, it sets it up for the source to play
[19:00:58] <KittyCat> when the source is doing playing it, you can unqueue it, refill it with new data, then requeue it
[19:01:23] <KittyCat> when you have 2 or 3 buffers working like that, it'll give the source a continuous stream of audio
[19:01:31] <Rain|code> so the sense of having two buffer is that if oe is buisy I fill the second?
[19:01:37] <KittyCat> right
[19:02:42] <KittyCat> three buffers may be better since it'll have one playing, one ready to play, and one being filled (like triple buffering in gfx)
[19:02:57] <Rain|code> mmmm
[19:02:59] <Rain|code> ok
[19:03:30] <Rain|code> infact I was considering exactly this...now that I undestand what they are for...:)
[19:04:28] <Rain|code> how do I determines the state of a buffer then?
[19:04:58] <KittyCat> alGetSourcei(yoursource, AL_BUFFERS_PROCESSED, &processed); will return >=1 in processed when there's buffers ready to unqueue
[19:05:13] <Rain|code> cool
[19:08:46] <lgp-michael> sorry, back, work called for a moment
[19:09:04] <Rain|code> but let me understand
[19:09:18] <Rain|code> how do I determine which nuffer to unqueue?
[19:09:20] <lgp-michael> yeah, the buffers are FIFO, so the one you unqueue will always be at the end end thus empty
[19:09:41] <lgp-michael> as long as the processed query above says it is
[19:09:57] <Rain|code> so let say...I alway unqueu m_buffer[0]?
[19:10:01] <lgp-michael> so if processed returns 2 empty buffers, call the unqueue twice
[19:10:23] <lgp-michael> and it qill get the right ones, and each time you call unqueue it will give you the ID of the buffer you just unqueued
[19:10:28] <KittyCat> the one you unqueue will always be the first in the queue, which is the oldest and thus earliest done playing
[19:10:55] <KittyCat> alSourceUnqueueBuffers(source, 1, &buffer); will put the unqueued bufferid into 'buffer'
[19:11:00] <lgp-michael> no, you dont unqueue a specific buffer
[19:11:07] <KittyCat> so you can use 'buffer' to fill data and requeue
[19:11:14] <lgp-michael> you unqueue a buffer and the unqueue function tells you which one you get back
[19:11:17] <Rain|code> ha
[19:12:00] <lgp-michael> it WILL be the one you put in first, but to save you having to keep track of that, you dont need to remember
[19:14:33] <Rain|code> alGetSourcei(m_source, AL_PROCESSED, &processed); processed tells me how many buffer I can unqueue right?
[19:15:37] <Rain|code> http://rafb.net/p/EfYNgt19.html
[19:15:52] <Rain|code> (I'm re-reding what you wrote)
[19:15:58] <Rain|code> reading
[19:16:29] <KittyCat> right
[19:16:38] <KittyCat> but you can't use it if it hasn't been unqueued yet
[19:17:05] <Rain|code> are you referring to the last code I posted?
[19:17:12] <Rain|code> or in general?
[19:17:12] <KittyCat> and you only need to unqueue one at a time, not all of them that it reports
[19:17:24] <KittyCat> both
[19:17:44] <KittyCat> if a buffer is still queued to a source, you can't call alBufferData on it
[19:17:49] <Rain|code> I see...which is the point to free only one and not all that are ready to be unqueued?
[19:18:12] <KittyCat> right
[19:18:22] <KittyCat> just unqueue what you need, and leave the rest for next time
[19:18:28] <Rain|code> ok
[19:19:07] <KittyCat> outBufferSize is being set incorrectly, though
[19:19:37] <KittyCat> and you need to delete outBuffer after you call alBufferData (it makes its own copy; it doesn't keep yours)
[19:19:52] <Rain|code> ok
[19:27:36] <Rain|code> I still dont' undestand...I mean once I unqueue a buffer
[19:27:51] <Rain|code> I alwyas write to m_buffer[0]?
[19:28:06] <Rain|code> since alBufferData make its own copy?
[19:28:32] <Rain|code> (I'm really sorry to annoying you with newbie questions...)
[19:28:47] <KittyCat> it's not a problem
[19:28:51] <KittyCat> when you unqueue a buffer, it gives you the oldest one on the queue
[19:29:19] <KittyCat> so if you have, say, {buffer1, buffer2, buffer3} on the queue, alSourceUnqueueBuffer will first give you buffer1
[19:29:31] <KittyCat> the next one you unqueue will be buffer2, etc
[19:29:36] <Rain|code> yes this is clear
[19:29:38] <Rain|code> FIFO
[19:29:51] <Rain|code> but inside a loop
[19:30:07] <Rain|code> should I keep trace by myown of which index to use?
[19:30:17] <Rain|code> or al provide something to me?
[19:30:33] <KittyCat> you can just use the one returned by alSourceUnqueueBuffers
[19:30:42] <Rain|code> ah
[19:30:52] <Rain|code> it returns a buffer?
[19:30:59] <KittyCat> yeah
[19:31:03] <Rain|code> wait I re-read the doc
[19:31:29] <KittyCat> alSourceUnqueueBuffers(source, 1, &buffer);
[19:31:31] <KittyCat> alBufferData(buffer, ...);
[19:31:36] <KittyCat> alSourceQueueBuffers(source, 1, &buffer);
[19:32:14] <Rain|code> alBufferData doesn't accept  buffer[3]
[19:32:41] <KittyCat> make buffer a local variable. ALuint buffer;
[19:33:07] <Rain|code> f**K you are right
[19:33:32] * Rain|code is really upset with hisown
[19:33:57] <Rain|code> :)
[19:34:59] <KittyCat> it's a somewhat different concept for audio streaming. takes people a little bit to understand it sometimes
[19:35:38] <Rain|code> yeah...I gueass that years spent in Video Render formatted my mind
[19:35:48] <Rain|code> and that's not good :(
[19:37:04] <KittyCat> the buffer queue is pretty nice since you know exactly what to write where, will stop if it doesn't get enough data in time and can be restarted quickly (instead of causing a "loop" back through old data)
[19:37:42] <Rain|code> I'm starting to understand...it is really interesting
[19:38:37] <Rain|code> But like this in the initializatino process I have to enqueue a first buffer, right?
[19:39:06] <KittyCat> you need to queue all buffers you want to use
[19:39:26] <KittyCat> and you must fill them with data (which can be the beginning of the stream, or just silence)
[19:39:35] <Rain|code> mmmm
[19:39:41] <Rain|code> ok ...let me try then
[19:40:01] <KittyCat> and they do all need to be the same format and frequency
[19:40:13] <Rain|code> yeah
[19:43:31] *** juanmabc has joined #openal
[19:43:31] *** ChanServ sets mode: +v juanmabc
[19:43:44] <wild13> KittyCat i may need some help here in a bit
[19:44:07] <KittyCat> okay
[19:45:32] <wild13> lol whats up with windows
[19:45:34] <wild13> :/
[19:45:46] <wild13> should be easierthen this i may have a looping bug
[19:46:08] <wild13> called alSource(AL_LOOPING,false); stops the current source from looping correct?
[19:46:18] <KittyCat> right
[19:46:56] <wild13> hmm
[19:47:06] <wild13> windows guy says that when loop is called false it continues to loop
[19:47:14] <wild13> he said it could be just the mono format
[19:47:46] <KittyCat> if you continue to requeue buffers on it without filling in new data, it'll seem to loop
[19:48:10] <wild13> each object has its own 3 buffers
[19:50:34] <Rain|code> no sounds :(((((
[19:51:20] <KittyCat> did you start the source after initially queueing the buffers?
[19:51:55] <Rain|code> http://rafb.net/p/H91e9489.html
[19:51:55] <KittyCat> should also check to make sure it's still playing after queueing
[19:51:59] <Rain|code> initialization
[19:52:35] * Rain|code is ready to receive tomatoes on his face
[19:52:53] <KittyCat> should also set  alSourcei (m_source, AL_SOURCE_RELATIVE, AL_TRUE);  just in case
[19:53:41] <KittyCat> and in readFrame, after you're done queueing buffers, do something like this:
[19:53:46] <KittyCat>     ALint state = AL_PLAYING;
[19:53:46] <KittyCat>     alGetSourcei(sID, AL_SOURCE_STATE, &state);
[19:53:46] <KittyCat>     if(state != AL_PLAYING) alSourcePlay(sID);
[19:53:58] <KittyCat> where sID is your source
[19:54:25] <Rain|code> ok
[19:54:29] <Rain|code> gonna tryt
[19:54:32] <Rain|code> http://rafb.net/p/4bzUaa44.html
[19:54:44] <Rain|code> (just the readFrame)
[19:57:22] <Rain|code> no, there's no sounds... :(
[19:57:24] <KittyCat> AL_BUFFERS_PROCESSED, not AL_PROCESSED
[19:57:51] <KittyCat> AL_PROCESSED is a buffer state, which is invalid to check on a source
[19:58:01] <Rain|code> ah
[19:58:22] <Rain|code> YEAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[19:58:33] <Rain|code> YEAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[19:58:46] <Rain|code> YYYYYYYYYYYYYYYYYYYEEEEEEEEEEEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHH
[19:58:54] <Rain|code> it works
[19:58:55] <KittyCat> take it it works, then? :)
[19:59:15] <Rain|code> I don't know I to thank you
[19:59:19] <Rain|code> really
[19:59:50] <Rain|code> now I just have to slow down everythis since is going at a frame rate of 234 FPS
[19:59:51] <wild13> KittyCat you see anyting wrong wtih this
[19:59:54] <wild13> http://pastebin.com/m4e1fdc63
[20:00:28] <wild13> on why it wouldnt stop looping
[20:00:59] <KittyCat> Rain|code, there should be a way to get the video framerate. you can use that along with the time to say when to call for the next frame
[20:01:13] <KittyCat> I can't say I know how, though. I haven't gotten into the video side of avcodec yet
[20:03:20] <KittyCat> wild13, don't know. what's the code using it?
[20:04:11] <KittyCat> doppler factor and doppler velocity are listener/context properties, though, not source properties
[20:04:50] <KittyCat> doppler velocity should be considered deprecated
[20:05:07] <KittyCat> doppler factor may actually be a source property, but only if the EFX extension is present
[20:09:27] <wild13> just
[20:09:30] <wild13> the codeusing it
[20:09:34] <wild13> is
[20:12:00] <wild13> http://pastebin.com/m754dce16
[20:16:45] <KittyCat> hmm..
[20:17:03] <wild13> so far we narrowed it down
[20:17:09] <KittyCat> well, ::release isn't destroying all buffers..
[20:17:09] <wild13> to it happens only on visual studio builds
[20:17:09] <wild13> :/
[20:17:36] <KittyCat> but I'm not sure. I can't see anything wrong to cause that
[20:17:52] <wild13> hmm
[20:18:00] <wild13> were having to modify cAudios code heavily
[20:18:20] <wild13> just for visual studio support XE
[20:18:24] <KittyCat> what's audiomgr->create do?
[20:18:35] <wild13> it creates a cAudio object
[20:18:38] <wild13> and stores it in a map
[20:19:11] <KittyCat> what's the third parameter?
[20:20:20] <wild13> to stream
[20:20:22] <wild13> or not to
[20:20:43] <wild13> streaming still only works on linu
[20:20:43] <wild13> x
[20:58:22] <wild13> KittyCat: i belive visual studio support will not be as eeasy as we hoped we may not support it but if we dont we lose a lot of user base
[21:00:14] <KittyCat> does it work in mingw? and is it windows 32-bit or 64-bit?
[21:01:15] <wild13> yeah
[21:02:32] <KittyCat> yeah it works with mingw?
[21:03:28] <wild13> yeah we have it compiling with mikmod and everything under mingw
[21:03:44] <wild13> it works in 64bit linux so in assumption it will work on 64bit windows using mingw
[21:04:02] <KittyCat> iirc, mingw doesn't compile 64-bit, yet
[21:04:18] <KittyCat> and if it did, I'd imagine there's long/int size issues to work out
[21:04:42] <wild13> hmm
[21:04:57] <wild13> i dont belive cAUdio uses any ints
[21:04:57] <wild13> or longs :E
[21:05:07] <wild13> i kept everything with floats but then agin
[21:05:13] <wild13> we have been having issues i never thought off
[21:06:14] *** prophile has quit IRC
[21:06:35] *** prophile has joined #openal
[21:06:35] *** ChanServ sets mode: +v prophile
[21:15:36] <Rain|code> thanks again guys....I did a first roght synchronization and the result is really impressive...I'm going to sleep :)
[21:17:17] <wild13> night
[21:20:46] <KittyCat> 'night
[22:09:35] *** jvalenzu has joined #openal
[22:09:35] *** ChanServ sets mode: +v jvalenzu
[23:02:52] *** jvalenzu has quit IRC
[23:32:29] *** kb1ooo has quit IRC
[23:44:18] <juanmabc> hello, my sources are too far from the listener and they sound very slow, is the ROLLOFF_FACTOR the setting to change? is this also a listener propery (master) or should I set each source (which seems less logical to me)
[23:45:00] <wild13> yes
[23:45:10] <wild13> increase the rolloff factor if you need it louder
[23:45:11] <KittyCat> slow or low?
[23:45:20] <juanmabc> low :S
[23:45:37] <KittyCat> as they move away, they're supposed to quiet down
[23:46:06] <KittyCat> you can change the min and max distances on the source to change how far away it can be before it starts going quiet, though
[23:52:48] <juanmabc> KittyCat: looks good, I will try to set the min and max in the listener for master settings
[23:53:02] <KittyCat> they're source settings
[23:53:14] <juanmabc> wild13: thank you, I was decreasing it
[23:53:44] <KittyCat> changing the rolloff factor will make it sound less natural, though, and affect all sources
[23:56:47] *** jvalenzu has joined #openal
[23:56:47] *** ChanServ sets mode: +v jvalenzu
[23:59:56] <juanmabc> KittyCat: well I'm trying the obvious, increase the volume of the sources but for some reason AL_GAIN doesn't take effect





top