> themselves. Since Web Audio needs standard layouts, I suggest we use those.
> The current spec for them is here: https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#ChannelLayouts > There's ongoing discussion in public-audio about how to extend those to > cover more channels. We can track whatever happens there. There are basically two commonly used channel orderings. The WAV orderings (used by WAV files) and what I will call the Vorbis orderings (which for 5 or more channels, follow the Dolby orderings used by, e.g., AC3 and AAC, and uses the obvious reductions of those to fewer channels). The Web Audio spec appears to be using the WAV ordering for 5.1. I suggest they also follow that ordering for 3 channels and for 5.0. For 6.1 and 7.1, the WAV ordering actually depends on whether you call your channels "side left" and "side right" or "back left" and "back right" (while, of course, the actual standards call them "surround left" and "surround right", which is neither of those things). We recently spent a few months going around about what to do about this mess on flac-dev (because FLAC also uses the WAV ordering). We finally reached a decision in this thread: http://lists.xiph.org/pipermail/flac-dev/2013-January/003568.html. It would be nice if they came to the same decision. > At some point we'll probably need to support variable/custom layouts, which > will require passing around some kind of metadata with audio buffers, but I > think we shouldn't worry about that now. We thought we would need to do this for Vorbis, too. A decade and a half later, we still haven't seen any demand for it. > appreciated. (I suppose that high-quality mixing might need to be stateful, > in which case we probably would define a different interface for that.) I wouldn't worry about this too much. In theory the optimal matrices are actually frequency-dependent, but we'd have to get pretty bored before modelling this got to the top of our priority list. > Web Audio requires non-interleaved channels. I think we should adopt that > everywhere we can. For a buffer that needs to be appended to frequently, > consider AudioSegment and AudioChunk; an AudioSegment is a sequence of > AudioChunks, and each AudioChunk is a sub-interval over a set of immutable > channel buffers. I agree. The libvorbis/Tremor APIs already produces channels in non-interleaved buffers. I actually wish the libopus API did, too (it would have reduced the amount of copying we had to do internally and saved some buffer space). > output. I think we need to extend libcubeb to try to get the "ideal" number > of channels (and, ultimately, layout!) from the OS. (And the ideal rate > too, if we can.) Then for any output stream that can vary its number of This sounds reasonable, though you still have the problem of what happens when someone with a 5.1 speaker system hooked up to their desktop plugs in a headset (which is still a slightly easier problem, as a small discontinuity when this happens is not a big deal compared to having to physically put the headset on). _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
