[00:02:44] *** barra_ has quit IRC
[00:17:13] <wild> i finished
[00:19:45] *** tsaotsao has quit IRC
[00:22:05] <KittyCat> distance attenuation only works for mono sources
[00:22:37] <KittyCat> sorry, got caught up in a game
[00:24:20] <KittyCat> (i != cAudio::thevector.end()) ||cAudio::thevector.begin() == cAudio::thevector.end()  that second check is unnecessary, btw
[00:25:34] <wild> lol its done :) got full 2d and 3d support
[00:25:50] <KittyCat> you also have vector<cAudio*>::iterator i   declared twice
[00:26:23] <wild> fixe
[00:26:23] <wild> d
[00:26:39] <KittyCat> initaudio should also probably be part of the cListener class
[00:26:54] <wild> how so?
[00:27:15] <KittyCat> since cAudio is for individual sounds, while cListener is for the sound context
[00:27:33] <wild> declare it a static as well?
[00:27:43] <KittyCat> yeah
[00:28:26] <wild> so static void initAudio(){ } << inside the class
[00:28:50] <KittyCat> yeah
[00:29:09] <KittyCat> static void initAudio(int *argc, char **argv) { alutInit(argc, argv); }
[00:30:07] <wild> any other suggestions?
[00:30:17] <wild> shuttind down should be in the listener
[00:30:19] <wild> to right?
[00:32:28] <KittyCat> alutExit at least, yeah
[00:32:41] <wild> yeah i move the init and shutdown to the listener
[00:33:07] <KittyCat> don't forget to call release() on each audio object, not just the one
[00:34:53] <wild> ok
[00:35:34] <wild> hmm i can use the same iterator type thing to call release on all teh objects vector correct?
[00:36:00] <KittyCat> I think so, yeah
[00:36:55] <KittyCat> the only thing you need to be careful with about the iterator is if you delete the object. because when you delete the object it should remove itself from the list, which would invalidate the iterator
[00:37:30] <KittyCat> but your current code shouldn't have that problem since the sounds are on the local stack, not the heap
[00:37:38] <wild> alright
[00:37:40] <KittyCat> but you should change that
[00:38:09] <wild> so the iterator controling the audio = bad right now
[00:38:21] <wild> or if it were to be closed
[00:38:40] <wild> if a object were to be released?
[00:38:56] <KittyCat> calling the release() method shouldn't remove it from the iterator
[00:39:09] <KittyCat> I mean when you use delete. eg:
[00:39:16] <wild> it dosnt
[00:39:31] <KittyCat> cAudio *audio = new cAudio(); // audio is added to the list
[00:39:44] <KittyCat> delete audio; // audio is removed from the list
[00:40:07] <KittyCat> whenever the vector is added to/removed from, all iterators are invalidated
[00:40:25] <wild> then ill warn all users to only do this at the end and closing of the program
[00:41:09] <KittyCat> or just whenever there isn't an iterator
[00:41:23] <wild> sounds good
[00:41:46] <KittyCat> just say creating an object automatically adds it to the sound list, and destroying an object removes it
[00:42:01] <KittyCat> it's standard C++ that iterators are invalidated when the list changes
[00:43:13] <KittyCat> though you can also make add/remove methods to do it, instead of doing it automatically
[00:44:29] <KittyCat> and remove() could return an iterator (vector::erase returns the next iterator from the list, gauranteed to be valid)
[00:46:56] <wild> lol im realeasing a version of the engine now
[00:47:05] <wild> and im moving some more stuff up for a update :)
[00:57:39] *** prophile has quit IRC
[01:15:58] *** Walt_ has quit IRC
[01:16:26] <wild> http://www.wild.deathtouchstudios.com/ <<
[01:17:31] *** Walt has joined #openal
[01:17:32] *** ChanServ sets mode: +v Walt
[02:17:31] <angasule> KittyCat: all modified fields now enable the Apply button, and there is a working confirmation dialog for the Cancel button, the only bug left is the backend list handling.
[02:17:33] <angasule> http://www.anduin.net/~angasule
[02:17:47] <angasule> I'm off to the LUG meeting, cheers
[02:48:07] *** wild has quit IRC
[02:51:08] *** wild has joined #openal
[02:51:09] *** ChanServ sets mode: +v wild
[02:57:35] *** tsaotsao has joined #openal
[02:57:35] *** ChanServ sets mode: +v tsaotsao
[05:49:20] <angasule> KittyCat: do you know of any good sound cards for linux?
[05:51:29] <KittyCat> basically any sound card that can do multiple voices. alsa/oss can't really do much more with it than that
[05:54:18] <angasule> heard anything more about the xonar? if that thing worked with OSS drivers it'd be great :)
[05:55:04] <KittyCat> nope, though it might be a good deal if the company is linux/open-source friendly. can bug them for openal drivers, or at least the specs ;)
[05:57:01] <angasule> hmm, is asus open? I have no idea, really
[05:57:16] <angasule> oh, yeah, they kinda are, at least with the eeepc
[05:57:23] <angasule> they won't flat out refuse, at least
[05:57:39] <angasule> I'll go have dinner, 1am, bbl
[06:06:09] *** wild has quit IRC
[06:16:35] *** tsaotsao has quit IRC
[07:03:20] *** angasule has quit IRC
[09:12:56] *** Gigs has joined #openal
[09:12:56] *** ChanServ sets mode: +v Gigs
[10:56:57] *** Walt has quit IRC
[10:58:32] * KittyCat is away: sleep
[12:34:09] *** Walt has joined #openal
[12:34:10] *** ChanServ sets mode: +v Walt
[12:38:04] *** Walt has quit IRC
[13:44:28] *** kb1ooo has quit IRC
[13:50:02] *** Walt has joined #openal
[13:50:02] *** ChanServ sets mode: +v Walt
[14:55:34] *** prophile has joined #openal
[14:55:35] *** ChanServ sets mode: +v prophile
[15:02:28] *** Walt has quit IRC
[15:23:20] *** prophile has quit IRC
[16:18:32] *** Walt has joined #openal
[16:18:32] *** ChanServ sets mode: +v Walt
[16:38:23] *** tsaotsao has joined #openal
[16:38:24] *** ChanServ sets mode: +v tsaotsao
[16:55:25] *** angasule has joined #openal
[16:55:25] *** ChanServ sets mode: +v angasule
[17:37:03] *** wild13 has joined #openal
[17:37:03] *** ChanServ sets mode: +v wild13
[18:01:14] *** neric has quit IRC
[18:05:02] *** neric has joined #openal
[18:05:02] *** irc.freenode.net sets mode: +v neric
[18:05:07] *** neric has quit IRC
[18:05:10] *** neric has joined #openal
[18:05:11] *** ChanServ sets mode: +v neric
[18:22:21] <wild13> mornin
[18:54:27] <Gigs> hi
[19:09:02] <wild13> whats up?
[19:33:55] *** prophile has joined #openal
[19:33:55] *** ChanServ sets mode: +v prophile
[21:00:50] *** kb1ooo has joined #openal
[21:00:50] *** ChanServ sets mode: +v kb1ooo
[21:01:29] <Gigs> Mostly lost.  Documentation isn't super. :P
[21:04:03] <wild13> maybe i can help
[21:04:21] <wild13> whats the problem?
[21:04:41] <Gigs> hmm where to start
[21:04:58] <wild13> mean code wise?
[21:05:37] <Gigs> ok well we are doing a software synthesis of dynamic wind sound in second life
[21:05:58] <wild13> alright
[21:06:05] <Gigs> there is code to do it with openAL but it was very crackly.  I tried to fix it and it broke worse :P
[21:06:17] <wild13> well it sounds simple enough
[21:06:21] <Gigs> it was very fragile and nasty code
[21:06:31] <wild13> yu got your listener and the wind is the object
[21:06:38] <wild13> id say something like a doppler effect would work
[21:06:56] <Gigs> well the software synth is doing the pitch
[21:07:10] <Gigs> hmm let me paste a line that will show you the idea
[21:07:15] <wild13> alright
[21:07:18] <Gigs> alBufferData(wind_buffers[counter],AL_FORMAT_STEREO16,windDSP((void*)gWindData,gSamplesPerBuffer/2),gSamplesPerBuffer,44100);
[21:07:32] <Gigs> windDSP returns the synthesized sound data
[21:07:46] <Gigs> so openal doesn't need to do anything too fancy here
[21:07:49] <wild13> id say the easiest thing to do would to be just recode the thing
[21:08:01] <wild13> but use the code you found as a reference
[21:08:03] <Gigs> yeah
[21:08:11] <Gigs> once I touched it though it crashes
[21:08:23] <Gigs> backtrace shows the crash in libpthread but it seems to be openAL
[21:08:46] <KittyCat> windDSP doesn't return newly-allocated memory, does it? openal does not keep the memory segment you pass to it (it makes its own copy)
[21:08:50] * KittyCat is back.
[21:09:06] <wild13> gigs here is a person who can solve it XD
[21:09:08] <Gigs> gWindData is malloc'ed in an init function
[21:09:14] <KittyCat> plus, which version of openal are you using?
[21:09:19] <Gigs> it's what is returned
[21:10:13] <Gigs> hmm hard to tell because the lib build with 0.0.0 on the end of it :P
[21:10:54] <Gigs> I got the newest download I think
[21:11:06] <Gigs> one second
[21:11:16] <Gigs> 0.0.8
[21:12:50] <Gigs> I don't know if this is a red herring, but this is the line that seems to cause the crash most often
[21:12:51] <Gigs> alSourceQueueBuffers(wind_sources[0], NO_WIND_BUFFERS, wind_buffers);
[21:13:09] <Gigs> But it's not entirely consistant because the segfault is actually coming from another thread
[21:13:11] <angasule> Gigs: that's /old/, several years old
[21:13:29] <angasule> KittyCat: you don't have @ here? the link to openal-soft should be in the topic
[21:13:32] <Gigs> angasule: really?  It's what is on openal.org
[21:13:37] <KittyCat> yes, you should try openal soft instead
[21:13:40] <Gigs> oh
[21:13:42] <Gigs> ok
[21:13:49] <angasule> Gigs: that site is old as well
[21:14:19] <Gigs> ok
[21:14:23] <KittyCat> the download page of openal.org (which recently got redirected to the revamped site) should have openal soft
[21:14:50] <Gigs> I don't think so
[21:14:53] <Gigs> http://www.openal.org/downloads.html
[21:14:58] <Gigs> this is all the old stuff
[21:15:16] <angasule> KittyCat: still points to the old site :/
[21:15:17] <KittyCat> hmm.. odd
[21:15:24] <KittyCat> I could've sworn it was redirected before
[21:15:44] <KittyCat> http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx
[21:16:33] <Gigs> what are distros doing these days
[21:16:42] <Gigs> like does OS X have the Soft version?
[21:16:54] <wild13> soft comes with the next debian andubuntu realeases
[21:17:21] <Gigs> ok as long as it's all compatible, this code will need to link with system-level openal on OS X
[21:17:22] <KittyCat> gentoo has ebuilds slowly working their way into portage
[21:18:27] <KittyCat> OpenAL Soft doesn't not yet work on OSX. but the API is 100% compatible, so if you code for one, it'll work on the other (as long as you don't rely on undefined behavior)
[21:18:36] <Gigs> I'll try not to :P
[21:23:20] <Gigs> Well back to the topic, I admit that I really don't understand what's going on here.
[21:23:37] <wild13> with?
[21:23:42] <Gigs> I understand sources and listeners, but I don't really get the buffers and the way the actual data moves
[21:23:56] <Gigs> buffers appear to be just integers and they count down from 32768?
[21:24:00] <Gigs> what's the point of that
[21:24:35] <wild13> if im correct the buffer holds the data in those integers and then the data is inturpeted
[21:24:40] <wild13> then again :/
[21:24:52] <Gigs> but it's just an integer, how can an integer hold data :P
[21:25:04] <wild13> 0-0\
[21:25:11] <wild13> everything is in the forms of numbers
[21:25:22] <wild13> data is just a squence of 1's and 0's
[21:25:37] <wild13> ons and offs *i may be going to far into it*
[21:25:42] <Gigs> I mean if my first buffer is "my_buffer" and it's say 32112, and I jam 4096 bytes of data into it, where does that allocation come from
[21:26:11] <Gigs> this goes back to kitty's initial comment which I think is probably related to this
[21:27:12] <Gigs> alBufferData, is it allocating "size" bytes?  or size*format bytes?
[21:27:29] <wild13> that i cant tell you..
[21:27:43] <Gigs> I find a lot of basic examples of loading a wav file for openal but once you get into these details the documentation is lacking :P
[21:27:44] <wild13>  my openal knowledge is limited to what i need to know to use it
[21:28:05] <Gigs> It's probably simpler than I am making it out to be.
[21:28:14] <wild13> yeah..
[21:28:19] <wild13> www.devmaster.net/articles/openal-tutorials/lesson1.php
[21:28:23] <Gigs> Anyway I have a dentist appointment so I need to take off for a while but I'll stay idle in here.
[21:28:35] <wild13> my knowledge consists of those tutorials and everything kittys taught me
[21:28:53] <Gigs> bbl, feel free to reply while I'm gone and I'll see it later
[21:40:48] <KittyCat> alBufferData takes the size in bytes
[21:41:43] <KittyCat> which is kinda bass-ackwards to the rest of the API that takes samples/frames, but that's how it is..
[21:48:17] <kb1ooo> Gigs, I think your asking standard audio waveform questions?   A buffer in OpenAL stores an audio waveform.  What you physically manipulate as a client is an integer handle to the buffer data.
[21:50:02] <kb1ooo> best to think of it as an object, as in OOP.
[21:50:36] <kb1ooo> since you are streaming, a good example is lesson8.
[22:00:11] *** tsaotsao has quit IRC
[22:01:34] <kb1ooo> e.g., you can think of wind_buffers[0] as a pointer to an internal openal buffer an audio waveform.  The data is assigned to the internal buffer from the alBufferData call, which tells it to assign the data returned from windDSP to the internal buffer.
[22:02:01] <kb1ooo> similarly, wind_buffer[1] will be a pointer to another waveform.
[22:02:16] *** tsaotsao has joined #openal
[22:02:16] *** ChanServ sets mode: +v tsaotsao
[22:03:36] <kb1ooo> windDSP returns PCM data.   Google PCM to find out more about it.
[22:16:27] *** angasule has quit IRC
[22:23:21] *** Walt has quit IRC
[22:30:56] *** barra_away has joined #openal
[22:30:57] *** ChanServ sets mode: +v barra_away
[22:36:08] *** tsaotsao has quit IRC
[22:39:59] *** barra_away is now known as barra_
[22:45:19] *** juanmabc has quit IRC
[22:56:58] *** tsaotsao has joined #openal
[22:56:58] *** ChanServ sets mode: +v tsaotsao
[23:08:07] *** angasule has joined #openal
[23:08:07] *** ChanServ sets mode: +v angasule
[23:31:21] *** angasule has quit IRC





top