2007-11-13 18:02:18 -08:00
|
|
|
#ifndef _AL_SOURCE_H_
|
|
|
|
#define _AL_SOURCE_H_
|
|
|
|
|
2010-11-06 15:08:54 -07:00
|
|
|
#define MAX_SENDS 4
|
2007-12-18 18:13:49 -08:00
|
|
|
|
2012-09-14 02:42:36 -07:00
|
|
|
#include "alMain.h"
|
2008-08-14 05:43:52 -07:00
|
|
|
#include "alu.h"
|
2014-02-23 21:11:01 -08:00
|
|
|
#include "hrtf.h"
|
2007-11-13 18:02:18 -08:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2014-08-20 21:35:18 -07:00
|
|
|
struct ALbuffer;
|
|
|
|
struct ALsource;
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
struct ALsourceProps;
|
2014-08-20 21:35:18 -07:00
|
|
|
|
2010-11-26 02:53:15 -08:00
|
|
|
|
2013-10-07 05:41:41 -07:00
|
|
|
typedef struct ALbufferlistitem {
|
2014-07-31 07:20:36 -07:00
|
|
|
struct ALbuffer *buffer;
|
|
|
|
struct ALbufferlistitem *volatile next;
|
2007-11-13 18:02:18 -08:00
|
|
|
} ALbufferlistitem;
|
|
|
|
|
2014-03-18 19:56:25 -07:00
|
|
|
|
2014-08-21 03:24:48 -07:00
|
|
|
typedef struct ALvoice {
|
2014-08-20 21:35:18 -07:00
|
|
|
struct ALsource *volatile Source;
|
2014-03-19 13:14:11 -07:00
|
|
|
|
|
|
|
/** Current target parameters used for mixing. */
|
2014-06-13 16:07:25 -07:00
|
|
|
ALint Step;
|
2014-03-19 13:14:11 -07:00
|
|
|
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
ALboolean Looping;
|
|
|
|
|
2016-02-14 01:22:01 -08:00
|
|
|
/* If not 'moving', gain/coefficients are set directly without fading. */
|
|
|
|
ALboolean Moving;
|
|
|
|
|
2014-05-18 09:31:08 -07:00
|
|
|
ALboolean IsHrtf;
|
2014-03-19 13:14:11 -07:00
|
|
|
|
2014-05-24 16:55:10 -07:00
|
|
|
ALuint Offset; /* Number of output samples mixed since starting. */
|
|
|
|
|
2015-10-15 15:13:19 -07:00
|
|
|
alignas(16) ALfloat PrevSamples[MAX_INPUT_CHANNELS][MAX_PRE_SAMPLES];
|
2015-10-15 07:29:25 -07:00
|
|
|
|
2015-11-05 09:42:08 -08:00
|
|
|
BsincState SincState;
|
|
|
|
|
2014-03-19 13:14:11 -07:00
|
|
|
DirectParams Direct;
|
|
|
|
SendParams Send[MAX_SENDS];
|
2014-08-21 03:24:48 -07:00
|
|
|
} ALvoice;
|
2014-03-19 13:14:11 -07:00
|
|
|
|
|
|
|
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
struct ALsourceProps {
|
|
|
|
ATOMIC(ALfloat) Pitch;
|
|
|
|
ATOMIC(ALfloat) Gain;
|
|
|
|
ATOMIC(ALfloat) OuterGain;
|
|
|
|
ATOMIC(ALfloat) MinGain;
|
|
|
|
ATOMIC(ALfloat) MaxGain;
|
|
|
|
ATOMIC(ALfloat) InnerAngle;
|
|
|
|
ATOMIC(ALfloat) OuterAngle;
|
|
|
|
ATOMIC(ALfloat) RefDistance;
|
|
|
|
ATOMIC(ALfloat) MaxDistance;
|
|
|
|
ATOMIC(ALfloat) RollOffFactor;
|
|
|
|
ATOMIC(ALfloat) Position[3];
|
|
|
|
ATOMIC(ALfloat) Velocity[3];
|
|
|
|
ATOMIC(ALfloat) Direction[3];
|
|
|
|
ATOMIC(ALfloat) Orientation[2][3];
|
|
|
|
ATOMIC(ALboolean) HeadRelative;
|
|
|
|
ATOMIC(ALboolean) Looping;
|
|
|
|
ATOMIC(enum DistanceModel) DistanceModel;
|
|
|
|
ATOMIC(ALboolean) DirectChannels;
|
|
|
|
|
|
|
|
ATOMIC(ALboolean) DryGainHFAuto;
|
|
|
|
ATOMIC(ALboolean) WetGainAuto;
|
|
|
|
ATOMIC(ALboolean) WetGainHFAuto;
|
|
|
|
ATOMIC(ALfloat) OuterGainHF;
|
|
|
|
|
|
|
|
ATOMIC(ALfloat) AirAbsorptionFactor;
|
|
|
|
ATOMIC(ALfloat) RoomRolloffFactor;
|
|
|
|
ATOMIC(ALfloat) DopplerFactor;
|
|
|
|
|
|
|
|
ATOMIC(ALfloat) StereoPan[2];
|
|
|
|
|
|
|
|
ATOMIC(ALfloat) Radius;
|
|
|
|
|
|
|
|
/** Direct filter and auxiliary send info. */
|
|
|
|
struct {
|
|
|
|
ATOMIC(ALfloat) Gain;
|
|
|
|
ATOMIC(ALfloat) GainHF;
|
|
|
|
ATOMIC(ALfloat) HFReference;
|
|
|
|
ATOMIC(ALfloat) GainLF;
|
|
|
|
ATOMIC(ALfloat) LFReference;
|
|
|
|
} Direct;
|
|
|
|
struct {
|
|
|
|
ATOMIC(struct ALeffectslot*) Slot;
|
|
|
|
ATOMIC(ALfloat) Gain;
|
|
|
|
ATOMIC(ALfloat) GainHF;
|
|
|
|
ATOMIC(ALfloat) HFReference;
|
|
|
|
ATOMIC(ALfloat) GainLF;
|
|
|
|
ATOMIC(ALfloat) LFReference;
|
|
|
|
} Send[MAX_SENDS];
|
|
|
|
|
|
|
|
ATOMIC(struct ALsourceProps*) next;
|
|
|
|
};
|
|
|
|
|
2014-03-18 19:56:25 -07:00
|
|
|
typedef struct ALsource {
|
2012-04-26 03:26:22 -07:00
|
|
|
/** Source properties. */
|
2012-04-19 21:46:29 -07:00
|
|
|
volatile ALfloat Pitch;
|
|
|
|
volatile ALfloat Gain;
|
|
|
|
volatile ALfloat OuterGain;
|
|
|
|
volatile ALfloat MinGain;
|
|
|
|
volatile ALfloat MaxGain;
|
|
|
|
volatile ALfloat InnerAngle;
|
|
|
|
volatile ALfloat OuterAngle;
|
|
|
|
volatile ALfloat RefDistance;
|
|
|
|
volatile ALfloat MaxDistance;
|
|
|
|
volatile ALfloat RollOffFactor;
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
volatile ALfloat Position[3];
|
|
|
|
volatile ALfloat Velocity[3];
|
|
|
|
volatile ALfloat Direction[3];
|
2014-10-31 22:43:13 -07:00
|
|
|
volatile ALfloat Orientation[2][3];
|
2012-04-19 21:46:29 -07:00
|
|
|
volatile ALboolean HeadRelative;
|
|
|
|
volatile ALboolean Looping;
|
2011-09-11 01:18:57 -07:00
|
|
|
volatile enum DistanceModel DistanceModel;
|
2012-02-09 23:35:17 -08:00
|
|
|
volatile ALboolean DirectChannels;
|
2007-11-13 18:02:18 -08:00
|
|
|
|
2011-09-11 01:18:57 -07:00
|
|
|
volatile ALboolean DryGainHFAuto;
|
|
|
|
volatile ALboolean WetGainAuto;
|
|
|
|
volatile ALboolean WetGainHFAuto;
|
|
|
|
volatile ALfloat OuterGainHF;
|
2007-12-17 21:33:05 -08:00
|
|
|
|
2011-09-11 01:18:57 -07:00
|
|
|
volatile ALfloat AirAbsorptionFactor;
|
|
|
|
volatile ALfloat RoomRolloffFactor;
|
|
|
|
volatile ALfloat DopplerFactor;
|
2008-07-15 02:33:05 -07:00
|
|
|
|
2016-03-25 14:40:44 -07:00
|
|
|
/* NOTE: Stereo pan angles are specified in radians, counter-clockwise
|
|
|
|
* rather than clockwise.
|
|
|
|
*/
|
|
|
|
volatile ALfloat StereoPan[2];
|
|
|
|
|
2014-07-08 09:13:35 -07:00
|
|
|
volatile ALfloat Radius;
|
|
|
|
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
/** Direct filter and auxiliary send info. */
|
|
|
|
struct {
|
|
|
|
ALfloat Gain;
|
|
|
|
ALfloat GainHF;
|
|
|
|
ALfloat HFReference;
|
|
|
|
ALfloat GainLF;
|
|
|
|
ALfloat LFReference;
|
|
|
|
} Direct;
|
|
|
|
struct {
|
|
|
|
struct ALeffectslot *Slot;
|
|
|
|
ALfloat Gain;
|
|
|
|
ALfloat GainHF;
|
|
|
|
ALfloat HFReference;
|
|
|
|
ALfloat GainLF;
|
|
|
|
ALfloat LFReference;
|
|
|
|
} Send[MAX_SENDS];
|
|
|
|
|
2012-04-26 03:26:22 -07:00
|
|
|
/**
|
|
|
|
* Last user-specified offset, and the offset type (bytes, samples, or
|
|
|
|
* seconds).
|
|
|
|
*/
|
2012-04-16 22:11:03 -07:00
|
|
|
ALdouble Offset;
|
|
|
|
ALenum OffsetType;
|
2007-11-13 18:02:18 -08:00
|
|
|
|
2012-04-26 03:26:22 -07:00
|
|
|
/** Source type (static, streaming, or undetermined) */
|
2012-04-19 21:46:29 -07:00
|
|
|
volatile ALint SourceType;
|
2007-11-13 18:02:18 -08:00
|
|
|
|
2012-04-26 03:26:22 -07:00
|
|
|
/** Source state (initial, playing, paused, or stopped) */
|
|
|
|
volatile ALenum state;
|
|
|
|
ALenum new_state;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Source offset in samples, relative to the currently playing buffer, NOT
|
|
|
|
* the whole queue, and the fractional (fixed-point) offset to the next
|
|
|
|
* sample.
|
|
|
|
*/
|
2016-05-19 20:50:55 -07:00
|
|
|
ATOMIC(ALuint) position;
|
|
|
|
ATOMIC(ALuint) position_fraction;
|
2012-04-26 03:26:22 -07:00
|
|
|
|
|
|
|
/** Source Buffer Queue info. */
|
2014-07-31 07:20:36 -07:00
|
|
|
ATOMIC(ALbufferlistitem*) queue;
|
|
|
|
ATOMIC(ALbufferlistitem*) current_buffer;
|
2014-05-10 05:07:13 -07:00
|
|
|
RWLock queue_lock;
|
2012-04-26 03:26:22 -07:00
|
|
|
|
|
|
|
/** Current buffer sample info. */
|
2011-05-17 13:25:15 -07:00
|
|
|
ALuint NumChannels;
|
2011-05-18 17:02:18 -07:00
|
|
|
ALuint SampleSize;
|
2011-05-17 13:25:15 -07:00
|
|
|
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
ATOMIC(struct ALsourceProps*) Update;
|
|
|
|
ATOMIC(struct ALsourceProps*) FreeList;
|
2010-09-26 01:15:27 -07:00
|
|
|
|
2012-04-26 03:26:22 -07:00
|
|
|
/** Self ID */
|
2012-04-19 22:28:01 -07:00
|
|
|
ALuint id;
|
2007-11-13 18:02:18 -08:00
|
|
|
} ALsource;
|
|
|
|
|
2016-05-10 22:49:24 -07:00
|
|
|
inline void LockSourcesRead(ALCcontext *context)
|
|
|
|
{ LockUIntMapRead(&context->SourceMap); }
|
|
|
|
inline void UnlockSourcesRead(ALCcontext *context)
|
|
|
|
{ UnlockUIntMapRead(&context->SourceMap); }
|
|
|
|
inline void LockSourcesWrite(ALCcontext *context)
|
|
|
|
{ LockUIntMapWrite(&context->SourceMap); }
|
|
|
|
inline void UnlockSourcesWrite(ALCcontext *context)
|
|
|
|
{ UnlockUIntMapWrite(&context->SourceMap); }
|
|
|
|
|
2013-11-04 13:51:19 -08:00
|
|
|
inline struct ALsource *LookupSource(ALCcontext *context, ALuint id)
|
2016-05-10 22:49:24 -07:00
|
|
|
{ return (struct ALsource*)LookupUIntMapKeyNoLock(&context->SourceMap, id); }
|
2013-11-04 13:51:19 -08:00
|
|
|
inline struct ALsource *RemoveSource(ALCcontext *context, ALuint id)
|
2016-05-10 22:49:24 -07:00
|
|
|
{ return (struct ALsource*)RemoveUIntMapKeyNoLock(&context->SourceMap, id); }
|
2013-11-04 13:51:19 -08:00
|
|
|
|
Provide asynchronous property updates for sources
This necessitates a change in how source updates are handled. Rather than just
being able to update sources when a dependent object state is changed (e.g. a
listener gain change), now all source updates must be proactively provided.
Consequently, apps that do not utilize any deferring (AL_SOFT_defer_updates or
alcSuspendContext/alcProcessContext) may utilize more CPU since it'll be
filling out more update containers for the mixer thread to use.
The upside is that there's less blocking between the app's calling thread and
the mixer thread, particularly for vectors and other multi-value properties
(filters and sends). Deferring behavior when used is also improved, since
updates that shouldn't be applied yet are simply not provided. And when they
are provided, the mixer doesn't have to ignore them, meaning the actual
deferring of a context doesn't have to synchrnously force an update -- the
process call will send any pending updates, which the mixer will apply even if
another deferral occurs before the mixer runs, because it'll still be there
waiting on the next mixer invocation.
There is one slight bug introduced by this commit. When a listener change is
made, or changes to multiple sources while updates are being deferred, it is
possible for the mixer to run while the sources are prepping their updates,
causing some of the source updates to be seen before the other. This will be
fixed in short order.
2016-05-14 23:43:40 -07:00
|
|
|
void UpdateAllSourceProps(ALCcontext *context);
|
2011-08-20 06:31:10 -07:00
|
|
|
ALvoid SetSourceState(ALsource *Source, ALCcontext *Context, ALenum state);
|
2011-08-21 00:49:04 -07:00
|
|
|
ALboolean ApplyOffset(ALsource *Source);
|
|
|
|
|
2008-01-16 13:27:15 -08:00
|
|
|
ALvoid ReleaseALSources(ALCcontext *Context);
|
|
|
|
|
2007-11-13 18:02:18 -08:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif
|