|
|
|
For those who can't wait for Michelle's non-openal version of audio streaming, take a look at gstreamer_audio_1.20.6.patch. This includes the minor change required to initialize GStreamer prior to instantiating the LLMediaImplGStreamer class. That is:
mMedia_data = new LLMediaManagerData; before: m_streamer=new LLMediaImplGStreamer (); That simple change kept the viewer from tipping over during initialization Thanks for the update whoops. I'm not always that good at remembering to update my patches. I had solved this in a slightly different way by changing when the init() got called to ensure the media manager and friends were already started.
I've not progressed very far with an independent patch as the llmedia classes are too video orientated and the llaudio classes have all the hooks for detailing with the streaming audio calls. So its an absolute tangle to seperate, so keeping a system where we can have fmod or openal is not easy. Its easy if we ditch fmod completely but then that also negates the need to have it independent of openal in the first place M2 I'll get the llmedia pieces of this applied internally soon, as there's no reason not to.
Some feedback:
Instead of using m_streamer->stop(), pause(), play() please use: Similarly, instead of re-adding methods for isPlaying etc, please use (getStatus() == LLMediaBase::STATUS_STARTED) etc. directly as a LLMedia user - again this is a blessed LLMedia API. Thanks! I've attached a patch, named openal_patch_1_20_7_llmedia_broken.patch, that inculdes the work of many folk, especially Seg and Michelle who deserve 99% of the credit! It includes the OpenAL audio classes, Wind, and streaming audio. All of which should play nicely in a standard LL build and controlled by defining:
LL_OPENAL - for OpenAL support IMPORTANT - the gstreamer changes use Tofu's changes to comply with the LLMedia API. However LLMedia is still not functioning correctly. For example, using: m_streamer->addCommand(LLMediaBase::COMMAND_STOP) does not stop the audio. It doesn't even get updated if you follow the "stop" with: m_streamer->updateCommand(); to force immediate update. Great Whoops!, glad you are putting the polish on this so it plays nicely with the standard build. If those flags all do what they are suppose to may be we can move this code into the viewer and just enable and build time, wooot! subject to getting llmedia to behave
Thanks Michelle!
I just created Yes! Thanks Tofu! I could have sworn that I tried updateMedia() but this time it works. The openal_patch_1_20_9_works.patch includes the sprinkling of updateMedia() where addCommand() is used.
Mind calling updateMedia() from just one place that's destined to get called fairly frequently, rather than from those various sites? LLAudioEngine_OpenAL::idle() looks like the perfect place to me.
The reason is that LLMedia isn't necessarily an asynchronous interface, it's just that the gstreamer implementation 98% is. It's better to poke for an update frequently than just when you assume it's needed (these assumptions may not quite be correct now or in the future). As Tofu has suggested, an updateMedia() should reside in idle(). Patch openal_idle_with_updateMedia.patch does just this. I left the remaining updateMedia() calls as is since we'll likely want the update "pushed" immediately.
I'll also update VMR-2662 with a master patch that includes everything. Whoops, do you have a contrib agreement on file? if so should we be taking this to the svn sandbox as its getting a bit unwieldy with the number of patches and any little revision needs a new patch attached which is difficult to follow. Should help polish the edges on this one a little. Tofu, does this seem a reasonable idea to you?
Sure, working in a sandbox sounds good.
In order to load the libraries correctly on Win32, in llmediaimplgstreamer.cpp
In LLMediaImplGStreamer::startup ( LLMediaManagerData* init_data ) change: // Get symbols! to: // Get symbols! I have it compiling, linking and running now with VC8. Carlo, any other changes needed?
Which gstreamer win32 package did you install? Should these instructions for gstreamer/win32 be placed on a wiki page, this is pretty cool. Any chance of a success/fail reporting and comparison for various in world streams that you can find? Thanks I've re-implemented this as part of the refactoring going on in
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Resolved
Normal
Time for more coffee.
I will now start work on a separate patch that is independent of openal, which i hope to be the one that gets included in the viewer.