GSoC: Call for project ideas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
latency.

>> 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.

-- 
imalone
http://ibmalone.blogspot.co.uk


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux