[00:09:44] *** KittyCat has joined #openal
[00:09:45] *** ChanServ sets mode: +v KittyCat
[00:26:21] *** angasule has joined #openal
[00:26:22] *** ChanServ sets mode: +v angasule
[00:57:26] *** kb1ooo has quit IRC
[04:00:05] *** kb1ooo has joined #openal
[04:00:05] *** ChanServ sets mode: +v kb1ooo
[04:00:49] <kb1ooo> KittyCat, you there?
[04:00:59] <KittyCat> yeah
[04:01:26] <kb1ooo> i just posted in new openal dev forum but it's not recognizing my line breaks, any ideas?
[04:01:57] <KittyCat> use <p>text here</p> to break it up into paragraphs
[04:02:13] <kb1ooo> that's annoying.
[04:02:22] <KittyCat> and make sure you stay within the outer <div></div> brackets
[04:02:26] <KittyCat> yes, it is
[04:02:32] <KittyCat> the foprums are horrible
[04:02:35] <KittyCat> *forums
[04:04:25] <kb1ooo> so have to have <div> </div> tags
[04:04:56] <KittyCat> yeah
[04:05:18] <KittyCat> you're basically hand-coding (limitted) HTML
[04:06:23] <KittyCat> <br> doesn't seem to work though, oddly
[04:12:16] <kb1ooo> so i can't click "ok" now.  Does that mean i have a formatting error.
[04:12:45] <KittyCat> hmm, don't think I've seen that problem
[04:29:06] <kb1ooo> well, got it, but missed a few lines in the formatting of the code.  I can't believe there's no preview at least.
[04:29:42] <kb1ooo> anyway,  check out my post.  it's re your C++ interface.
[04:39:21] <kb1ooo> slight modificiation of your interface to make it a bridge patter
[04:40:52] <KittyCat> hmm..
[04:42:57] <KittyCat> the thing I'm concerned about there is the destructor. since a plain (non-heap) object's destructor is automatically called when it goes out of scope, there's no way to control it (eg. safely throw/catch without leaking anything)
[04:44:33] <KittyCat> additionally, I read a page about C++ that says you can't throw from a destructor to out of it
[04:44:53] <KittyCat> which kind of causes a problem since destroying the object can fail under certain circumstances
[04:50:55] <kb1ooo> not entirely understanding.  Can you give me an example?
[04:52:36] <KittyCat> when an object is destroyed, it destroys the stream. when the stream is destroyed, it closes the input data and destroys the AL buffers
[04:53:09] <KittyCat> but if it was/is playing on a source, it has to stop the source and detach the buffers from it (or else they can't be destroyed)
[04:53:31] <KittyCat> and there's no gaurantee the correct context will be set for the source to be able to manipulate it
[04:55:50] <KittyCat> a source is only useable from the context it was created in. if the context is changed, you can't use the source
[04:56:24] <KittyCat> and if you can't use the source, you may not be able to detach the buffers to delete them (buffers cannot be attached to a source when you delete them)
[05:00:12] <kb1ooo> it seems then that there is something not quite right with the delegation of responsibility for the stream.
[05:02:07] <KittyCat> I mean.. I could say the stream must be stopped (which can cleanly fail as needed) before you destroy it. but the thought of the stream object irreversably leaking its buffers when its destroyed bothers me
[05:08:48] <KittyCat> if a function can fail, it should be able to say so and return gracefully, allowing the program to try again
[05:09:02] <kb1ooo> how does your original implementation get around this?  Sorry, I just don't know enough about OpenAL.
[05:09:38] <kb1ooo> you mean b/c you can't recover from a destructor failing?
[05:10:03] <KittyCat> currently it throws out of the destructor. since there are no on-stack objects, I believed this to mean that the object would remain valid if the exception was caught, and could be deleted again as long as the app retained a handle to it
[05:10:41] <KittyCat> it was only after I implemented that that I read that throwing out of the destructor was Very Bad, breaking all kinds of rules
[05:13:50] <kb1ooo> right, ok.
[05:26:40] *** jvalenzu has quit IRC
[05:26:47] <kb1ooo> is there no other way.  like having the stream object store the context, then while destroying the source, switch to it's context then switch back to the current context?
[05:27:13] <KittyCat> that's n ot safe since other threads may b e working
[05:27:19] <KittyCat> changing the context will change it for all threads
[05:30:36] <kb1ooo> hmm, ok.  tired here.  will sleep on it.
[06:20:14] *** Archon has joined #openal
[06:20:15] *** ChanServ sets mode: +v Archon
[06:20:18] *** Archon has left #openal
[06:24:32] * KittyCat is away: sleep
[09:24:14] *** juanmabc has quit IRC
[09:54:04] *** juanmabc has joined #openal
[09:54:04] *** ChanServ sets mode: +v juanmabc
[12:45:35] *** kb1ooo has quit IRC
[13:35:21] *** kb1ooo has joined #openal
[13:35:21] *** ChanServ sets mode: +v kb1ooo
[16:27:57] *** jvalenzu has joined #openal
[16:27:57] *** ChanServ sets mode: +v jvalenzu
[17:42:02] * KittyCat is back.
[18:56:56] <kb1ooo> KittyCat, so it seems that there are two scenarios during destruction.  Either the stream is not playing on a source, in which case the buffers can be destroyed even if the context is not correct, or
[19:00:37] <kb1ooo> the stream is playing and you need to stop the source, which requires that the correct context.  but if the stream was playing on a source, then you are queuing buffers ever 20ms or so, and if the context isn't set properly then the execption will get thrown during playing.
[19:01:19] <KittyCat> the app polls the stream which handles the queueing
[19:03:12] <kb1ooo> right, so the stream is queueing and that requires access to the source in the proper context.
[19:03:37] <KittyCat> right
[19:03:54] <kb1ooo> so that access to the source is happening every 20ms or so.
[19:04:10] <kb1ooo> while the stream is playing, that is.
[19:04:57] <KittyCat> not necesarrilly that low. the buffer could be several hundred ms long
[19:05:07] <kb1ooo> ok
[19:05:18] <KittyCat> so as long as its stopped before it empties out, there won't be a problem. and even if it does, OpenAL just stops playback
[19:05:30] <KittyCat> automagically
[19:06:21] <KittyCat> though even destroying the stream without a source on it may be a problem, if a context for a different device (or NULL) is set.
[19:06:35] <KittyCat> unlike sources it doesn't have to be the exact same context, but it must still be for the same device
[19:07:33] <kb1ooo> bbl, gotta pick up lunch.
[19:08:23] <KittyCat> really the only thing I can think to do is either expose the buffers (ugh) or just assert()/abort()
[19:28:17] *** angasule has quit IRC
[19:41:30] *** angasule has joined #openal
[19:41:30] *** ChanServ sets mode: +v angasule
[19:53:29] *** barra_away has joined #openal
[19:53:29] *** ChanServ sets mode: +v barra_away
[19:54:07] *** barra_away is now known as barra_
[19:58:35] *** angasule has left #openal
[20:38:36] *** angasule has joined #openal
[20:38:37] *** ChanServ sets mode: +v angasule
[22:22:55] *** juanmabc has quit IRC
[23:02:11] <kb1ooo> KittyCat, I think that your original solution has the same problem regardless of whether the ALUTstream object is allocated on the stack or the heap.  You'd have to prevent people from calling delete on ALUTstream objects in their destructors.
[23:07:16] *** prophile has joined #openal
[23:07:17] *** ChanServ sets mode: +v prophile
[23:34:59] *** prophile has quit IRC





top