* The USD schema should not directly contain any audio data but should refer
  to an audio file or stream via an *assetPath*

* The USD schema should not directly define the supported audio file
  formats, but see :ref:`Usdz Considerations <wp_usdaudio:usdz considerations>` 
  below for usdz-related restrictions

* Any number of audio elements should be allowed in a USD stage

* Each audio element is consumed as a whole: the USD schema does not provide
  for isolating specific sub-channels or tracks within an audio asset.

* The same audio file should be referenceable by multiple USD primitives

* Audio elements should be positionable (and orientable) in space with a
  given 3D transformation that can change over time

* Audio elements should also be able to represent "ambient" sound where the
  mono or stereo sound is played regardless of spatial positioning

* Audio should be able to be amplified/attenuated over time 

* This does not provide any absolute measure of sound pressure (i.e. dB)

* Each audio element should be able to be amplified/attenuated
  independently. At a later date we may introduce a "grouping" feature to
  modulate multiple audio streams at once

* No explicit support for "fadein" or "fadeout", which could be encoded via
  time-varying attenuation, should fading not be embedded directly in the
  audio streams being referenced

* The start of playback within a UsdStage's time-range should be
  independently specifiable for each audio element, as should an optional
  endpoint.

* Should be able to specify an offset into each referenced audio file from
  which playback should begin

* Should be able to easily loop the audio stream, if desired

* Each audio stream should be able to have its own arbitrary sample rate. It
  should be the responsibility of the playback tool to properly determine
  and play the sample rate specified in a given stream

* **uniform asset filePath = @@** 

  Path to the audio file.

* **uniform token auralMode = "spatial"** 

  Determines how audio should be consumed.  Allowed values: 

  *spatial*: Play the audio in 3D space if the device can support spatial
  audio. If not, fall back to mono.

  *nonSpatial* : Play the audio without regard to the :usda:`SpatialAudio`
  prim's position. If the audio media contains any form of stereo or other
  multi-channel sound, it is left to the application to determine whether
  the listener's position should be taken into account. We expect
  *nonSpatial* to be the choice for ambient sounds and music sound-tracks.

  For now, we consider *oriented* and *spread-limited* sounds, which are
  supported by major game engines, as beyond scope. However, in anticipation
  of future support of these features, in consideration to authoring tools
  needing to author transformations for :usda:`SpatialAudio` prims *now* ,
  **we stipulate that the emission direction for** :usda:`SpatialAudio`
  **prims is the -Z axis** , which matches the orientation of directional
  lights in `UsdLux
  <api/usd_lux_page_front.html>`_ .

* **uniform token playbackMode = "onceFromStart"** 

  For the fallback value of "once" play the referenced audio once, beginning
  at :bi:`startTime`, continuing until :bi:`endTime`, if :bi:`endTime` is
  greater than :bi:`startTime`, otherwise until the audio completes. For any
  value other than "once", **loop** the audio file to fill time, as
  described below. If specified, :bi:`mediaOffset` is applied to the first
  run-through of the audio clip with the second and all other loops
  beginning from the start of the audio clip. In future we can add
  additional attributes that can identify cut-points within the referenced
  media such that we can continuously loop a subsection of the referenced
  clip, but for now we choose to start more simply. Non-fallback values of
  :bi:`playbackMode` determine when looping should begin and end: 

  * *onceFromStart :* Play the audio once from :bi:`startTime`, continuing 
    until the audio clip completes.

  * *onceFromStartToEnd :* Play the audio once from :bi:`startTime` to
    :bi:`endTime` or until the audio clip completes, whichever
    comes first. See :ref:`SdfTimeCode and TimeScaling
    <wp_usdaudio:sdftimecode and time scaling>` to understand how this
    mode is affected by time-scaling. 

  * *loopFromStart :* Start playing the audio at :bi:`startTime` and
    continue looping through to the stage's authored :bi:`endTimeCode`.

  * *loopFromStartToEnd :* Start playing the audio at :bi:`startTime`
    and continue looping through, stopping the audio at :bi:`endTime`. See
    :ref:`SdfTimeCode and TimeScaling<wp_usdaudio:sdftimecode and time scaling>` 
    to understand how this mode is affected by time-scaling. 

  * *loopFromStage :* Start playing the audio at the containing stage's a
    uthored :bi:`startTimeCode`, and continue looping through to the stage's
    authored :bi:`endTimeCode`. This can be useful for ambient sounds that
    should always be active.

* **uniform timeCode startTime = 0** 

  Expressed in the :ref:`timeCodesPerSecond<glossary:TimeCode>` of the
  containing stage, ***startTime*** specifies when the audio stream will
  start playing during animation playback. See :ref:`SdfTimeCode and
  TimeScaling<wp_usdaudio:sdftimecode and time scaling>` to understand how
  this property resolves on a stage.

* **uniform timeCode endTime = 0** 

  Expressed in the :ref:`timeCodesPerSecond<glossary:TimeCode>` of the
  containing stage, ***endTime*** specifies when the audio stream will cease
  playing during animation playback, if the length of the referenced audio
  clip is longer than desired.  If **e *ndTime*** is less than or equal to
  **startTime** , then play the audio stream to its completion.  See
  :ref:`SdfTimeCode and TimeScaling<wp_usdaudio:sdftimecode and time
  scaling>` to understand how this property resolves on a stage.

* **uniform double mediaOffset = 0** 

  Expressed in **seconds** , :bi:`mediaOffset` specifies the offset from the
  referenced audio file's beginning at which we should begin playback when
  stage playback reaches the prim's :bi:`startTime`. If the prim's
  :bi:`playbackMode` is a looping mode, :bi:`mediaOffset` is applied only to
  the first run-through of the audio clip; the second and all other loops
  begin from the start of the audio clip.

* **double gain = 1.0** 

  Float multiplier on the incoming audio signal. A value of 0 "mutes" the
  signal. Negative values will be clamped to 0. Although gain is commonly
  expressed in dB in the audio world, that formulation requires the addition
  of an extra animatable :bi:`mute` property since dB can only express
  ratios of signal, not an absolute scale factor, except theoretically as
  :math:`- inf` dB. Further, given the intended use of SpatialAudio for
  content delivery in usdz assets, the commonality with the `Web Audio API
  <https://www.w3.org/TR/webaudio/#GainNode>`_ seems relevant.

   def SpatialAudio "WoodysVoice"
   {
       # SpatialAudio xform.  This prim might typically be located
       # as a child of the "Woody" model so that it's location need
       # only be specified relative to Woody, rather than replicating
       # Woody's animation
       double3 xformOp:translate     = (3.0, -3.0, 2)
       uniform token[] xformOpOrder  = ["xformOp:translate"]


       # SpatialAudio Properties.  We have left the playbackMode at its
       # fallback of "onceFromStart", so we do not require an endTime:
       # the sound will play to completion
       uniform asset  filePath       = @WoodysVoice.mp3@
       uniform token  auralMode      = "spatial"
       uniform timeCode startTime =  65.0
       # Skip the first third of a second in WoodysVoice.mp3 
       uniform double mediaOffset    =  0.33333333333
   }