[opus] Antw: Re: Antw: [EXT] Opus merging streams

[Andrew Sonzogni]

Thanks for the info !

Then I have a question. What kind of mixer algorithms can be used to mix 
3 different channel together on an embedded system ?

I've used this one but it's not THAT good: (chan1 + chan2 + chan3) / 3

The output signal may peak or be buggy some times.

For your information, I'm using an ARM M4F with Opus configured like 
this (40ms, 16kHz, 16 bitrate, 0 compres).


Kind regards,

Andrew

Le 06/04/2022 à 08:36, Sampo Syreeni a écrit :
> On 2022-04-06, Ulrich Windl wrote:
>
>> Incidentially I came across a Dolby Atmos demo that had about 118 
>> channels wirh 24bit audio at 48kHz, all in one huge WAV file yesterday.
>
> Is that even a legitimate encoding?! What the fuck.
>
>> When I tried to play that (in plain stereo) with audiacity, even my 
>> fast computer (i7 at 4GHz) had dropouts. So I can imagine that 
>> decoding a large number of channels and mixing those seems to be a 
>> bad idea.
>
> It is. Which is why my favourite ambisonics exists (sales pitch): it's 
> a principled and nigh entropically speaking optimum way to fold down a 
> static central soundfield down to a number of channels. Third order, 
> so sixteen channels, seems to be upto the task for *any* central 
> isotropic soundfield at all, and the system yields to static 
> optimization.
>
> I cannot for the life of me understand why Atmos exists. Except for 
> patent patent law or something like that. If it was used to express a 
> live gaming or augmented reality setup, with arbitrary auditory 
> parallax, I could get the point. But that's not what Atmos or even 
> Dolby AC-4 are about. They just encode a static scene -- in a way 
> *much* more complicated and heavier on the processor than a "simple" 
> third degree periphonic ambisonic HOA signal set would be, and in a 
> manner not amenable to low resource optimizations in surround sound. 
> The object based encoding simply seems stupid and superfluous.
-- 

	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20220406/e983e1da/attachment.htm>