[00:00:17] <wild13> alext ?
[00:00:27] <KittyCat> vorbis/vorbisheader.h
[00:00:36] <wild13> ahHA
[00:00:40] <wild13> i dont have that header
[00:00:48] <wild13> can you pastebin it
[00:01:44] <KittyCat> vorbis/vorbisfile.h I mean, sorry
[00:02:00] <wild13> its there XE
[00:02:06] <wild13> maybe mine are outdated
[00:19:58] <wild13> KittyCat can you upload your precompiled libogg and libvorbis for  me
[00:20:57] <KittyCat> you don't have them?
[00:21:21] <wild13> i have a old version
[00:21:27] <wild13> and compiling it on windows is driving me crazy
[00:21:33] *** prophile has quit IRC
[00:22:10] <wild13> the headers lib and dlls if you could
[00:22:20] <wild13> http://filebin.ca/ << upload there
[00:22:51] <KittyCat> http://kcat.strangesoft.net/ogg-libs-bin.zip  for windows..
[00:23:05] <KittyCat> they're kind of old, though
[00:23:23] <wild13> i got the ones from the devmaster tutorials
[00:39:59] <wild13> kitty i looked threw all the headers in vorbis and there is no mention of
[00:40:03] <wild13> OV_CALLBACKS_DEFAULT
[00:40:19] <KittyCat> might've been a later addition
[00:41:05] <wild13> any idea were i can find precompiled versions of the new vorbis
[00:41:30] <KittyCat> http://rafb.net/p/CN7VIr70.html
[00:42:13] <wild13> ...
[00:42:17] <wild13> were do i puts it XD
[00:42:30] <KittyCat> anywhere
[00:42:45] <KittyCat> after including vorbisfile.h and stdio.h
[01:04:15] *** wild13 has quit IRC
[01:06:13] *** Alam_Debian has quit IRC
[01:28:38] * KittyCat is away: sleep
[01:33:43] *** Alam_Debian has joined #openal
[01:33:43] *** ChanServ sets mode: +v Alam_Debian
[01:53:08] *** wild13__ has joined #openal
[01:53:09] *** ChanServ sets mode: +v wild13__
[01:53:15] <wild13__> KittyCat are you bizzy?
[02:11:57] <wild13__> is ther eanything else i have to change after doing ov_open_callbacks
[02:24:45] <DragonRift> any sexy coder honeys here?
[02:24:45] <DragonRift> :p
[02:25:02] <DragonRift> I think coder chicks are hawt
[02:25:03] <DragonRift> :p
[02:44:14] <wild13__> ...
[02:44:29] <wild13__> KittyCat after doing the OV_CALLBACKS_DEFAULT
[02:44:38] <wild13__> i dont get streaming sound on windows im all out of ideas
[02:47:25] <DragonRift> hi wild13__
[02:47:26] <DragonRift> wasap man
[02:47:30] <DragonRift> other then openal
[02:51:07] <wild13__> im going crasy
[02:51:16] <wild13__> this shouldnt have been a problem but it is XE
[02:59:55] <wild13__> dragonrift how fluent are you in openal?
[03:00:27] <wild13__> DragonRift?
[03:18:10] <DragonRift> I'm not even a coder
[03:18:14] <DragonRift> I am a project director
[03:18:25] <DragonRift> PR/business man
[03:18:56] <DragonRift> I have a team of people who code for me
[03:19:08] <wild13__> ahh
[03:19:09] <DragonRift> sorry wild13__
[03:19:36] <DragonRift> a couple weeks away from a working prototype of my engine
[03:19:37] <DragonRift> :)
[03:19:49] <wild13__> cool
[03:19:54] <DragonRift> yeah
[03:19:56] <DragonRift> a 3d mmorpgmaker
[03:20:01] <wild13__> 0-0\\
[03:20:13] <DragonRift> what
[03:20:29] <wild13__> how many people on this dev team of yours
[03:20:41] <DragonRift> 4 coders and 7 years dev in
[03:20:45] <DragonRift> 265k$ invested
[03:20:55] <wild13__> 0-0\
[03:21:00] <DragonRift> and were almost at 0.2.0
[03:21:07] <wild13__> nice
[03:21:19] <DragonRift> the core mechanics are almost completed
[03:21:29] <DragonRift> speedtree for foliage
[03:21:31] <DragonRift> deferred shading
[03:21:37] <DragonRift> shader driven pipeline
[03:21:42] <DragonRift> EAX audio
[03:21:54] <wild13__> wow
[03:21:59] <DragonRift> seamless disk paged terrain
[03:22:05] <DragonRift> rayleigh scattered sky
[03:22:08] <DragonRift> particle clouds
[03:22:19] <DragonRift> parallel split shadow maps
[03:22:23] <DragonRift> HDR
[03:22:40] <wild13__> commercial app i assume?
[03:22:45] <DragonRift> indeed
[03:22:55] <DragonRift> the maker is to be used inhouse
[03:23:24] <DragonRift> my artists who start soon were the guys who did the gfx in elephants dream
[03:23:37] <DragonRift> the blender movie
[03:23:47] <DragonRift> and my lead artist works for pixar
[03:23:50] <wild13__> o wow :)
[03:24:11] <DragonRift> the software will be free for windows linux and mac
[03:24:17] <DragonRift> and will be 10$ a month to play the game
[03:24:43] *** barra_ has quit IRC
[03:24:50] <DragonRift> requires dualcore or better and Nvidia gfx card thats a geforce 6 or newer
[03:25:03] <DragonRift> reason I say geforce
[03:25:07] <DragonRift> is because ati drivers suck
[03:25:14] <DragonRift> the cards crash constantly
[03:25:25] <DragonRift> so if ATI improves there badly designed drivers
[03:25:28] <DragonRift> they will work too
[03:25:41] <wild13__> lol
[03:26:03] <wild13__> sounds cool :0
[03:26:24] <DragonRift> its not that were against ati
[03:26:29] <DragonRift> its just nvidia is superior
[03:26:46] <DragonRift> we support GPU and PPU physics
[03:27:00] <DragonRift> all CUDA based cards
[03:27:10] <DragonRift> like the new GTX 240 and GTX 280
[03:27:25] <DragonRift> state of the art
[03:27:41] <DragonRift> we may even make CUDA a req
[03:28:06] <DragonRift> if we do that
[03:28:07] <DragonRift> http://www.nvidia.com/object/cuda_learn_products.html
[03:28:13] <DragonRift> these will all be what works
[03:28:23] <wild13__> awsome
[03:28:31] <wild13__> how long till you relaese the engine?
[03:29:54] <DragonRift> the engine itself will be 800k$ +10% royalty or 1.5 Million for royalty free
[03:29:55] <DragonRift> per title
[03:30:46] <DragonRift> but will allow companies to make a WoW grade mmo with Call of Duty 4 grade rendering
[03:30:49] <DragonRift> in like 3 months
[03:31:10] <wild13__> 0-0\
[03:31:57] <DragonRift> drag and drop game creation
[03:32:02] <DragonRift> script and code generation
[03:32:11] <DragonRift> point and click and manual scripting
[03:32:17] <DragonRift> point and click shader creation
[03:32:24] <DragonRift> biomechanical ai to help animating
[03:32:32] <wild13__> wow goign all out ehh
[03:32:37] <DragonRift> digital mollectular matter for physics
[03:32:42] <DragonRift> thats the point
[03:32:50] <DragonRift> all these game companies take no pride
[03:33:04] <DragonRift> they just keep doing the same things
[03:33:08] <DragonRift> over and over and over
[03:33:13] <DragonRift> and mmo games never get these techs
[03:33:17] <DragonRift> its always offline games
[03:33:23] <DragonRift> like Assassin's Creed
[03:33:43] <DragonRift> our goal is to make a next gen MMO Engine like no one has seen ebfore
[03:33:50] <DragonRift> before
[03:34:38] <DragonRift> now that nvidia owns physx
[03:34:46] <DragonRift> its now a industry standard for nvidia based games
[03:36:51] <DragonRift> http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=3930691&CatId=3669
[03:36:53] <DragonRift> for example
[03:37:00] <DragonRift> this nvidia card has Integrated PhysX
[03:37:07] <DragonRift> and the driver for it works on windows linux and mac
[03:37:33] <DragonRift> and it supports TRI SLI
[03:44:30] 
[03:44:30] <DragonRift> Delivering physics in games is no easy task. It's an extremely compute-intensive environment based on a unique set of physics algorithms that require tremendous amounts of simultaneous mathematical and logical calculations.
[03:44:30] 
[03:44:30] 
[03:45:02] <wild13__>  :)
[03:45:06] <wild13__> that must make life very easy
[03:46:01] <DragonRift> yes and no
[03:46:10] <DragonRift> we have excluded about 60% of the current market
[03:46:10] <DragonRift> :/
[03:46:32] <DragonRift> and 5.5 Billion users excluded
[03:49:08] <wild13__> damn that really sucks
[04:50:37] <DragonRift> in 1-3 years
[04:50:50] <DragonRift> we will only be excuding less the 20% of the market
[04:52:30] <wild13__> its a good trade off
[06:33:49] <wild13__> ;(
[06:37:29] *** jvalenzu has joined #openal
[06:37:29] *** ChanServ sets mode: +v jvalenzu
[06:38:22] <wild13__> hi
[06:42:55] *** DragonRift has quit IRC
[07:06:43] *** jvalenzu has quit IRC
[07:35:24] *** wild13__ has quit IRC
[10:19:19] * KittyCat is back.
[14:04:12] *** arke has joined #openal
[14:04:13] *** ChanServ sets mode: +v arke
[14:05:08] *** juanmabc has joined #openal
[14:05:09] *** ChanServ sets mode: +v juanmabc
[14:05:54] <arke> HI.
[14:06:01] <arke> argh
[14:06:04] *** kb1ooo has quit IRC
[14:06:09] <arke> Hi. (damn sticky shift key)
[14:12:21] <KittyCat> hi
[14:20:25] *** lubos has joined #openal
[14:20:25] *** ChanServ sets mode: +v lubos
[14:24:42] *** juanmabc has quit IRC
[14:29:36] *** lubos has quit IRC
[15:17:32] *** prophile has joined #openal
[15:17:32] *** ChanServ sets mode: +v prophile
[15:46:13] *** juanmabc has joined #openal
[15:46:13] *** ChanServ sets mode: +v juanmabc
[15:47:01] *** Alam_Debian has quit IRC
[15:48:32] *** kb1ooo has joined #openal
[15:48:32] *** ChanServ sets mode: +v kb1ooo
[15:56:15] *** Alam_Debian has joined #openal
[15:56:15] *** ChanServ sets mode: +v Alam_Debian
[16:46:29] *** LtJax has joined #openal
[16:46:29] *** ChanServ sets mode: +v LtJax
[16:46:57] *** LtJax has quit IRC
[16:49:27] *** jvalenzu has joined #openal
[16:49:27] *** ChanServ sets mode: +v jvalenzu
[16:53:23] <arke> Anybody familiar with the effects extension?
[16:54:40] <KittyCat> a bit
[16:55:51] <arke> hmm
[16:55:55] <arke> I'm reading through the guide a bit
[16:56:09] <arke> it strikes me (as far as I can tell) that it's not possibleto create a chain of effects
[16:56:50] <arke> since the effect slots seem to always mix directly to the output
[16:58:17] <KittyCat> yeah, you can't currently feed an effect slot output to another effect slow
[16:58:34] <arke> ugh
[16:58:38] <arke> :(
[16:58:59] <KittyCat> efx isn't too useful without hardware support, though
[16:59:09] <KittyCat> filter chains are usually accomplished in software
[16:59:19] <arke> well, I'm not opposed to it either way
[16:59:24] <arke> err, wrong window
[16:59:35] <arke> hmm
[16:59:44] <arke> so I guess I need to implement the effects myself afterall :)
[16:59:52] <KittyCat>  what effects?
[17:00:20] <arke> just some basic effects
[17:00:28] <arke> chorus, reverb, distortion, the usual
[17:00:34] <arke> then again
[17:01:08] <arke> I gotta look in our documentation, I don't think there has to be support for multiple chained effects
[17:01:17] * arke shrugs
[17:02:36] <KittyCat> you can mix some effects a bit. though it's mainly limited to using a low/hi/band pass filter on an effect slot
[17:08:53] <arke> Another, unrelated question - is there a way to get some sort of stream time or number of samples elapsed or something similar from an output device?
[17:09:33] <KittyCat> not from the output device, no. but you can from playing samples
[17:10:08] <arke> How?
[17:10:36] <KittyCat> alGetSourcei(source, AL_SAMMPLE_OFFSET, &numframes);
[17:10:52] <arke> Aah, perfect.
[17:11:02] <KittyCat> gives the number of samples played from the beginning of the buffer
[17:12:01] <KittyCat> alGetSourcef(source, AL_SEC_OFFSET, &fTime); for time in seconds.. though it has floating point inaccuracey issues if you need to be precise
[17:12:59] <arke> Great, thanks!
[17:13:29] <arke> And another one - if I don't explicitly use the 3D positioning stuff, will it still use overhead?
[17:13:43] <KittyCat> note that on looping sources, they reset back to 0 when they loop
[17:13:50] <arke> Right.
[17:14:10] <KittyCat> you may somewhat. depends on the format
[17:14:33] <arke> STEREO16, most likely
[17:14:48] <KittyCat> setting the distance model to AL_NONE will help a little. non-mono sounds will skip by the 3d stuff
[17:15:36] <KittyCat> setting source-relative mode for the sources will also help
[17:15:52] *** wild13 has joined #openal
[17:15:52] *** ChanServ sets mode: +v wild13
[17:20:57] *** jvalenzu has quit IRC
[17:21:33] <wild13> hi
[17:22:28] <KittyCat> hi
[17:22:44] <wild13> KittyCat /me thansk teh heavens
[17:23:06] <wild13> is there something else other then the ov_open_callbacks change
[17:23:25] <wild13> is there anything else i needed to do to the code i put that in and it compiles but i get no audio]
[17:23:31] <KittyCat> shouldn't be
[17:23:34] <KittyCat> paste the code
[17:24:22] <wild13> http://pastebin.com/m2c1f71f
[17:24:25] <wild13> open stream function
[17:26:10] <KittyCat> where did you define OV_CALLBACKS_DEFAULT?
[17:26:25] <wild13> i have a compiled version of the newest
[17:26:30] <wild13> vorbis
[17:26:33] <wild13> so its in the header
[17:26:59] <wild13> like i said it compiles but i get no sound
[17:27:06] <arke> IIRC OV_CALLBACKS_DEFAULT is vorbisfile speak for use FILE*
[17:27:35] <arke> eh
[17:27:37] <arke> nope :P
[17:27:39] * arke looks at the paste
[17:27:48] <KittyCat> yeah
[17:27:57] <KittyCat> he's doing that because of windows' deficiency
[17:28:10] <arke> aah, right
[17:28:25] <KittyCat> but he's not getting any playback in linux with that, though ov_open with the same params worked fine
[17:28:52] <KittyCat> wild13, does it work in windows?
[17:28:52] <arke> o.O
[17:28:57] <wild13> if you need the cAudio header ill throw it up
[17:29:12] <wild13> it works in linux
[17:29:12] <wild13> but now windows :E
[17:29:14] <wild13> not*
[17:29:36] <KittyCat> ov_open_callbacks works in linux, but not windows?
[17:29:41] <wild13> yeah
[17:29:42] <wild13> the irony
[17:29:48] <arke> hah
[17:30:12] <KittyCat> Windows is using an up-to-date DLL?
[17:30:19] <wild13> i just installed the runtime
[17:30:22] <wild13> newest
[17:31:11] <wild13> im about to try the dlls you sent me
[17:32:38] <wild13> nothing
[17:33:10] <wild13> http://www.rarewares.org/ogg-libraries.php
[17:33:15] <wild13> downloading the ones found here
[17:33:57] * arke shrugs
[17:34:01] *** barraAway has joined #openal
[17:34:01] *** ChanServ sets mode: +v barraAway
[17:34:48] *** barraAway is now known as barra_
[17:35:02] <wild13> if its a dll issue ill kill a man
[17:38:36] <wild13> i threw in a the new dll renamed it to vorbis.dll
[17:38:54] <wild13> now im getting a cannont locat libmmd.dll
[17:41:51] <wild13> KittyCat do you think its a dll issue?
[17:59:53] <KittyCat> no idea, honestly :/
[18:00:41] <wild13> damn XE
[18:01:56] <wild13> :'(
[18:03:48] <KittyCat> might be a better idea to learn ffmpeg
[18:04:04] <KittyCat> get a whole bunch of formats through one api with that
[18:04:39] <wild13> 0_0\
[18:05:00] *** angasule has quit IRC
[18:05:00] <wild13> i have my mind set on getting openal up and running
[18:05:01] *** angasule_ has joined #openal
[18:05:01] *** ChanServ sets mode: +v angasule_
[18:05:17] <wild13> is it possible to use ffmpeg with openal?
[18:05:19] <KittyCat> it's a little tricker to use, but I have some code that makes it rather easy
[18:05:24] <KittyCat> yup
[18:05:30] <KittyCat> I'm doing that in OpenMW
[18:05:55] <KittyCat> or rather, I should say, I did that for OpenMW
[18:06:26] <wild13> 0_0\
[18:13:06] <wild13> isnt a dll issue
[18:14:33] *** angasule__ has joined #openal
[18:14:33] *** ChanServ sets mode: +v angasule__
[18:15:31] <wild13> is ffmpeg crossplatform?
[18:15:59] <KittyCat> looks like it
[18:16:13] <wild13> what formats does it support?
[18:17:52] <KittyCat> http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/avcodec_8h.html#0c33394cb3458990f80b53c83ebe25f4  is a list of codec ids
[18:18:21] <KittyCat> not all of them may work, and some don't work very well. but there's a number of useable ones there
[18:19:00] <wild13> like?
[18:19:06] <wild13> lol the big thing i need is ogg support
[18:19:15] <KittyCat> that's there
[18:19:49] <wild13> can you show me some example code so i can get it up and running?
[18:22:41] <KittyCat> http://rafb.net/p/fBrZ0C71.html
[18:22:41] <arke> Ugh.
[18:22:57] <arke> I just noticed I need to be able to synchronize stuff from Audio
[18:23:07] <arke> taht was easy with PortAudio
[18:23:12] <arke> but -
[18:23:20] <arke> how could I approach this with OpenAL?
[18:24:26] <KittyCat> use the current audio/source position to syncronize what you need
[18:25:14] *** arke_ has joined #openal
[18:25:14] *** ChanServ sets mode: +v arke_
[18:25:20] <arke_> gah.
[18:25:21] <KittyCat> alGetSourcei(source, AL_SAMPLE_OFFSET, &offset);
[18:25:30] <KittyCat> frame = offset * fps / freq;
[18:25:42] <arke_> what I meant to say - in PortAudio, I delayed the start of the video by the audio latency
[18:25:47] <arke_> that worked perfectly
[18:25:51] <KittyCat>  would give you the corresponding frame for the currently sample position
[18:25:55] *** angasule_ has quit IRC
[18:26:04] <arke_> is that compensated to the audio latency?
[18:26:09] <arke_> s/to/by
[18:26:37] <KittyCat> depends on the latency you're talking about
[18:26:41] <arke_> well
[18:26:49] <arke_> ideally, the latency would be low enough to not notice ;)
[18:26:54] <arke_> which is one of the things I'm testing
[18:27:11] <KittyCat> the latency of the hardware buffer, no. but then that's supposed to be as small as possible anyway.
[18:27:22] <arke_> right. does OpenAL adjust that automagically?
[18:27:31] <KittyCat> the latency of the source buffer, yes. the size of the buffer won't affect the playback position latency
[18:27:41] <arke_> Right.
[18:27:46] <arke_> Well, gotta hope it works out ;)
[18:27:55] <KittyCat> it should
[18:28:31] <KittyCat> openal needs to work fairly in sync with video/graphics anyway. and it needs a small update buffer to do that
[18:28:52] * wild13 crys
[18:31:55] <KittyCat> ?
[18:32:25] * wild13 kicks windows PIECE OF SHIT....cAudio works in mac,linux,unix,bsd and soloris
[18:32:34] <wild13> and i lose one function in windows
[18:32:57] <KittyCat> heh. welcome to the world of software development ;)
[18:33:16] <KittyCat> I'm really surprised developers continue to stick to windows
[18:33:47] <arke_> best development tools ;)
[18:33:52] * arke_ hugs visual studio
[18:34:39] <arke_> I don't suppose there's an easier way to route the captured stuff to the output than making a source and queueing buffers on it?
[18:35:30] <KittyCat> other than having the hardware itself do it, not really
[18:39:44] * arke_ tries doing that
[18:40:52] <KittyCat> th at's not really a solution for something you'll have other people use, though. since it means changing the hardware volu me controls, which is a pretty big no-no
[18:41:25] <arke_> ah, I meatn making a source
[18:41:29] <arke_> :)
[18:42:30] <KittyCat> there isn't. but it's not that hard, really
[18:43:08] <arke_> Right. Just trying to understand the exact semantics of the QueueBuffer stuff, then I'll try it.
[18:43:55] <KittyCat> query the number of capture samples available. if > 0, read the data, put it into an AL buffer, queue the buffer on a source, and make sure the source is playing
[18:44:40] <wild13> KittyCat : two people reported using ov_open worked for them on windows
[18:45:26] <KittyCat> it might work for some people. the issue comes in if your app links against different libs than vorbisfile.dll
[18:46:22] <KittyCat> eg. if you use debug multithreaded, and vorbisfile uses release non-threaded
[18:46:26] <KittyCat> or something along those lines
[18:47:03] <wild13> i dont have a vorbisfile.dll
[18:47:11] <wild13> nvm i do
[18:48:12] <wild13> how do i find out what thread the dll uses?
[18:48:14] <arke_> No need to unqueue or anything?
[18:48:42] <KittyCat> arke_, yeah, you should unqueue buferrs and reuse them if possible
[18:49:24] <KittyCat> ideally you'd probably buffer 3 or 4 "silent" buffers onto a source and start it playing
[18:50:02] <KittyCat> then you check for th e number of captured samples, etc. and when you go to write it to a buffer,you unqueue one from the source
[18:50:48] <arke_> hmm
[18:50:50] <arke_> so
[18:51:03] <arke_> alcGetIntegerv(inputDevice, ALC_CAPTURE_SAMPLES, 1, &nSamples);
[18:51:32] <arke_> hmm
[18:51:42] <arke_> say I queue { 1, 2, 3, 4 } as buffers
[18:52:14] <arke_> aah
[18:52:16] <arke_> nevermind
[18:52:54] <arke_> if { 1, 2 } are there, then { 3, 4 } is queued, then the state is { 1, 2, 3, 4 }, and then if one is unqueued, it's { 2, 3, 4 }
[18:52:56] <arke_> >_<
[18:53:00] * arke_ should learn reading :)
[18:54:03] <KittyCat> then you buffer 1, and requeue it, so the source would have { 2, 3, 4, 1 }
[18:54:24] <KittyCat> the next bit of data would then make it { 3, 4, 1, 2 }
[18:54:27] <KittyCat> and so on
[18:58:51] <KittyCat> http://rafb.net/p/50TKjy56.html  something like that should work
[18:58:53] <arke_> makes sense
[18:59:02] <arke_> though ... 3 buffers should be enough, I think
[18:59:19] <arke_> aah, beautiful
[18:59:20] <arke_> thanks!
[18:59:57] <wild13> :( my engine is completly broken on windows 3d sound dosnt work ethier
[19:02:12] <KittyCat> no 3d at all?
[19:02:19] <KittyCat> not even panning?
[19:02:43] <wild13> it plays 2d
[19:03:00] <wild13> ive never encountered anything like this
[19:03:13] <KittyCat> creative's software driver only does stereo output
[19:04:28] <wild13> how do i get the 3d working
[19:04:32] <wild13> switch to a diffrent driver?
[19:05:02] <KittyCat> what os/hardware?
[19:05:07] <wild13> vista
[19:05:14] <wild13> probley integrated crap
[19:05:27] <KittyCat> you'll need to use openal soft, then
[19:05:36] <wild13> openal soft is on windows?
[19:05:41] <KittyCat> vista ditched accelerated dsound, so creative's hardware wrapper won't work
[19:05:49] <KittyCat> it works on windows
[19:06:53] <wild13> link to openal soft compiled version?
[19:07:35] <wild13> a compiled version saves me the long tedious process of downloading cmake etc..
[19:08:44] <KittyCat> there isn't one, unfortunately :/
[19:08:51] <wild13> can you make one
[19:09:14] <KittyCat> I can try..
[19:09:18] <wild13> thanks ;)
[19:11:29] <arke_> here's another question
[19:11:34] <arke_> though, I can guess the answer
[19:11:53] <arke_> WASAPI on windows vista ;)
[19:12:43] <KittyCat> is anyone even using wasapi?
[19:12:57] <KittyCat> wild13, getting the dcc request?
[19:13:14] <arke_> no idea, but it's integrated in Vista, so a backend for OpenAL shouldn't be out of the questino, I think...
[19:13:50] *** angasule__ is now known as angasule
[19:13:58] <KittyCat> don't think it offsers much more than what dsound provides. dsound still exists, it's just software mixed
[19:14:36] <arke_> WASAPI is supposed to provide a much lower latency
[19:14:55] <KittyCat> does it do 3d?
[19:15:09] <arke_> not sure.
[19:15:18] <KittyCat> hardware accelerated 3d sound
[19:15:28] <KittyCat> without that, it's not too useful for openal
[19:15:33] <arke_> I think so, though I'm not sure.
[19:17:21] <wild13> no im not kitty :/
[19:17:57] <KittyCat> are you registered and indentified with the network?
[19:18:06] <KittyCat> *identified
[19:18:07] <wild13> yeah but im on irssi
[19:18:19] <arke_> dcc should work on irssi
[19:18:21] * arke_ shrugs
[19:19:13] <arke_> darn, not hearing anything.
[19:22:21] <wild13> can you upload to your site kitty?
[19:24:45] <KittyCat> http://kcat.strangesoft.net/soft_oal.dll.bz2
[19:29:00] <wild13> kitty how do i specify it to use
[19:29:02] <wild13> openal soft
[19:29:10] <wild13> throw the dll with the exe?
[19:29:28] <KittyCat> yeah
[19:29:37] <arke_> I'm aware of the flaws, just trying to hack for now: http://rafb.net/p/KVqDWj37.html
[19:30:01] <arke_> I can step through the audioThread thread just fine
[19:30:01] <wild13> i hope to god this works
[19:30:13] <KittyCat> you'll also need to create/edit %AppData%\alsoft.ini (where %AppData% is your user's application data directory)
[19:30:50] <KittyCat> and add the line format=AL_FORMAT_51CHN16 for 5.1 output
[19:33:05] <wild13> kitty cat it didnt work :(
[19:33:31] <KittyCat> try naming it openal32.dll, in case it's trying to select a different device.
[19:33:59] <wild13> still playing full 2d
[19:34:03] <wild13> no 3d what so ever
[19:34:39] <KittyCat> that should work..
[19:35:03] <KittyCat> you are using a mono source, right?
[19:36:00] <wild13> mono source?
[19:36:02] <KittyCat> arke_, looks good to me
[19:36:09] <KittyCat> mono data/buffer
[19:36:23] <wild13> im not sure
[19:36:28] <wild13> should i take off the else stereo
[19:36:30] <wild13> buffer?
[19:36:51] <KittyCat> hmm, actually. arke_ there's a couple things..
[19:38:04] <KittyCat> arke_, you'll want to set AL_LOOPING to false. requeueing the buffers will keep it going with new data.
[19:38:27] <KittyCat> you also may need to call alBufferData with some silence before queueing them onto the source
[19:39:01] <arke_> Aah, it works
[19:39:18] <arke_> don't know which it was, but I set AL_LOOPING to false and I added a alSourcePlay call after the queue
[19:39:23] <wild13> KittyCat i forced it to use mono and it worked
[19:40:20] <KittyCat> with AL_LOOPING true, AL_BUFFERS_PROCESSED will never return anything other than 0
[19:41:31] <arke_> KittyCat, it did, though
[19:41:37] <arke_> KittyCat, 2, then 1, then 0
[19:41:42] <arke_> was silent though
[19:41:45] <KittyCat> hm, what OS?
[19:42:15] <arke_> XP :)
[19:42:35] <KittyCat> the old linux openal is buggy and will return other values. but it's not supposed to
[19:42:52] <KittyCat> creative's windows drivers shouldn't, though
[19:43:36] <KittyCat> and in your audioThread, you may want to add this, just after buffering and queueing the data:
[19:43:37] *** angasule_ has joined #openal
[19:43:37] *** ChanServ sets mode: +v angasule_
[19:43:37] *** angasule has quit IRC
[19:43:42] <KittyCat> alGetSourcei(sources[0], AL_SOURCE_STATE, &state);
[19:43:45] <KittyCat> if(state != AL_PLAYING) alSourcePlay(sources[0]);
[19:45:23] <wild13> kittycat why the hell is it in slowmo
[19:45:31] <KittyCat> hm?
[19:45:44] <wild13> well i have it working with mono
[19:45:50] <wild13> but its in slow mo
[19:46:05] <KittyCat> if it's stereo data, because it's reading through the data half as fast
[19:46:33] <wild13> but when i use stereo
[19:46:35] <wild13> it isnt 3d
[19:46:51] <KittyCat> if it's stereo, you'll need to use an audio editor to convert it to mono
[19:47:00] <wild13> has to be mono?
[19:47:06] <KittyCat> for 3d, yeah
[19:47:15] <wild13> how come it works in linux fine
[19:47:21] <wild13> with stereo
[19:47:34] <KittyCat> broken linux implementation ;)
[19:47:51] <wild13> what?
[19:47:52] *** angasule__ has joined #openal
[19:47:52] *** ChanServ sets mode: +v angasule__
[19:48:16] <KittyCat> the old openal si will add 3d spatialization to non-mono sources. but it shouldn't
[19:48:42] <wild13> why shouldnt it
[19:48:43] <KittyCat> projecting stereo sounds into 3d space doesn't make too much logistical sense
[19:48:46] <wild13> that a amazing feature
[19:49:04] <KittyCat> and the spec says it shouldn't
[19:49:27] <KittyCat> openal soft and the implementations don't
[19:49:36] <KittyCat> nor dsound3d
[19:49:50] <wild13> that is really werid
[19:50:51] <angasule__> wild13: you can deinterleave (I probably made up that word :P ) and then spatialise each mono stream
[19:51:17] <angasule__> honor honour color colour, silly spellchecker is still broken
[19:51:34] <KittyCat> yeah. would be nice if openal had a way to buffer individual channels from interleaved data, but oh well. need to copy it to a temp buffer.
[19:52:27] <wild13> so kitty if i forced a mono into a stereo source
[19:52:29] <wild13> it would play 2d?
[19:53:24] <KittyCat> it would play without spatialization (and fast), yeah
[19:53:48] <angasule__> KittyCat: and extention :)
[19:54:47] <KittyCat> angasule__, perhaps. won't be too useful if you can't rely on it, though
[19:55:30] <arke_> well, it's working, though I'm fightign with soem sort of times-two bug
[19:55:49] <arke_> setting the buffer sizes to 2048 causes 2048 samples to be silent and 2048 to have signal ;)
[19:56:24] <angasule__> KittyCat: non-windows games may not care
[19:56:48] <KittyCat> arke_, the openal buffers resize automatically when you give it new data
[19:57:23] <arke_> I meant my own buffer plus what I give alCaptureOpenDevice
[19:57:41] <wild13> KittyCat tell me there is a way to convert stereo to mono on the fly
[19:58:53] <KittyCat> poor man's converter: specify half the channels and double the frequency ;)
[19:59:03] <arke_> hah! :D
[19:59:09] <wild13> code plz XD
[19:59:20] <wild13> or just the snipits i would need to pull it off
[19:59:23] <arke_> won't sound right with sounds that have stereo fx though
[19:59:49] <arke_> wild13, interleaved stereo data?
[20:00:01] <arke_> wild13, if so, take two samples, add them, and you've got one mono sample
[20:00:13] <wild13> hmm
[20:00:39] <arke_> while(nSamples--) { out[0] = in[0] + in[1]; out++; in += 2; }
[20:00:42] <arke_> something like that
[20:00:57] <KittyCat> (l+r)*sqrt(1/2), actually
[20:01:08] * wild13 dies
[20:01:09] <arke_> ah, you're right.
[20:01:45] <arke_> M_SQRT_2, IIRC
[20:01:48] <arke_> err
[20:01:50] <arke_> no :P
[20:02:20] <wild13> ok now how to pull this off with vorbis
[20:02:21] <wild13> :E
[20:02:32] <arke_> well, vorbis gives you a nicely interleaved buffer
[20:02:53] <arke_> :)
[20:03:30] <wild13> how to access thsi nicely interleaved buffer?
[20:03:37] *** angasule_ has quit IRC
[20:03:45] <arke_> ov_read, of course!
[20:04:04] <arke_> (...IIRC)
[20:04:45] <angasule__> brb
[20:04:53] *** angasule__ has quit IRC
[20:05:19] * arke_ opens our production codebase to take a look
[20:07:17] <arke_> ah, I changed it to use ov_read_float
[20:08:00] <wild13> in windows in my open i have ov_open_callbacks
[20:08:07] <wild13> and for the last parameter vorbisCallbacks
[20:08:14] <wild13> so it looks like
[20:08:16] <arke_> eh
[20:08:17] <arke_> welll
[20:08:23] <arke_> you gotta get the actual audio data somewhere
[20:08:29] <arke_> meaning, ov_read or ov_read_float
[20:09:46] <wild13> i have a custom VorbisRead function dosnt call ov_read anywere
[20:10:17] <KittyCat> you get the audio data from ov_read
[20:10:33] <wild13> whoops found it
[20:10:34] <KittyCat> the callbacks are only used to supply libvorbisfile with the file data. it doesn't give you the audio data
[20:10:55] <wild13> forgot stream is called in both functions :E
[20:11:18] <wild13> how would i modifiy ov_read to use th interlaced buffer?
[20:11:48] <KittyCat> ov_read gives you the interlaced buffer
[20:14:36] <wild13> ok
[20:15:44] <wild13> ov_read gives me the buffer and i need to convert a stereo to mono and you said (l+r)*sqrt(1/2)
[20:15:49] <wild13> is how i owuld get this?\
[20:16:36] <arke_> yeah, but
[20:16:51] <arke_> remember that you're getting 8 or 16 bit samlpes, not float samples
[20:17:19] <KittyCat> length /= 2;
[20:17:24] <KittyCat> for(i = 0;i < length/2;i++)
[20:17:39] <KittyCat>   ((short*)data)[i] = (((short*)data)[i*2] + ((short*)data)[i*2 + 1]) * sqrt(1/2);
[20:18:21] <arke_> that isn't gonna work ;)
[20:18:34] <KittyCat> some extra clamping may be required
[20:18:53] <arke_> not just
[20:19:06] <arke_> he'd have to either convert to float or do the sqrt(1/2) differently
[20:19:18] <KittyCat> or just use 0.5 instead of sqrt(1/2).. good enough, and won't risk overflow
[20:19:24] <KittyCat> he shouldn't need to
[20:19:37] <KittyCat> the sqrt() is just providing a scalar
[20:19:45] <arke_> well yeah
[20:19:56] <arke_> ah
[20:19:59] <arke_> ignore me, I'm an idiot
[20:19:59] <KittyCat> so the 16-bit range input, translates into a 16-bit output
[20:20:06] <arke_> Yes
[20:20:08] <arke_> >_<
[20:20:10] <arke_> <-- brain damaged
[20:20:30] * wild13 still dosnt know what any of this means
[20:21:27] <KittyCat> you're probably better off just editing the sound file to be mono. assuming you can find an audio editor that can do vorbis
[20:21:44] <wild13> audacity
[20:21:44] <arke_> audacity can, IIRC
[20:21:55] <arke_> aargh, where is my evil *2 bug >_<
[20:22:13] *** angasule has joined #openal
[20:22:13] *** ChanServ sets mode: +v angasule
[20:22:16] <wild13> problem is the users will want to put a stereo sound into 3d
[20:22:26] <KittyCat> no they won't
[20:22:33] <KittyCat> if they do, they'll be told the same thing as you
[20:23:01] <KittyCat> stereo sounds don't get spatialized. I don't know of any audio api that allows it
[20:23:38] <angasule> fmod allows it, I think, though I think it's ugly to do it
[20:24:22] <KittyCat> it does full 3d spatialization on stereo samples?
[20:24:38] <KittyCat> or just panning + volume control?
[20:26:20] <arke_> how nice, no mention of ALC_CAPTURE_SAMPLES in the docs
[20:26:37] <arke_> hah
[20:26:37] <angasule> I think spatialization, but it requires telling it how separated or something, I didn't really read on it, since fmod is closed source
[20:26:43] <arke_> becuase it's mispelled, heh
[20:27:36] <KittyCat> angasule, ah. it probably breaks it into 2 mono sources for you, then.
[20:27:50] <KittyCat> still an odd and unwieldy thing to do, though
[20:27:57] <angasule> KittyCat: yeap, fmod is really a layer on top of openal, I think
[20:28:11] <KittyCat> hm, really?
[20:28:13] <angasule> KittyCat: their features look that way, at least
[20:28:25] <KittyCat> I think it uses alsa with its own 3d mixer
[20:28:39] <KittyCat> alsa, oss, dsound, and dsound3d
[20:28:43] <angasule> ah
[20:28:59] <angasule> well, probably it's based off ds3d just like openal and hence the similarities
[20:29:19] <KittyCat> would be nice if it used openal, though
[20:29:20] <angasule> but it's higher level than openal, some people might not want to go that high
[20:34:21] <arke_> argh
[20:34:37] <arke_> KittyCat, I get dropouts at intervals of my internal temporary buffer size o.O
[20:35:33] <KittyCat> hmm.. try queueing 3 or 4 buffers, and use a larger capture size (256 is kinda small, I think)
[20:35:57] <arke_> capture size is up to a second ;)
[20:36:04] <arke_> and I'm queueing 3 buffers atm
[20:36:13] <arke_> and I commented out SwitchToThread
[20:36:17] <arke_> and running in Release mode :/
[20:36:46] <angasule> try more, but smaller, buffers?
[20:37:06] <arke_> AAH
[20:37:13] <arke_> I think I found the bug
[20:39:25] <arke_> nope
[20:39:29] <arke_> that wasn't it >_<
[20:39:49] <wild13> dammit :/ fixed the 3d soudn issue with the engine but still no streaming support
[20:40:15] <KittyCat> arke_, try waiting for more samples before queueing
[20:40:37] <KittyCat> eg. if(nSamples > 1024) instead of if(nSamples > 0)
[20:40:52] <arke_> good idea
[20:40:54] * arke_ tries
[20:41:03] <arke_> same deal
[20:42:16] <KittyCat> how about 2048, and with 3 queued buffers?
[20:43:02] <arke_> same deal
[20:43:03] <arke_> :(
[20:44:00] *** wild13 has quit IRC
[20:44:16] *** wild13 has joined #openal
[20:44:17] *** ChanServ sets mode: +v wild13
[20:50:34] <KittyCat> that's odd. that should give you at least a 16KB playback buffer
[20:50:42] <arke_> yeh
[20:51:08] <KittyCat> paste your latest code?
[20:51:17] <arke_> reworking a bit, one sec...
[20:53:09] <arke_> http://rafb.net/p/PJO0Fk88.html
[20:53:20] <arke_> (i put everything in audioThread for simplicity)
[20:54:28] <KittyCat> you'll want a larger capture buffer
[20:55:02] <KittyCat> should probably be double from what you check against
[20:55:34] <KittyCat> alcCaptureOpenDevice(NULL, 44100, AL_FORMAT_MONO16, BUF_SIZE*2);
[20:55:36] <KittyCat> ...
[20:55:39] <KittyCat> if(nSamples >= BUF_SIZE)
[20:55:40] <KittyCat> ...
[20:56:08] <arke_> I had everythign at 176400 earlier ;)
[20:56:30] <arke_> anyway, same thing again
[20:56:40] <KittyCat> but if the capture buffer and what you're waiting for are the same size, capturing will stall regardless of the actual size
[20:56:51] <arke_> right
[20:57:36] <arke_> I put that back on 0
[20:58:23] <KittyCat> with 0, it may be filling the buffers too small
[20:59:09] <arke_> shouldn't matter, since it can't fill a buffer until one is free anyway
[21:00:46] <KittyCat> but one may not come free until it plays through them all (because they're so short, they may be streamed in one shot)
[21:01:36] *** juanmabc has quit IRC
[21:01:50] <KittyCat> like if you have 3 ~256 byte buffers, and the driver does a 1024 byte update..
[21:02:07] <arke_> roit...
[21:02:25] <arke_> well it's not the problem either way, unfortunately...
[21:02:32] *** juanmabc has joined #openal
[21:02:32] *** ChanServ sets mode: +v juanmabc
[21:03:31] <KittyCat> unfortunately I've not played with capture before. I don't have a mic or anything
[21:03:50] <arke_> :(
[21:03:54] <arke_> thanks for the help anyway
[21:17:29] <wild13> KittyCat i got a new error
[21:18:18] <KittyCat> hm?
[21:18:27] <wild13> well i replaced
[21:18:34] <wild13> OV_CALLBACKS_DEFUALT
[21:18:50] <wild13> ehh
[21:18:53] <wild13> ill show you
[21:20:40] <wild13> http://pastebin.com/mc23f809
[21:20:43] <wild13> openstream function
[21:21:08] <wild13> when i put vorbisCallbacks into the ov_open_callbacks i get shit meaning it didnt get any data correct?
[21:22:37] <KittyCat> you're not setting vorbisCallbacks to anything
[21:22:51] <KittyCat> except in open(), where you set them to the memory functions
[21:23:17] <wild13> o ok i see
[21:23:40] <wild13> nvm then sigh was just a hopefull new error
[21:23:54] <wild13> OV_CALLBACKS_DEFAULT dosnt work :/
[21:27:14] <arke_> AH
[21:27:19] <arke_> KittyCat, I think I have found a clue
[21:27:27] <arke_> err
[21:27:50] <arke_> yes
[21:28:13] <arke_> alSourcePlay never actually causes the state to change to AL_PLAYING
[21:29:57] <arke_> AL_INVALID_OPERATION
[21:30:04] <arke_> so there's no current context ... yes there is o.O
[21:30:33] <KittyCat> ah, right. you're queueing incomplete buffers
[21:30:59] <KittyCat> it can't play until it has at least one buffer with a format
[21:31:05] <arke_> alBufferData doesn't make compelte buffers? :/
[21:31:11] <arke_> ah
[21:31:12] <arke_> AH
[21:31:13] <arke_> >_<
[21:33:48] <arke_> STILL THE SAME THING ARGH
[21:34:23] <KittyCat> error or skipping?
[21:34:26] <wild13> arke welcome to my world
[21:34:30] <arke_> skipping
[21:34:31] <arke_> no error
[21:34:36] <arke_> hmm
[21:34:48] <arke_> well if I can't get this working tonight, I'll have to look for alternatives tomorrow :/
[21:35:11] *** jvalenzu has joined #openal
[21:35:11] *** ChanServ sets mode: +v jvalenzu
[21:35:17] <KittyCat> try checking the source state when nBuffersProcessed is 0
[21:35:26] <KittyCat> instead of after queueing
[21:36:35] <arke_> hmm
[21:36:39] <arke_> same thing still
[21:36:42] <arke_> but
[21:36:50] <arke_> since it steps into that if every time
[21:37:00] <arke_> if(i != AL_PLAYING)
[21:37:03] <arke_> ... there's something wrong.
[21:40:14] <arke_> argh
[21:40:26] <arke_>  I get AL_INVALID_VALUE on the first alSourcePlay
[21:42:05] <arke_> and how great
[21:42:16] <arke_> the docs don't even say that it's possible for it to return AL_INVALID_VALUE
[21:42:23] <arke_> ah
[21:42:27] <arke_> it's probably for a previous call
[21:43:54] <wild13> im trying to cout my buffers
[21:44:00] <wild13> ethier the cout isnt owkring or the buffers are empty
[21:47:08] <wild13> KittyCat the buffers are empty
[21:47:57] <arke_> here's another thing
[21:48:04] <arke_> 50% of the time I hear something, 50% of the time I don't
[21:49:29] <arke_> but hey
[21:49:34] <arke_> almost no dropouts!
[21:57:38] <arke_> hmm
[21:57:41] <wild13> well now
[21:57:55] <wild13> i got to the point were the data dosnt go into the buffer nore is it read
[21:57:59] <wild13> even though the file is opened
[21:58:11] <arke_> Argh
[21:58:16] <arke_> this is an even bigger problem
[21:58:19] <arke_> and a red flag raiser
[21:58:25] <arke_> half the time, everything is silent
[21:58:35] <arke_> I only hear myself half the time tryign to start the exe
[22:03:07] <KittyCat> how do you mean?
[22:03:09] *** jvalenzu has quit IRC
[22:03:17] <arke_> nevermind, bug of mine ;)
[22:03:26] <arke_> it's all working now and I'm trying to get the latency down
[22:04:30] <arke_> ok
[22:04:36] <arke_> not a bug of mine, just happened again
[22:04:44] <arke_> occasinally, everything will appear to work fine, but it's silent
[22:04:45] <arke_> :/
[22:05:00] <arke_> tbh, I'm really not too confident about using OpenAL
[22:05:15] <arke_> that, plus that I can't reallly push the latency down very far just capturing one mike...
[22:05:57] <KittyCat> hmm. paste your latest code?
[22:09:45] <arke_> http://rafb.net/p/Xkf0ia94.html
[22:09:51] <arke_> that already has artifacts
[22:10:19] <arke_> I'm gonna take a look if changing the thread priority helps, but ...
[22:11:28] *** wild13 has quit IRC
[22:12:56] <KittyCat> move the source state check to if nBuffersProcessed is not > 0
[22:14:21] <arke_> no difference
[22:14:23] <arke_> :/
[22:20:27] *** arke_ has quit IRC
[22:36:18] *** wild13 has joined #openal
[22:36:18] *** ChanServ sets mode: +v wild13
[22:48:48] *** juanmabc has quit IRC
[23:47:20] <wild13> cant figure out why the buffers dont get filled
[23:58:03] *** kb1ooo has quit IRC





top