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

[Antoine Martin]

On 05/12/2010 03:54 AM, Antoine Martin wrote:
> On 05/12/2010 03:48 AM, Antoine Martin wrote:
>> On 05/11/2010 11:29 PM, Tanu Kaskinen wrote:
>>> On Tue, 2010-05-11 at 12:21 +0700, Antoine Martin wrote:
>>>    
>>>> Add-to-wishlist: ability to use codecs here would be nice. I doesn't
>>>> look like I can use ladspa plugins over the tunnel, or can I? If so, how?
>>>> 1.4Mbit/s is a little high when most modern cpus can compress audio to
>>>> 192Kbit/s on the fly without consuming any significant amount of CPU.
>>>>      
>>> The lack of compression is a known bug :) AFAIK nobody is currently
>>> working on the feature, though.
>>>    
>> That's a shame.
>> Especially since it consumes the whole bandwidth allocation whether 
>> actual sound is being played or not! Ouch.
>> Well, at least when using an ssh tunnel with CompressionLevel=9 you 
>> can reduce that down to around 220Kbit/s when idle. (from 1.4Mbit/s) 
>> I haven't tried with single-channel 22KHz yet.
> Correction, that's ~56Kbit/s idle. (~25 times less, decent saving)
> (and no noticeable change when playing real audio)
FYI: using gstreamer's TCP transport on the same streams, using code 
based on this example:
http://www.jejik.com/articles/2007/01/streaming_audio_over_tcp_with_python-gstreamer/

I get ~56Kbit/s whilst in use. Not bad compared to 1.4Mbit/s!

Antoine

>
>>
>> The SSH transport is not the best place to be doing this sort of 
>> compression!
>> Aren't there any open-source codec frameworks that could easily be 
>> plugged into the tcp transport?
> [snip]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100514/7ecd7475/attachment.htm>