On 9/21/14, 8:15 AM, Kiran Krishnappa wrote: > >>Someone on IRC was writing up, > >>I think, but I don't know what state that got to. > > > Arun, below is the status of compressed sink: > > I was facing some issues in reporting timing to PA client. The compress > library that I am using does provides an API to query playback time from > DSP. Initially, I thought of adding a new API (for passthrough streams > only)to protocol-native to obtain correct timing from driver. Dropped > that idea, decided to stuff the timing info in response to > "pa_stream_update_timing_info" info. It seems the timing reporting issue > is resolved now. ?? There should be support to query the time from the compress API, without it the implementation is clearly broken. > Now , I need to look into timing issue in case of seek operation. This can't be handled in PulseAudio, you have to do it somewhere else (gstreamer) > > Apart from this, > * there were couple of changes at gstreamer side (pulsesink) to avoid > packeting data into IEC frames What? This is needed to force PulseAudio to keep working with its default byte->time conversion. If you removed the padding and packetization the timing will be completely in the weeds > * Introduced new API's to tinycompress to get device file descriptor > which inturn added to pa_rtpoll_run can you share this code please? > * Not sure how to calculate sink latency in case variable bitrate You can keep track of the IEC frames you provided to the sink and work from there: it's constant bitrate. Of course if you removed the IEC framing you are on your own... > > Regards, > Kiran > > > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >
