[pulseaudio-discuss] network audio compression

[Lennart Poettering]

On Mon, 03.08.09 09:15, pl bossart (bossart.nospam at gmail.com) wrote:

> 
> Hi Lennart,
> 
> > I see supporting AC3 pass-thru, Vorbis/Speex decompression and CELT
> > compression+decompression as different sides of a (three-sided...)
> > medal.
> 
> I can see why you'd want to support AC3 pass-thru (multichannel
> receiver) and CELT (network), it's not clear why you'd want
> Vorbis/Speex decompression. Would that be to allow compressed alerts
> in the server cache when using libcanberra?
> Thanks for your feedback.

Allowing a compressed cache would be a side-effect but the main reason
for supporting Vorbis/Speex is to minimize traffic. I.e. if you play a
vorbis file with PA across the network it would make more sense to the
decompression on the server side than on the client side -- which is
what currently happens.

Of course we could support other codecs too, but Vorbis/Speex/CELT
have the advantage that they can be used without getting into any
patent mess, and AC3 is similar because deocding would happen in
hw/pass-thru and not in software.

But this all is really complex, because VBR codecs break the timing
assumptions we currently make. So we'd need some very superficial
decoding of the data to get the timing right on both sides.

Also I have no interest in reimplementing GStreamer, so we need to
come up with some idea where the separation between PA in GSt actually
lies. Maybe PA should just integrate a gst pipeline for the actual
decoding (though probably not given that gobject/gst is hardly useful
for RT stuff). More likely we'd declare that PA would not do any
demuxing on its own, just take raw vorbis/speex/celt/ac3 frames or
so. Dunno, needs to figured out when the day comes.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4