[pulseaudio-discuss] GSoC: Call for project ideas

Ian Malone ibmalone at gmail.com
Mon Mar 25 00:57:46 PDT 2013

On 25 March 2013 06:13, David Henningsson
<david.henningsson at canonical.com> wrote:
> On 03/23/2013 12:11 PM, Toby Smithe wrote:

>> becomes impractical, with drops and latency problems. A while ago, I
>> looked into implementing Opus compression for the network streams, but
>> never had a chance. I think Opus would make the ideal codec because it
>> is very flexible, recently ratified as an Internet standard, and can be
>> remarkably lightweight (according to the official benchmarks).

By the way, aside from the concerns about using a lossy codec in my
other email, Opus would be exactly the right choice, though you
haven't pointed out a major reason: it's explicitly designed for low

>> In doing these network audio, I might also be able to move on to
>> auxiliary tasks like improving the GUI tools for this use-case.
>> Do you think this might work?
> I think it sounds interesting. Networked audio (and its latency) is indeed
> something people complain about every now and then.
> But Opus is just a codec, right? Or does it also specify how it is actually
> transferred over the network (UDP/TCP etc)?
> Are you planning to extend our RTP module with Opus support?
> In short; Opus might be one piece of the puzzle to get reliable low-latency
> streaming, but could you also outline how you think about the network stack
> part?

There is a RTP transport defined for Opus,
http://tools.ietf.org/html/draft-spittka-payload-rtp-opus though you
don't have to use it.

By the way, FLAC compression for 16bit 44.1kHz I get a ~ 2:1 compression.


More information about the pulseaudio-discuss mailing list