Commit Graph

21 Commits (77f56fa7bf6404ebcda4d17c1229336243fac4cf)

Author SHA1 Message Date
Liny 375fe0a924 Fix build on osx by fixing equality typo. 2018-10-13 17:24:29 -07:00
Ansariel 872a28c506 FIRE-23152: Fix stream metadata display for OGG Vorbis (might be ICY streaming server specific) 2018-10-11 23:46:48 +02:00
Ansariel 31e4d9db08 Fix FMOD error logging 2017-09-02 12:04:04 +02:00
Ansariel 6dd2070446 Add Firestorm tagging to previous commit 2015-06-17 10:20:47 +02:00
Drake Arconis c12f153b68 Audio Engine and FMOD Ex improvements and fixes from Shyotl Kuhr and Drake Arconis 2015-06-16 17:01:40 -04:00
Ansariel 80f42dfdd4 Backed out changeset 158bbab1eb2a (FIRE-12077) as it causes other issues 2015-06-16 20:25:27 +02:00
Nicky b9150394a7 FIRE-12077; Contribution by Gibson Firehawk to fix the bug that Linux clients freeze ocassionaly when the stream changes or stops.
From his original commit:

OPEN-279 Potential fix for the BUG-3214 stream stopping issue
Here is what the FMOD documentation says about the stream state FMOD_OPENSTATE_Ready and playing, but not possible to release at this time without stalling the main  Since the FMOD Ex implementation (not sure about the old FMOD 3.75), streams have been released while the stream state is FMOD_OPENSTATE_PLAYING. Before release is called, the stream would only be paused, not stopped. The stream must be stopped for it to no longer be in playing state. Also, there usually needs to be just a little time between when a stream is stopped for it to exit playing state before releasing it. The viewer has been calling release almost instantly after just pausing the stream.
I think s quite possible that, even though releasing streams while they are in playing state t appear to be problematic most of the time, that some of the stream stopping issues such as BUG-3214 are a result of it. In the net streaming example program that comes with the FMOD API, when a stream is to be stopped, stop is called for the channel and then right before release, the program waits not only for the stream to exit playing state, but also for the stream to return to FMOD_OPENSTATE_READY before releasing. Due to the differences in how the viewer has been stopping and releasing streams compared to how FMOD does it in their example program, along with what they say in their documentation about the stream state FMOD_OPENSTATE_PLAYING, i have made the following changes to how streams are stopped and released by the viewer.
1.) Stop the stream channel instead of just pausing it before release so the stream can exit FMOD_OPENSTATE_PLAYING state and return (usually very quickly after stop is called) to FMOD_OPENSTATE_READY.
2.) Converted the dead streams list into a delayed release list. If a s state is not FMOD_OPENSTATE_READY when s checked right before release, push the stream to the delayed release list. Check for delayed release streams during each update like how was done before with the dead streams list and release streams that are in ready state.
3.) During viewer shutdown, call stop on the currently playing stream. After that, check if any streams are in the delayed release list, and, if so, release them when their stream state is ready state. If an unlikely edge case occurs where the streams in the delayed release list are not released in a timely fashion, force release them. The force release added in this change is actually pretty much the equivalent of how streams used to be stopped previously. The main difference, and advantage, is that regardless of which state the stream might be in during force release besides FMOD_OPENSTATE_READY, it won't be in FMOD_OPENSTATE_PLAYING when released.itstreamdoesnitthread.PLAYING -
2015-05-11 14:05:44 +02:00
Tank_Master 6babf8abd2 Merge LL 3.7.7 2014-06-09 11:29:57 -07:00
Richard Linden e340009fc5 second phase summer cleaning
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-08-09 17:11:19 -07:00
Graham Madarasz c38204f5e0 Unwind cruft from hunting for 2707 they won't end up in vwr-dev-mat 2013-06-05 14:26:27 -07:00
Graham Madarasz cf3d2a06a1 BUG-2707 turn off more LL_DEBUGS to narrow down Kat's crashing cuplrit 2013-06-01 19:36:38 -07:00
Graham Madarasz d21fc254a7 BUG-2707 hunt for infos call crashing Kat 2013-06-01 13:43:52 -07:00
callum cce8d02766 MAINT-2629: limit stream searches to prevent hangs on bad streams 2013-05-01 07:27:59 -04:00
callum d9de58b46a OPEN-173 FIX FMODEx Music stutters once every few seconds (OSS patch via Latif Khalifa & Siana Gearz) 2013-04-19 16:29:11 -07:00
Sovereign Engineer 3a141d2ff3 Cleanup some left over comments in fmodex streaming 2013-02-04 10:25:23 -05:00
Nicky 28c3886eff Compile fix for GCC, cannot construct an LLSD object with NULL. 2013-10-07 17:44:19 +02:00
Cinders 79bbf7be35 FIRE-11478: Better handling of audio stream tags with fmodex, based on work by Shyotl Khur 2013-10-06 22:08:36 -06:00
callum_linden ba3e89b5c7 first push - patch from CmdCupCake plus force FMODEX on 2013-01-18 16:43:19 -08:00
Cinders a9d0bfd7c8 Add a little debugging to llstreamingaudio_fmodex.cpp 2013-07-14 14:28:54 -06:00
Cinders 41185aec09 FIRE-11042: Fix crash when stream metadata is null.
Could probably use more work
2013-07-14 10:42:15 -06:00
Ansariel 3cc0755527 Make streamtitle display work with fmodex
Yes, polling looks ugly, but there doesn't seem to be a callback method for changed metadata
anymore and the "updated" member in the FMOD_TAG struct doesn't want to work properly.
2013-07-12 13:21:54 +02:00