• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

185 Neutral

About KCat

  • Rank
  1. OpenAL distance fade

    0x1103 is AL_FORMAT_STEREO16, which explains why it's not fading with distance (though I don't know why the freq is set to that; make sure you're using the right order). You'll have to use your favorite wave editor to make the sounds you want 3d-ized to be mono instead of stereo. Background music and local-only sounds (those which never 'move' away from the listener) can stay stereo, though. The reference distance is the distance at which a source's volume will typically be at the loudest. If the source and listener are 'reference distance' units apart, or closer, the source will play at its set gain as determined by the source's AL_GAIN setting.
  2. OpenAL distance fade

    Double-check the format of the sounds. They should be AL_FORMAT_MONO8 (0x1100) or AL_FORMAT_MONO16 (0x1101), otherwise they won't attenuate. If that's properly set, then what happens if you change the AL_MAX_GAIN source property to 0.5? Also, alSourcei(m_Source, AL_REFERENCE_DISTANCE, m_maxGain); // 1.0f infering what I can from this line, it isn't completely correct. The reference/minimum distance isn't dependant on the source's max gain. Changing the reference distance between 0 and 1 won't do much at this scale (except for 0, where it disables attenuation).
  3. OpenAL distance fade

    Are you perhaps setting AL_SOURCE_RELATIVE? What kind of scale does your gameworld have (ie. are you actually moving things out to near 1000 units, or keeping them within 10 or 100)? Are you changing the alDistanceModel? Also, stereo sounds do not attenuate. Only mono sounds. If you're still having problems it might be helpful to see some code.
  4. OpenAL distance fade

    The reference distance is typically the distance where the source will be loudest. So if you, say, set the reference distance to 2 and the max gain to 0.8 for the source, if the listener is 2 units or closer to the source, the playback volume for the source will be at 0.8. The problem with setting the reference distance to 0 is because of the inverse distance math. The math for getting the attenuation is: flAttenuation = MinDist / (MinDist + (Rolloff * (Distance - MinDist))); (where Rolloff is the rolloff factor, which can be used to strengthen or weaken the distance attentuation, and MinDist is the reference distance) If the reference distance was 0, that would cause the math to be 0/x, which would always be 0 (or worse, if the distance was also 0, you'd get 0/0). A reference distance of 0 makes mathmatically no sense because, as in real-life, you can't be listening directly at the point where a sound eminates from. Setting the reference distance to something >0 and clamping solves this issue.
  5. OpenAL distance fade

    The distances, not the volumes (the default volumes are generally fine). Unless you set the rolloff factor to 0 (default is 1), set the distance model to none (default is inverse distance clamped), set the reference distance to > max distance, or something else that would cause the attenuation math to fail (which you have to be pretty explicit about to do, usually). Just don't set the reference distance to 0.
  6. OpenAL distance fade

    You also need to set the source's distances. // The distance that the source will be the loudest (if the listener is // closer, it won't be any louder than if they were at this distance) alSourcei(source, AL_REFERENCE_DISTANCE, 1.0); // The distance that the source will be the quietest (if the listener is // farther, it won't be any quieter than if they were at this distance) alSourcei(source, AL_MAX_DISTANCE, FLT_MAX); The given values in that example are the defaults. As the listener moves between the reference and max distances from the source, the perceived volume will increase and decrease accordingly. And being that the max distance defaults to FLT_MAX, that's really far so it won't seem to quiet much as it moves away. Setting more reasonable max distances for the sources will make the distance fading more apparent (exactly what values are reasonable depends on your unit scale and how far away you'd prefer the sounds to be heard).
  7. It sounds like your card is set to capture the output, and OpenAL is selecting that capture device. You can call const char *str = alcGetString(NULL, ALC_CAPTURE_DEVICE_SPECIFIER); to get a list of capture devices (each name seperated by a NULL and the string ended by two NULLs), and you can pass one of those names to open a different capture device. There could be a mixer setting to select a different capture source too, but I'm unsure of how that all works.
  8. When you stream in OpenAL, it doesn't have much of a concept of "beginning" and "end". Rewinding the source doesn't do much because the beginning is actually the oldest queued buffer that wasn't unqueued, and the end is the last queued buffer. To loop a stream in anything, OpenAL or whatever, you simply need to rewind the decoder when it runs out of data, and continue feeding the stream as you left it. So it's basically something like this: /** Start Stream **/ OpenDecoder(); ret = DecodeData(buf, BUFFER_SIZE); alBufferData(buffers[0], format, buf, ret, frequency); ret = DecodeData(buf, BUFFER_SIZE); alBufferData(buffers[1], format, buf, ret, frequency); if((ret=alGetError()) != AL_NO_ERROR) { fprintf(stderr, "Error loading, %#04x :(\n", ret); return 1; } alSourceQueueBuffers(source, 2, buffers); alSourcePlay(source); if(alGetError() != AL_NO_ERROR) { fprintf(stderr, "Error starting :(\n"); return 1; } /** Update Stream **/ ALuint buffer; ALint val; alGetSourcei(source, AL_BUFFERS_PROCESSED, &val); if(val <= 0) continue; /* For each processed buffer... */ while(val--) { /* Read the next bit of decoded data */ ret = DecodeData(buf, BUFFER_SIZE); if(ret == 0) { if(Looping) { /* End of Stream; restart decoder */ CloseDecoder(); OpenDecoder(); ret = DecodeData(buf, BUFFER_SIZE); } if(ret == 0) break; } alSourceUnqueueBuffers(source, 1, &buffer); alBufferData(buffer, format, buf, ret, frequency); alSourceQueueBuffers(source, 1, &buffer); if(alGetError() != AL_NO_ERROR) { fprintf(stderr, "Error buffering :(\n"); break; } } /* Make sure the source is still playing, and restart it if * needed. */ alGetSourcei(source, AL_SOURCE_STATE, &val); if(val != AL_PLAYING) alSourcePlay(source);
  9. Quote:Original post by tasen Thanks for the reply. I checked and I don't have the dll directory as you say (I re-downloaded the latest SDK to make sure). The only DLLs I could find were the ogg/vorbis ones included in the samples directory. Odd. Well, if you're on XP, the redistributable should have installed openal32.dll and wrap_oal.dll into C:\Windows\system32. You can just copy them out of there. I'm not sure where Vista has them install too, but I'd assume something similar.
  10. Generally, you'll want to package the redistributable installer with your app, then as part of your app's installation, run the OpenAL installer with the /s (silent) switch.. that'll make sure OpenAL is installed on the system and has the latest version (and if the user already has it installed, it'll simply update if needed). If you want to package the DLLs and have your app use them without installation, the DLLs are in the SDK, extracted in "OpenAL 1.1 SDK\dll". Put those two .dll files in a sub-directory of your app (not the same dir as the exe, otherwise it'll always take precedence over a version the user may have installed). Then when your app loads, use an option to check whether to load (via LoadLibrary) the system's openal32.dll, or the one with your app. You'll then have to load the function pointers with GetProcAddress/alcGetProcAddress. The first method is preferred as it will a) make sure the user has OpenAL installed, so your app can use it fine as-is, b) install it for the whole system, so other apps can use it too, and c) make sure the user is updated to the latest version available at the time it was packaged with your app.
  11. You have to figure it out from the byte length. But it's pretty simple, as long as you're loading them with normal PCM data: ALfloat GetBufferLength(ALuint buffer) { ALint size, bits, channels, freq; alGetBufferi(buffer, AL_SIZE, &size); alGetBufferi(buffer, AL_BITS, &bits); alGetBufferi(buffer, AL_CHANNELS, &channels); alGetBufferi(buffer, AL_FREQUENCY, &freq); if(alGetError() != AL_NO_ERROR) return -1.0f; return (ALfloat)((ALuint)size/channels/(bits/8)) / (ALfloat)freq; }
  12. Is OpenAL dead?

    For anyone interested, OpenAL Soft's GIT repo now has a branch with preliminary EFX support. More info is available on the mailing list post here: http://opensource.creative.com/pipermail/openal-devel/2007-December/004985.html
  13. Is OpenAL dead?

    Quote:Original post by phantom Khronos is split into working groups; so if they did take on OpenAL for example, the working group for that would have no direct ties (and thus no impact on) the development of their other APIs. I see. Well, I took a look at khronos.org, and a quick search for OpenAL brings up a few forum posts asking for its adoption, but I didn't see any response from Khronos members. Quote:On windows, does OpenAL Soft build as an Enumeratable dll? So, if I was to build it and drop the dll into my apps dir, then grab a list of OpenAL 'devices' would it show up along side the Creative ones I have installed? An enumeratable DLL is a regular OpenAL DLL, just with a different filename. By default OpenAL Soft builds as openal32.dll in Windows (the only dll that apps are directly concerned about), but simply renaming it to soft_oal.dll, or any name that ends in oal.dll, and putting it somewhere in the DLL search path should automatically add OpenAL Soft devices along side an existing list. Relating to that topic though, it may be confusing to users to see OpenAL Soft's device names next to the device names in the wrap_oal.dll driver Creative ships in their redistributable. The names shouldn't clash, however.
  14. Is OpenAL dead?

    Quote:Original post by remdul Thanks for your comments Chris. Your work is very much appreciated. I will most certainly be switching to OpenAL Soft. :) I hope it works out for you. :) Feel free to ask questions if anything comes up. Quote:Has Creative ever had talks with Khronos Group? Not as far as I'm aware, but then, I didn't even know the Khronos Group existed until the news that they were getting the OpenGL API from the ARB. I'm sure quite a lot of their attention has been towards the GL3 API, anyway.
  15. Is OpenAL dead?

    Hello. Found this thread through a discussion in #openal on Freenode. :) Quote:Original post by Roots I don't think OpenAL is dead. Its just somewhat stagnant and slow developing because of Creative's tight grip over it. I wouldn't even say that. It's somewhat stagnant sure, but the very latest open source sources have always been available from their SVN repo. As it says on the downloads page, first thing under the OpenAL Source Code heading: Quote:The OpenAL source code is available via Subversion from http://www.openal.org/repos/openal. Links to Subversion clients can be found on the links page. From the command line, you can do the following to retrieve the current trunk: svn checkout http://www.openal.org/repos/openal/trunk openal The very latest Linux/Unix version, based off the original Loki implementation, is there (under OpenAL-Sample), as well as the Apple-controlled OSX code (whether or not it's the actual code as shipped with the Mac, I have no idea), and the latest Creative-controlled Windows code (before it closed up). Even FreeALUT is there (under alut). All of it under the LGPL.. except the OSX version which actually seems to be under an X11-like license. The only thing stopping anyone from working on it (improving the code, creating extensions) is that no one wants to. Quote:Also I don't think its easy to contribute to the OpenAL source unless you work at Creative, and do only the things that Creative wants you to do with the code. Not entirely true. I can't say the same about the Windows or OSX code, but ever since Loki went belly-up, the Linux/Unix code (the "Sample Implementation") has been an entirely open-source community driven project. The only direct ties Creative has with it are that, besides controlling the core API, the mailing list and repo used for its development are on their servers. But no one's prevented from trying to move it elsewhere if there was a benefit from doing so, and they could convince the maintainers (who don't work at Creative, btw). When I started with the OpenAL code, I initially tried to work on cleaning up the SI. The only troubles I had with submitting patches was that the maintainers were very busy and don't have much time to dedicate to OpenAL. But even still, because I was doing so much work on it, after a few months the maintainers asked if I wanted write access to the SVN repo. I said sure, and after Daniel Peacock (the guy at Creative in charge of the SVN repo's access control) came back from his vacation, I got it. No hassles. I've since decided that the SI is more or less a lost cause, which is what lead me to fork the original Windows code as a pet project. And while I have no intention of moving development of OpenAL Soft away from repo.or.cz (I like GIT too much), it's likely that Creative's OpenAL repo, which I still have write access to, will hold a mirror of the main development branch of OpenAL Soft as the "new" SI. I've also been told that Creative would likely have no problems hosting downloads of the SI at openal.org, as releases are tagged and put together (the last release, 0.0.8, is there). As for EAX/EFX, IP, and patents, last I knew, Creative is under a will-not-enforce agreement of its patents against open source projects. I have expressed my desire for implementing EFX in OpenAL Soft multiple times on their mailing list, and they've never said I can't or shouldn't. Though if you need/want to go commercial, I don't know the situation (eg. if you're allowed to use a lib that implements EFX, as long as your product doesn't use it; it'd be kind of silly to not allow that, though). Quote:1.1 is the version of the current OpenAL specification, and 0.0.8 is AFAIK the version of their (SI?) implementation. 0.0.8 is the release version of the SI, which implements most, but not all, of the 1.1 spec. The two numbers have no other correlation. (OpenAL Soft implements all of the 1.1 spec, btw). And an interesting idea to toss out there, for those who want to see OpenAL evolve.. perhaps some people could get together to form an not-for-profit open-source Foundation or Group specializing in audio design and APIs, and ask Creative if they can help control the API and feature set as it goes into the future. Who knows.. I'm sure Creative is feeling a nice pinch from consumers not caring much about audio cards these days, and not being near the top in the professional market. Perhaps someone to help push the OpenAL API forward is something they want, and that we'd all benefit from. - Chris, OpenAL Soft maintainer
  • Advertisement