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
