[pulseaudio-tickets] [Bug 56993] Implement opus audio compression

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=56993

--- Comment #16 from Arun Raghavan <arun at accosted.net> ---
(In reply to Tanu Kaskinen from comment #15)
> (In reply to Arun Raghavan from comment #14)
> > (In reply to Tanu Kaskinen from comment #13)
> > > So, are you against any compression support in the native protocol or not?
> > 
> > I am not in favour of having encoding/decoding being part of our protocol.
> > This added complexity in the native protocol is not worth the gains for the
> > (imo) relatively uncommon use-case of tunnel modules.
> 
> Ok, so if it was up to you, tunnels would never ever transparently compress
> the audio that gets sent over the network, because that causes an
> uncomfortable amount of complexity in the native protocol.

Actually, I did later add a way forwards -- support for compressed audio in the
protocol (with compression left to clients, which tunnel could potentially do).

It's not just uncomfortable complexity, but also a commitment to a single
codec, a single implementation of that codec, or later exploding our internals
to become a mini multimedia framework if we want to support more. 

> > I'm not against the native protocol supporting compressed audio. i.e.
> > clients providing compressed audio for devices that support compressed
> > playback. in fact, this is something I would actively like to have, but
> > there are tricky bits to deal with latency reporting, rewinds, etc.
> 
> Isn't this already supported? Or do you mean avoiding the IEC61937 wrapping?

I mean without IEC61937 payloading, yes. Think AAC/MP3 in Bluetooth, or an ALSA
compressed device that does decode + render.

> > That said, if we had this, then the tunnel modules themselves could do the
> > encode/decode.
> 
> I don't follow.
> 
> > I am curious about your views on this -- do you think this is something we
> > should add to the native protocol, or are you batting for this since the
> > work has been done, or ...?
> 
> In my opinion tunnels should not be forever doomed to waste bandwidth. The
> patch that was submitted should be reviewed, and I wouldn't like to give a
> response of "will not accept the feature, don't try again". I haven't looked
> deeply into the patch, so I don't know how close it's to my liking, but in
> principle transparent encoding/decoding in the TCP transport doesn't seem
> very complicated. It shouldn't affect e.g. rewinding, if all buffers are
> PCM, and just the in-transit data is compressed.

Except of course, it affects all the transports of the native protocol, not
just TCP.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20170822/d312b050/attachment.html>