Here's a first proposal that I think avoids major disruption in the development. Two new routines are added to specify the pa_stream will transport non PCM data. This new extended type will be passed through the native protocol instead of the 'passthrough' flag I added earlier, and all sinks/sink-inputs/sources/source-outputs on the server side will make use of this extended representation. It'd be nice to have a means to query what the sink capabilities are before creating a stream with a non-PCM type, but you don't know on what sink you will play until you actually connect and server-side heuristics/audio policy kick-in. The expected behavior on the client side is that if the connect_playback call fails with compressed data, the application will have to reconfigure its pipeline to provide PCM data and retry. The simple API remains simple and handles PCM only. Feedback welcome -Pierre -------------- next part -------------- A non-text attachment was scrubbed... Name: stream-api.patch Type: application/octet-stream Size: 6456 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100923/0218cbac/attachment.obj>
