<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement opus audio compression" href="https://bugs.freedesktop.org/show_bug.cgi?id=56993#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement opus audio compression" href="https://bugs.freedesktop.org/show_bug.cgi?id=56993">bug 56993</a> from <a class="email" href="mailto:arun@accosted.net" title="Arun Raghavan <arun@accosted.net>"> Arun Raghavan</a> <pre>(In reply to Tanu Kaskinen from <a href="show_bug.cgi?id=56993#c15">comment #15</a>) > (In reply to Arun Raghavan from <a href="show_bug.cgi?id=56993#c14">comment #14</a>) > > (In reply to Tanu Kaskinen from <a href="show_bug.cgi?id=56993#c13">comment #13</a>) > > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>