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
