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, 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 ??
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 ?
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?
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?
Thanks,
Himanshu
On Sun, Aug 21, 2011 at 5:21 PM, David Henningsson <
[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
>
> ______________________________**_________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.**freedesktop.org<[email protected]>
> http://lists.freedesktop.org/**mailman/listinfo/pulseaudio-**discuss<http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss>
>
beep-not-working-with-gst-launch
Description: Binary data
beep-working-with-pacmd-playfile
Description: Binary data
_______________________________________________ pulseaudio-discuss mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
