[pulseaudio-discuss] native-protocol-tcp vs esound-protocol-tcp

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 12/05/10 06:10 did gyre and gimble:
> On Wed, 2010-05-12 at 03:48 +0700, Antoine Martin wrote:
>> Aren't there any open-source codec frameworks that could easily be
>> plugged into the tcp transport?
> 
> All I know is that when compression gets implemented, it will be done
> using the CELT codec (http://www.celt-codec.org/).
> 

AFAIUI, The main issue is to do with timing. The codec support is, in
part, to provide good support for Bluetooth. The idea is that we can
pass through codecs if at all possible, e.g. passing ac3 encoded audio
to a 5.1 system is certainly desirable, but we need to be able to easily
extract from the encoded stream the timing required. This extraction
needs to be (ideally) very light weight - e.g. it shouldn't require a
full decode of the data ideally.

Because of this codec support, the plugging of compression into the
tunnel protocol is unlikely to happen until the groundwork of the codec
support is in place and we can reuse that structure.

That's certainly my understanding of things, but I could be quite off.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]