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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
