Standard music deliverables with sub-bass on channel 3 (L/R/LFE) import fine, preview fine (the inspector labels them 2.1), and play through AudioSource.clip - but they can't be hosted by the generator pipeline these examples are built on, and 2D playback on the clip path silently drops their channels. Filing here rather than only the bug reporter because the pattern in PR #1's ClipPlayerGenerator inherits the first defect verbatim.
Environment: reproduced on 6000.6.0b8; repro project settings derived from this repo's (6000.7 stream). Repro project: three-channel-clip-repro - one scene, a 3ch / 6ch (5.1 control) / 7ch matrix in both Decompress On Load and Streaming variants, each playable via AudioSource.clip and via a forwarding IAudioGenerator, with a 2D/3D toggle. Playback routes through an AudioMixer so lane activity is visible in the Audio Mixer window's Master meters.
1. AudioClip.CreateInstance refuses channel counts the clip path plays
Any generator that composes a clip as a nested instance - exactly what ClipPlayerGenerator in PR #1 does - throws for 3ch and 7ch clips:
ArgumentException: 'audioClip' has a channel count that cannot be converted to a valid speaker mode.
UnityEngine.Audio.SampleProviderBindings.CreateGeneratorHeader (...)
UnityEngine.AudioClip.CreateInstance (...)
ClipForwardingGenerator.CreateInstance (Assets/Scripts/ClipForwardingGenerator.cs:31)
UnityEngine.Audio.ScriptableGeneratorBindings.InstantiateGeneratorFromObject (...)
UnityEngine.AudioSource:Play()
followed by "Assigned scriptable generator returned an invalid instance." and silence. The 6ch control clip instantiates and plays through the same wrapper, so this is specific to counts without a speaker mode, not multichannel generally. The requested nested AudioFormat doesn't enter into it - the clip's own channel count is refused.
(Note for anyone reproducing: assigning a bare AudioClip to AudioSource.generator does not exercise this - clip, resource, and generator are one backing slot and a bare clip plays the legacy way regardless of which property assigned it. Only a forwarding generator reaches AudioClip.CreateInstance - which is also the route every nested-generator/middleware use case takes.)
2. 2D legacy playback silently drops these clips' channels
Measured on a virtual audio device's per-channel meters (engine output, independent of monitoring hardware - also visible on the repro's AudioMixer meters):
| Clip |
2D (spatialBlend 0) |
3D (spatialBlend 1) |
Import preview |
| 3ch (L/R/sub) |
no signal on any lane |
plays (spatialize fold) |
plays, labeled 2.1 |
| 6ch 5.1 (control) |
plays, discrete lanes |
plays |
plays |
| 7ch |
only the LFE lane carries signal (source ch4) |
plays |
plays |
No warning or error is logged - for music with sub-bass on channel 3, the whole asset is silent with no diagnostic. The LFE lane surviving while everything else drops suggests the 2D path's channel mapping bails partway rather than falling back to the fold that the 3D path and the import preview already use.
Questions
- Is the generator path intended to reject channel counts the clip path accepts? If by design, is extending the speaker-mode mapping (at minimum 3ch -> the 2.1 semantics the importer already displays) planned before the next LTS?
- Should 2D clip-path playback of no-layout counts fold like the 3D path does, or at least log why it can't?
Happy to file through the official bug reporter as well if that's preferred - raised here first since PR #1's example is directly affected.
Thanks!
Standard music deliverables with sub-bass on channel 3 (L/R/LFE) import fine, preview fine (the inspector labels them 2.1), and play through
AudioSource.clip- but they can't be hosted by the generator pipeline these examples are built on, and 2D playback on the clip path silently drops their channels. Filing here rather than only the bug reporter because the pattern in PR #1'sClipPlayerGeneratorinherits the first defect verbatim.Environment: reproduced on 6000.6.0b8; repro project settings derived from this repo's (6000.7 stream). Repro project:
three-channel-clip-repro- one scene, a 3ch / 6ch (5.1 control) / 7ch matrix in both Decompress On Load and Streaming variants, each playable viaAudioSource.clipand via a forwardingIAudioGenerator, with a 2D/3D toggle. Playback routes through an AudioMixer so lane activity is visible in the Audio Mixer window's Master meters.1.
AudioClip.CreateInstancerefuses channel counts the clip path playsAny generator that composes a clip as a nested instance - exactly what
ClipPlayerGeneratorin PR #1 does - throws for 3ch and 7ch clips:followed by "Assigned scriptable generator returned an invalid instance." and silence. The 6ch control clip instantiates and plays through the same wrapper, so this is specific to counts without a speaker mode, not multichannel generally. The requested nested
AudioFormatdoesn't enter into it - the clip's own channel count is refused.(Note for anyone reproducing: assigning a bare
AudioCliptoAudioSource.generatordoes not exercise this -clip,resource, andgeneratorare one backing slot and a bare clip plays the legacy way regardless of which property assigned it. Only a forwarding generator reachesAudioClip.CreateInstance- which is also the route every nested-generator/middleware use case takes.)2. 2D legacy playback silently drops these clips' channels
Measured on a virtual audio device's per-channel meters (engine output, independent of monitoring hardware - also visible on the repro's AudioMixer meters):
spatialBlend0)spatialBlend1)No warning or error is logged - for music with sub-bass on channel 3, the whole asset is silent with no diagnostic. The LFE lane surviving while everything else drops suggests the 2D path's channel mapping bails partway rather than falling back to the fold that the 3D path and the import preview already use.
Questions
Happy to file through the official bug reporter as well if that's preferred - raised here first since PR #1's example is directly affected.
Thanks!