Re: [Jack-Devel] Switch from CELT to Opus in JACK1/JACK2 sources

On 09/07/2012 08:06 PM, Adrian Knoth wrote:
> On 09/07/2012 05:33 PM, Robin Gareus wrote:
> 
>> The question boils down to this:
>>
>>   A)  use standard opus modes
>>      + makes some opus-devs and packagers happy
>>      - adds latency
>>      - adds code-complexity to jack (re-framing to N*120 frames)
>>      + possibly improved compressed sound-quality
>>
>>   B) use opus custom-modes.
>>      - may not be available on all systems
>>        (requires libopus to be compiled with --enable-custom-modes)
>>      + no additional latency
>>      + simple code in jack
>>      - possibly substandard compression quality
>>        (should still be better than celt, though)
> 
> Definitely B).
> 

Thanks for all the input so far.
Current standings: (A):0  (B):3

> JFTR, I think user ron_ is [hidden], the Debian Opus maintainer
> and an Opus upstream developer.

yes he is.

> If he refuses to compile with custom-modes, I'll happily embed the
> entire opus source in both jackd packages. ;)

heh, we crossed that argument at some point.

16:59 <+bemasc> In principle you might even want to fork libopus to mess
with 32- or 16-sample frames (or why not 4, while you're at it!).
[..]
17:24 < ron_> rgareus: forking or embedding the package wouldn't be a
great plan where there is a system lib available

> Unrelated:
> 
>> 22:50 <+bemasc> Interop may not be on the roadmap now, but I maintain
>> that it might make sense.  For example, I hope that live concert mixing
>> systems from different vendors will eventually interoperate over
>> multichannel Opus-RTP.
> 
> Lossy codec that can't go below 5ms for live concert mixing? LOL.
> 

indeed. at times it was a tiresome discussion..
With some of today's music, the lossy codec may actually not be a big
issue -  5ms latency OTOH can phase you away.. :) Too bad actually. RTP
would be way cooler than AVB.

2c,
robin

1347044381.11398_0.ltw:2,a <504A4418.4070409 at gareus dot org>