On 08/22/2011 01:35 PM, Himanshu Chug wrote:
Hi Tanu, All,
I have an up-to-date gst pulse-sink with latest patches from David,
but this issue remains same.
_Background_: We are stablizing our audio driver on OMAP4 platform,
You might want to hang out in the #ubuntu-arm channel on freenode, at
least if your product is Ubuntu based. OMAP4 is one of the platforms
they are working with.
there are lot of changes went into our audio driver recently which break
this use-case which was working fine earlier with same PA and gst setup
but with old kernel and ALSA driver.
so there might no changes needed in PA and gst-pulsesink and I am trying
to understand the actual issue here and to avoid the work-around of
modifying the
tsched_buffer_size=1024 which says: -the use-case is always working
fine by loading module-alsa-sink with tsched_buffer_size=1024
I am new to PA, so some of my questions sounds very basic, but I want to
dive deep into code details to get hold this problem , I seeks few
clarifications from here:
From protocol-native.c handle_seek( ) function we are getting rewinds
due to rewrite on the condition when sink's read index is greater than
write index,
The comment says " /* OK, the sink already asked for this data, so
let's have it ask us again */
indexr = pa_memblockq_get_read_index(s->memblockq);
if (indexw < indexr) {
/* OK, the sink already asked for this data, so
* let's have it usk us again */
pa_log_debug("Requesting rewind due to rewrite.");
pa_sink_input_request_rewind(s->sink_input, (size_t)
(indexr - indexw), TRUE, FALSE, FALSE);
}
as per my understanding,
PA is going to write audio buffers on write index and update write index
after every write.
ALSA sink is going to read audio buffers from read index and update the
read index after every read.
here we are rewinding back (indexr - indexw) size due to PA rewrite, but
practically what causes the situation where indexr > indexw ??
When your client buffer is empty, your sink input hands out silence to
PulseAudio internally. When you send in a new packet, that's internally
being treated as an overwrite/rewind of the silence previously handed out.
1. Is ALSA not in Sync (to slow or too fast) in reading the buffers ?
2. Is gst-plusesink not giving enough buffers in time when ALSA needs ?
3. or something else ?
Given your log, you seem to start off with an empty buffer. This was
fixed in gstreamer a while ago. See
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/ext/pulse/pulsesink.c?id=8ca094795add18733faeb2a1f335bb33f40f9894
- and perhaps a few of the following commits as well.
4. handle_seek( ) called , why we need to seek streams in a smooth
playback scenario ? the same function is not called from pacmd play-file
scenario and the beep worked fine always here?
What is your Pulseaudio version? I'm not 100% sure, but from your log it
looks like you're missing the optimisation in PulseAudio that does not
split seek and write in two, which probably means you're missing the
other optimisation as well. Don't know how much that will help in this
case though.
Attached are the PA logs for beep (click.wav) playback 1. working fine
with pacmd play-file 2. Not working with gst-launch
Any comments/clarifications are helpful?
Recommend upgrading to latest stable releases of Gstreamer and
PulseAudio unless already done so.
Thanks,
Himanshu
On Sun, Aug 21, 2011 at 5:21 PM, David Henningsson
<[email protected]
<mailto:[email protected]>> wrote:
On 08/20/2011 06:12 PM, Tanu Kaskinen wrote:
On Fri, 2011-08-19 at 14:08 +0530, Himanshu Chug wrote:
Hi All
I am able to get the small beep files working consistently
using gst-launch
now by modifying tsched_buffer_size param of
module-alsa-sink like:
load-module module-alsa-sink tsched_buffer_size=1024,
(buffer size is default to 2s)
I am using timer based tsched audio scheduling , on OMAP4
platform.
I have few questions:
Q1. how does this change affect my system, if I always make
tsched_buffer_size=1024? I suspect it may increase the power
consumption and increase the ALSA
wakeup's , if I reduce the buffer size and period like like
this?
Yes.
Q2. When the beep file is not played on speakers , I can see
a lot of rewind
prints from PA
protocol-native.c: Requesting rewind due to rewrite. and it
continues and
finally I got EOS from my gst pipeline
I need to know what is rewind ? and what triggers PA to make
these rewinds?
As the log message says, the rewrites cause the rewinds.
and what is "rewrite" here in terms of pulseaudio?
It means rewriting part of the sink (hw) buffer. If that log message
appears, it means that the client has written data to a position
that
requires a part of the sink's buffer to be overwritten, and thus a
rewind is needed.
(Just to remind you I can play the beep wav with paplay and
pacmd
play-file, without any issues and without modifying the
buffersize param.
so I am just confused whats going here ? )
So did you find out whether your system has David's patches that I
referred to in my previous reply? If you did, and the patches are
applied, then there's still something to fix in Pulseaudio's and
Gstreamer's interaction.
Btw, I posted an improved version of the patch a few days ago to the
gstreamer mailinglist, and it has been committed. See
http://cgit.freedesktop.org/__gstreamer/gst-plugins-good/__commit/ext/pulse/pulsesink.c?__id=__e70020b45630d99132a99892ecc6e1__dcd1ce6f8a
<http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/ext/pulse/pulsesink.c?id=e70020b45630d99132a99892ecc6e1dcd1ce6f8a>
Hopefully that can help.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic <http://launchpad.net/%7Ediwic>
_________________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.__freedesktop.org
<mailto:[email protected]>
http://lists.freedesktop.org/__mailman/listinfo/pulseaudio-__discuss
<http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss>
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
