|
|
|
[
Permlink
| « Hide
]
Tofu Linden added a comment - 14/Nov/07 04:29 AM
nag!
Ah screw it, I'm attaching the current patch as is. It completely usurps fmod, so that will have to be fixed for LL to be happy with it. But it works, and it has changed little since I first wrote it, before reading the coding standards. Looks like I get extra credit for using std::string.
 Oh yeah, there's a totally bogus patch to llaudiodecodemgr.cpp in there. It turns out the written WAV files are broken, and FreeALUT rejects them. The length fields are off by something like 8-10 bytes. Thing is the code looked correct to me, but it apparently isn't. To get things working I just bumped the fields by that much.
Also, wind noise and music streaming are missing. Wind noise may be a bit tricky to do as OpenAL doesn't seem to be designed with callbacks in mind. Music streaming should probably be stubbed over to the LLMedia class, but as gstreamer doesn't seem to be working for me I can't do much with that until gstreamer is fixed.
As poor Seg can't get fedora to play with gstreamer, i've had a go
Attached is a modified version of his original OpenAL patch that adds streaming audio support via the existing llmedia/ gstreamer stuff. Its a bit of a hack and manages to work with a tiny delta and no changes to the existing llmedia/* classes. All it does is create a local instance of LLMediaImplGStreamer class then drives this directly via the hooks LLAudioEngine_OpenAL::startInternetStream() etc. Although it works, there is room for some null pointer protection and probably its worth checking that LLMediaImplGStreamer dosn't do anything unexpected its pretty simple and at least gets streaming audio working for us opensource only users I've run in to a problem where the viewer crashes if there's no sound card. Seems to be some kind of initialization problem.
Its much easier, for me at least, if you post patches against my patch, rather than including it. Yea, sorry about that, due to the way i was managing the patches it was not easy for me at the time to do a diff. I will post a diff against your original patch as posted here should make it easy for future inclusion as soon as i get 5 minutes.
This patch is hella awesome overall. I'm using this for my client whenever I'm not in voice meetings. I'd love to take this in after a few changes. If either of you would like to coordinate with me, here are changes this needs –
– This isn't feature complete without wind noise. Please list this and anything else this needs in a TODO section at the head of audioengine_openal.cpp – We can merge this in now, before wind and anything else is complete, but only if it coexists with libfmod instead of replacing it. This can be either a global configuration #define, or it could be the fallback if an fmod shared library is absent (similar to openjpeg vs kdu) – Audio is popping quite a bit when samples first play, and distorting when loud. Could there be a signed vs unsigned sample bias issue here? – Adding strlcpy is a great idea. I'll move this to a common header. But the benefit is reduced if you include magic numbers, ie: Searching around, I find a few variations on this in our project: Please copy that into the CPP and use it. I'll move the llbase32 one into a global header and merge your duplicate out later. – Where errors or info are produced, please include the method (or at least class) producing the output. This makes these much more useful for debugging – Why the MAX_UNPLAYED_AGE change in LLAudioSource::isDone ? Please include a comment explaining the change. Also, if it's a change necessitated only by openAL use, consider retrieving that value from the LLAudioEngine in use btw, you're both signed contributors? We could create this in a branch in the secondlife.com svn sandbox instead of needing to coordinate the patch format.
Hi Guys,
Cool, i'm happy to work with you on this, I think most of the changes you have request Soft, are no problem and i am working on some now and fixing the volume as well. Making it play nicely with fmod should be no trouble either. Wind is the biggest issue as we need a wind "generator" And yea, i'm a signed contributor and i believe Seg is too, so i'm happy to work on an svn sandbox branch. I would personally prefer to clean a couple of issues before you take the patch and merge as it will take ages to get updates in so its better to get as much right at the sandbox stage as possible. Answers to some of Soft's comments/questions:
I've noticed no problems with popping or noise. So I can't really help you there. Please for the love of god, don't proliferate further use of C string functions! That's not in my patch, Michelle seems to have pulled that over from the fmod implementation. Bletch. Please, please use the C++ string classes. The LL coding standards agree with me on this. Death to fixed buffers. The MAX_UNPLAYED_AGE change is because I was testing on my not particularly fast laptop, and sounds would never ever playing the first time. It just couldn't quite download and decode them before the timeout. Its testing cruft that should probably be dropped, but I kinda wish it were a runtime configurable option... Hi Seg, I will get those C strings cleaned up. It was just a "proof of concept" and yes it was just ripped from the fmod implementation.
As for popping, I believe it is an openAL configuration issue and nothing to do with any code here but I am still looking into that. For what its worth, a slightly newer version of my patch. It moves the fmod "cleanup hack" into the fmod implementation class, where it belongs. I haven't got around to merging in any other of the "get along with fmod" work though. Not posting deltas against my patch makes much more work for me...
I'm not sure the SVN sandbox is the solution. Is this going to happen in a branch dedicated purely to OpenAL? Mixing it up with other changes will make it harder for me to keep things in sync with my Fedora package, in which I would much prefer to stick to patches against a release tarball than use SVN snapshots... I have done some work in getting openal and fmod to co-exist and implemented the changes in llstartup.cpp for this to be necessary too. Your welcome to just take my existing code to see what i have done and clean it up/implemented it a different way. Just may save you a bit of time
i have not uploaded it here yet as it contains experimental wind generator code but as i said you may just wish to rip out the play nicely with fmod bits, or i can later tonight get a diff against your latest snapshot if you like. The whole lot is at http://www.byteme.org.uk/uploads/openALv4.patch The plan for the svn branch was just to play around with openal in, so it would not contain other patches. it can be based on last stable release 1.18.5.3 (or any other release) but if you think its not worth it, what i will do is create my own tree on my server and check in your patch as it stands then it makes it easy for me to generate diffs against your code. What do you think? Something I've noticed, some gestures are set to play the same sound a bazillion times at once. I'm not quite sure why, I would guess its an attempt to increase volume. With OpenAL it seems to result in each duplicate sound to play with a slight delay the first time the gesture is triggered, resulting in an obnoxious echo-y mess. They seem to play in sync upon later triggers, after the sound is decoded and cached. I suppose I need to analyze how fmod handles this...
This may have something to do with LLAudioChannelOpenAL::playSynced(), which is quite likely bogus. I'm not fully clear on what it is supposed to do, and the fmod implementation really doesn't translate to OpenAL's rather async nature. So I just stubbed it over to plain play(), which has worked okay so far... Attached is an incremental patch to add gstreamer streaming audio to Segs 1.18.6.1 openAL patch. Please apply segs patch first. I've made better use of std::string this time. Anyway do what you will with it
Sorry for the delay guys,
Finally attached is my 2nd patch to play nicely with fmod. Patches should be applied in the following order :- 1 (Seg's) slviewer-1.18.6.1-openal.patch I've added a scons OPENAL=yes build config line and this follows all the way through in the same way FMOD does and produces a LL_OPENAL preprocessor define that can be used in code (the same as the LL_FMOD preprocessor define). FMOD and OPENAL can both be included in the build and FMOD respects the LL_BAD_ALSA,LL_BAD_OSS, and LL_BAD_ESD flags as normal. OpenAL will respect LL_BAD_OPENAL flag. FMOD is attempted first and if that is unavailable due to build or run time settings OpenAL is attempted. Have fun Thanks for the work, folks. Personally I think OpenAL is the future of SL audio - I'd love it to prove stable/good enough to be the default some day, at least on Linux, but while testing the transition with users having it sit side-by-side with FMOD is very valuable.
Seg, the normal OpenAL trick to synchronize the start of multiple sounds is to pause the AL context, start the sounds playing, then resume the AL context. Digging on the OpenAL mailing lists should yield the precise code. Warning! These patches, especially streamed audio, do not work out of the box on 1.19.1.x. For some reason LL decided to change LLMediaImplGStreamer.. Even with a few minor changes to get a safe build, the viewer still crashes while initializing LLMediaImplGStreamer. I'll try and get a version working and will submit an update soon.
Thanks Whoops, My patches (i use for my builds) have kind of followed the latest releases so i don't get a crash when i run my builds of 1.19.1.0 but i don't not get any streaming audio either. I don't recall making any real changes so i don't know why i don't crash and you do. If it saves any time, you may wish to rip my patch i am currently using out of my svn (byteme.org.uk) and rebase that as it only needs tweaking to make the audio play again.
I also don't use the play nicely with fmod patch, don't bother rebasing that as it will have to all be done again when we switch to cmake. I've created a sub task for gstreamer streaming audio, as it is somewhat independent of openAL but is a step required to free us from FMOD and this can leave this JIRA exclusively for openal implementation. Its
Please see
That's cool, Whoops. I'd like to suggest that the latest iteration of the patch live on this issue rather than a subissue though - it's getting a little tricky to track where the current iteration lives, otherwise.
The file openal_1_20_9_29May2008.patch includes accumulated updates that provide OpenAL support including: basic audio, audio streaming, and wind (still needs work). The following compiler definitions control what gets built:
LL_OPENAL - for OpenAL support It would be nice if LL could work this set of patches into the official viewer source tree so that they can refine it more, if needed. Have people tried compiling this for Windows? There are many dependencies on GLib etc. I'd think before Linden would be interested in integrating this I'd have to be fairly easy to get it compiling/building. Right now, especially on Windows, it's not very straight forward.
I've been trying to use VC8 to compile a windows viewer with the OpenAL and GStreamer patch (downloaded and installed glib-2.16.3, gstreamer etc) and there are still build problems. We are aware of the issues with gstreamer and windows but no ones really played with that to find out if it can be done at all. If you do get it to build it will be very interesting to know how and how well it works.
And there is openal-soft which has streaming hooks (that openal does not) that may be able to be used and feed something else including gstreamer or a suitable streaming client on windows? I honestly wouldn't expect that LL_GSTREAMER_ENABLED should be used on non-Linux platforms - unless there's some sort of miracle, using GStreamer for streaming audio isn't going to be a convenient hack for non-Linuxers.
One idea is that the OpenAL code can use something like createSourceFromMimeType("http", "audio/*") from the LLMedia API to ask LLMedia for any available audio streaming handler regardless of platform/API - this should return a GStreamer implementation object on Linux, and most likely a QuickTime implementation object on Mac and Win32 with similar functionality and the same base API, removing a direct GStreamer dependancy from the OpenAL code. That's another good argument for sticking to the LLMediaBase API. Any word on getting this ported to 1.21?
Attached a new diff that implements OpenAL sound and GStreamer streaming audio on 1.21.0 code (well based on the SVN trunk actually but that should be close enough).
Sounds and streaming works Cmake build modifications are implemented so that we can build with the new cmake system it does not usurp fmod if you want to enable openal you need to pass cmake the following -DOPENAL:BOOL=TRUE if you build with openal AND fmod one will win, i forget which. The decodemgr fixes are not included as trunk is showing these fixes included already The cmake build mods need more work and I am very unhappy with the llmedia and gstreamer stuff that has been dragged around to get streaming to work. We really need to abstract this in a true llmedia class to prevent this mess. I've speculatively taken this onto an internal branch and I'm fiddling with it. I'll probably clean up the streaming stuff a lot while I'm at it, and re-publish patches.
I'm attaching vwr-2662-linden1.patch - this patch takes the source from current trunk (approx. viewer 1.21) to the current HEAD of the branch I'm working on getting this integrated with. I've been doing a fair bit of refactoring and fixing so I'd appreciate if any further patches (if any) were relative to this one.
This is a work-in-progress. It should work pretty well, but I'm still rewiring, testing and fixing a bunch of stuff. Most notably the CMake integration isn't improved at all yet. Ah, a quick explanation of the patch. This includes openal_1.21.0.diff with the following changes:
Attaching updated patch. Compared with the previous (-linden1) patch, this rewrites wind buffering (making it adaptive), removes the gain being applied twice to wind, resurrects Doppler support (assumes a relatively unbroken OpenAL, i.e. openal-soft) and adds a few other tweaks and cleanups.
Doppler effect is maximized and reversed regardless of the position of the setting slider with this linden2 patch.
Thanks for testing. Doppler - and decent sound quality - requires OpenAL-soft, not the legacy OpenAL-SI.
http://kcat.strangesoft.net/openal.html  The WIP branch is being exported now -
http://svn.secondlife.com/trac/linden/browser/branches/openal Please use this as the basis for testing and patches from now on. Installed OpenAL-Sl and recompiled, but i dont notice any improvements yet. :/
will give the branch a try OpenAL-SI is exactly what you shouldn't use. OpenAL-soft should be good (much better).
Scratch that, OpenAl-soft is what i meant to type x.x
Testing OpenAL branch and its working nicely, still the doppler issue.
I see errors like this every once in a while in the console WARNING: loadWAV: LLAudioBufferOpenAL::loadWAV() Error loading /home/khyota/.secondlife/cache/d9a01633-3978-5dd2-e1af-5dca918356c4.dsf There was already an AL error on entry to an ALUT function. those WARNING: loadWAV errors have been fixed.
Wind still does not sound the same here. Seeing these messages every once in a while too. 2008-10-21T13:12:57Z INFO: updateWind: Wind had stopped - probably ran out of buffers - restarting: 15 now queued. Also repeated stopping of internet streams that when streaming is turned off. 2008-10-21T13:26:18Z INFO: stopInternetStream: entered stopInternetStream() The best part is, Voice plays nicely with it and works! Might OpenAl make it into the next release? its almost perfect. New patch applyable to latest trunk? or a trunk remerge? the branch is aging and openal is the only way i can get sound in my 64bit viewers.
It'll be re-merged from trunk soon (perhaps later this week). I'm waiting for some trunk dust to settle.
My best guess right now is that this'll be in viewer 1.23. Missy, you will have to wait for Tofu's merge back to trunk. The branch is a little old now on the main code and the security update to asset uploads has prevented the viewer from uploading anything at all.
Tofu, how soon are you hoping for a merge? if its going to be a while i may create a fresh set of patches for trunk or at least last release so that the openal can be applied to a newer base. It's in the last stages of QA.
Has anyone had any success using Tofu's patch in windows? And if you have, can you post a patch of the changes you made?
openal-soft-1.6.372 was released, will that add any usefull features for the viewer? Oh and i tried merging the branch myself but it was a complete mess!
The branch is already using something extremely close to 1.6.372, though I'll likely put the official 1.6.372 through QA after the current branch has landed.
Oh, here's a status update on QA while I'm here... The branch passed QA and is now simply in the 'merge queue' awaiting the final merge to trunk. It's next in line after the current trunk lock-holder, but merge QA-ing is a bit slower than usual because of USA Thanksgiving!
This has landed on the trunk now!
Great! wind is working again! havent heard it in months, but still seeing the out of buffer messages, is that normal? "Building with OpenAL audio support" shows up twice on configure.
Great work for getting OpenAL fully supported Tofu! hugs The out-of-buffer messages aren't bad, they're more of debugging interest at this point - I should get rid of them to avoid worry.
"This has landed on the trunk now!"
That sounds very painful for the elephant :S This change in trunk, http://svn.secondlife.com/trac/linden/changeset?old_path=trunk%2Findra%2Fcmake%2FOPENAL.cmake&old=1541&new_path=trunk%2Findra%2Fcmake%2FOPENAL.cmake&new=1587
makes CMake no longer detect OpenAL-soft for standalone building on openSUSE 11.1, which has an official package for it now. Reverting back fixes it. OpenAL hit RC8. I've been getting lots of reports of the client crashing when trying to play music where it haven't before. This is the 32-bit binary linux client as supplied by LL on the main download page. I build from source as 64-bit with the openal patch from here with no problems until RC8. On my system, sounds works and music works, but I have no center channel. I used to have a full 5.1 sound.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Normal
OpenAL support
audio engines will get it by default.