Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Le vendredi 19 août 2011 21:54:20 Pierre-Louis Bossart, vous avez écrit : > > For this example, assume tlength is 500 ms and minreq is 50 ms. In > > adjust latency mode (which I understand is recommended for power > > efficiency), this is configured to the client's tlength/2 - minreq = > > 200 > > ms. The problem here is that if the client is filled up to only e g 130 > > ms, PulseAudio will take the 130 ms, the client will underrun, and hand > > out 70 ms of silence. A better behaviour would be to write the 130 ms > > that are available, and go to sleep until the 130 ms is almost up and > > see if more data has come in at that time. > > What is the value of the prebuf field here? If the playback started when > the buffer contains 200ms you would not see any underrun or rewind? In current VLC, prebuf is 0. Trigger is manual. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
Hello, Le vendredi 19 août 2011 21:02:59 David Henningsson, vous avez écrit : > I've spent most the afternoon trying to figure out why VLC doesn't work > well with a large tlengths. I seem to have found suboptimal behaviour on > both the PulseAudio and VLC sides. Nice. > What bothers me on the PulseAudio side is this call (in alsa-sink.c, > mmap_write): > > pa_sink_render_into_full(u->sink, &chunk); > > For this example, assume tlength is 500 ms and minreq is 50 ms. In > adjust latency mode (which I understand is recommended for power > efficiency), this is configured to the client's tlength/2 - minreq = 200 > ms. The problem here is that if the client is filled up to only e g 130 > ms, PulseAudio will take the 130 ms, the client will underrun, and hand > out 70 ms of silence. A better behaviour would be to write the 130 ms > that are available, and go to sleep until the 130 ms is almost up and > see if more data has come in at that time. > > However, things are probably not as bad as it looks. If a new package > comes in from the client in time, I believe PulseAudio would rewind back > the 70 ms of silence and write the new data, and no glitch will be > heard. So the worst thing is actually the somewhat "false alarm" sent to > the client. VLC currently assumes that a PulseAudio under-run event implies a silence/glitch. It uses it as an opportunity to resync the audio stream... this is not good if there was no actual under-run :-/ > However messing with PulseAudio's buffering mechanisms isn't giving me > warm and fuzzy feelings, at least not right before the 1.0 release :-D > > So over to the VLC side. I started off with the current git head of VLC. > > For the synchronisation, I believe the correct way is to do something like: > 1) when the first packet arrives, notice its timestamp (pts), and set a > system timer to trigger at that point in time (i e trigger in i->pts - > mdate() usecs) Yeah. That would certainly be better than the current zero padding of the stream, especially when resuming from pause (i.e. PulseAudio uncorking). But but, VLC does not have a mainloop. A timer is going to need a dedicated thread. Or maybe libpulse can accept user timers in its threaded mainloop? > 2) the callback from the system timer would then uncork/trigger the stream. > At that point, PulseAudio's buffer has been filled up by all the other > calls to Play that happened in between. > > I did a quick hack myself: I didn't know how to do system timers in VLC > so I set it to check at every call to Play, if it was yet time to start > the stream. (And commented out the call to stream_resync.) That gave > good synchronisation as well as I could see (being layman on observing > synchronisation issues). vlc_timer_*() functions. But I'd rather use the Pulse mainloop if possible. > For the buffering attributes, I tried setting tlength to 500 ms (note: > AOUT_MAX_PREPARE_TIME is actually 2000 ms, not 500 ms as I originally > thought). > Given an initial filled buffer as suggested above, that did not > underrun. That was with playing back a local video file. > I set minreq to AOUT_MIN_PREPARE_TIME (40 ms), which is mostly taken out > of the air. > > However, given the reasoning above, if you want to be certain to avoid > the false underrun alarms as outlined in the PulseAudio section, I > believe a minreq of AOUT_MIN_PREPARE_TIME and tlength of > AOUT_MIN_PREPARE_TIME * 4 = 160 ms should be a relatively safe setting. In my experience, larger tlength caused more underruns. But maybe that's because VLC is more likely to be continuously late? > Also remember to set the PA_STREAM_ADJUST_LATENCY flag. It's not clear to me what this actually will do. > Hopefully this gives a little insight in the current problems with VLC > and PulseAudio! -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] VLC, PulseAudio and large tlengths
> For this example, assume tlength is 500 ms and minreq is 50 ms. In > adjust latency mode (which I understand is recommended for power > efficiency), this is configured to the client's tlength/2 - minreq = > 200 > ms. The problem here is that if the client is filled up to only e g 130 > ms, PulseAudio will take the 130 ms, the client will underrun, and hand > out 70 ms of silence. A better behaviour would be to write the 130 ms > that are available, and go to sleep until the 130 ms is almost up and > see if more data has come in at that time. What is the value of the prebuf field here? If the playback started when the buffer contains 200ms you would not see any underrun or rewind? -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Making locking nicer for NFS
Sorry for breaking the threading, but I only just subscribed to the list so I can't reply properly. I'm the origin of the patch recently posted by David Henningsson which alters the way locking works. Maarten Bosmans had some questions I'd like to address. The confusing formatting of the diff in core-util.c is just unidiff being clever. Basically I created a new function to wrap around fcntl to share the common code between pa_lock_fd and pa_read_lock_fd. I have no objection of course to simply defining it unconditionally and using it always. I do not know Windows, so I was trying to make the minimally disruptive change. I didn't know that Windows has read locks. In Unix, promoting a read lock to a write lock converts the lock--it does not add another lock--without releasing the readlock in the middle. I am not wedded at all to the specific details of what the generic functions in core-util.c do. The root issue is as David Henningsson explained. By using an exclusive lock, pulseaudio creates an unnecessary contention in reading the .pulse-cookie file, and because of the less-than-ideal (but quite unchangeable) behavior of NFSv3, this forces a thirty-second delay anytime two pulse clients try to read the cookie at the same time. Switching to a read lock for the read, and only using an exclusive lock when the cookie needs to be written (a much rarer operation), avoids this problem entirely. Thomas ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] VLC, PulseAudio and large tlengths
I've spent most the afternoon trying to figure out why VLC doesn't work well with a large tlengths. I seem to have found suboptimal behaviour on both the PulseAudio and VLC sides. What bothers me on the PulseAudio side is this call (in alsa-sink.c, mmap_write): pa_sink_render_into_full(u->sink, &chunk); For this example, assume tlength is 500 ms and minreq is 50 ms. In adjust latency mode (which I understand is recommended for power efficiency), this is configured to the client's tlength/2 - minreq = 200 ms. The problem here is that if the client is filled up to only e g 130 ms, PulseAudio will take the 130 ms, the client will underrun, and hand out 70 ms of silence. A better behaviour would be to write the 130 ms that are available, and go to sleep until the 130 ms is almost up and see if more data has come in at that time. However, things are probably not as bad as it looks. If a new package comes in from the client in time, I believe PulseAudio would rewind back the 70 ms of silence and write the new data, and no glitch will be heard. So the worst thing is actually the somewhat "false alarm" sent to the client. However messing with PulseAudio's buffering mechanisms isn't giving me warm and fuzzy feelings, at least not right before the 1.0 release :-D So over to the VLC side. I started off with the current git head of VLC. For the synchronisation, I believe the correct way is to do something like: 1) when the first packet arrives, notice its timestamp (pts), and set a system timer to trigger at that point in time (i e trigger in i->pts - mdate() usecs) 2) the callback from the system timer would then uncork/trigger the stream. At that point, PulseAudio's buffer has been filled up by all the other calls to Play that happened in between. I did a quick hack myself: I didn't know how to do system timers in VLC so I set it to check at every call to Play, if it was yet time to start the stream. (And commented out the call to stream_resync.) That gave good synchronisation as well as I could see (being layman on observing synchronisation issues). For the buffering attributes, I tried setting tlength to 500 ms (note: AOUT_MAX_PREPARE_TIME is actually 2000 ms, not 500 ms as I originally thought). Given an initial filled buffer as suggested above, that did not underrun. That was with playing back a local video file. I set minreq to AOUT_MIN_PREPARE_TIME (40 ms), which is mostly taken out of the air. However, given the reasoning above, if you want to be certain to avoid the false underrun alarms as outlined in the PulseAudio section, I believe a minreq of AOUT_MIN_PREPARE_TIME and tlength of AOUT_MIN_PREPARE_TIME * 4 = 160 ms should be a relatively safe setting. Also remember to set the PA_STREAM_ADJUST_LATENCY flag. Hopefully this gives a little insight in the current problems with VLC and PulseAudio! -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulse-cookie locking in NFS causes 30 second delays
I can't really comment on the bug itself or the necessity of changing
the locking scheme.
About the proposed patch:
First: that hunk in core-util is formatted very confusingly, but I
guess that is just the result of diff being stupid there.
If the right solution is to add pa_read_lock_fd, the I think it should
be defined unconditionally (i.e. not protected by HAVE_READ_LOCKS) and
the implementation should fall back to pa_lock_fd for a write lock if
F_SETLKW is not defined, so that the stuff on Windows keeps working
(I'll fix it up properly to use a read lock later)
Also, the semantics of promoting a read lock to a write lock need to
be defined in a comment in core-util.c. From the patch it looks like a
promoted lock needs to be unlocked only once, but at least on Windows
two unlock operations are needed.
Maarten
2011/8/19 David Henningsson :
> Hi,
>
> I came across this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269
>
> Which claims the following (and also offers a patch [1] to fix it). I don't
> know much about file locking or NFS, but maybe someone here knows more than
> I here.
>
> Quoting the bug:
>
> Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is
> manipulated by the code in src/pulsecore/authkey.c. Currently it does this
> to read the key:
> 1) Open the file
> 2) Acquire a write-lock for the file.
> 3) Read the file.
> 4) If the file is not a good cookie, generate a new cookie and write it to
> the file.
> 5) Close the file.
>
> If more than one thread is opening the cookie at once, then there is
> contention at step (2) which is rarely necessary. Instead, step (2) should
> acquire only a read-lock, and then step (4) should promote that to a
> write-lock before writing the file.
>
> This is particularly bad in the case where the .pulse-cookie file is on NFS.
> In that case, the lock contention forces a thirty-second backoff from
> whichever thread gets there second.
>
> I am happy to work with y'all in engineering a patch for this. It requires
> obviously a change to src/pulsecore/authkey.c, and a corresponding one in
> src/pulsecore/core-util.c where the actual lock syscall occurs.
>
> The following script (if ~ is in NFS) will demonstrate the problem. The two
> pactl processes both try to acquire the lock on the file simultaneously, and
> whichever one loses will take thirty seconds before it wins, because of the
> needless contention (and the unfortunate facts of how lockd in NFS works).
>
> !/bin/bash
>
> NUM_PROCS=2
>
> procs=()
> for i in $(seq 1 $NUM_PROCS); do
> pactl list > /dev/null &
> procs[$i]=$!
> done
> for i in $(seq 1 $NUM_PROCS); do
> wait ${procs[$i]}
> done
>
>
> --
> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic
>
> [1] https://launchpadlibrarian.net/77550336/use-read-locks
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulse-cookie locking in NFS causes 30 second delays
'Twas brillig, and David Henningsson at 19/08/11 09:21 did gyre and gimble:
> Hi,
>
> I came across this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269
>
> Which claims the following (and also offers a patch [1] to fix it). I
> don't know much about file locking or NFS, but maybe someone here knows
> more than I here.
>
> Quoting the bug:
>
> Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is
> manipulated by the code in src/pulsecore/authkey.c. Currently it does
> this to read the key:
> 1) Open the file
> 2) Acquire a write-lock for the file.
> 3) Read the file.
> 4) If the file is not a good cookie, generate a new cookie and write it
> to the file.
> 5) Close the file.
>
> If more than one thread is opening the cookie at once, then there is
> contention at step (2) which is rarely necessary. Instead, step (2)
> should acquire only a read-lock, and then step (4) should promote that
> to a write-lock before writing the file.
>
> This is particularly bad in the case where the .pulse-cookie file is on
> NFS. In that case, the lock contention forces a thirty-second backoff
> from whichever thread gets there second.
>
> I am happy to work with y'all in engineering a patch for this. It
> requires obviously a change to src/pulsecore/authkey.c, and a
> corresponding one in src/pulsecore/core-util.c where the actual lock
> syscall occurs.
>
> The following script (if ~ is in NFS) will demonstrate the problem. The
> two pactl processes both try to acquire the lock on the file
> simultaneously, and whichever one loses will take thirty seconds before
> it wins, because of the needless contention (and the unfortunate facts
> of how lockd in NFS works).
>
> !/bin/bash
>
> NUM_PROCS=2
>
> procs=()
> for i in $(seq 1 $NUM_PROCS); do
> pactl list > /dev/null &
> procs[$i]=$!
> done
> for i in $(seq 1 $NUM_PROCS); do
> wait ${procs[$i]}
> done
>
>
On first glance, this seems sensible, but I'd like Lennart's comment on
this one as locking is one area I don't feel super confident playing
around with!
Lennart, thoughts? See the link for the proposed patch.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] unable to play very small beep (.wav) sounds
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? 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? and what is "rewrite" here in terms of pulseaudio? (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 ? ) Thanks in advance, Best Regards, Himanshu ** On Thu, Jul 28, 2011 at 1:55 PM, Tanu Kaskinen wrote: > On Thu, 2011-07-28 at 11:56 +0530, Himanshu Chug wrote: > > Hi Tanu > > > > I guess you are right, I am able to play the same beep.wav with paplay > and > > pacmd play-file without any issues. > > seems like issues with gstreamer (pulsesink? ) any hints .. ? > > Make sure you have the patches applied in your pulseaudio and gstreamer > that are talked about in this thread: > > http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-June/010305.html > > If you already have those, I don't have any further hints. > > -- > Tanu > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Pulse-cookie locking in NFS causes 30 second delays
Hi,
I came across this bug:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/817269
Which claims the following (and also offers a patch [1] to fix it). I
don't know much about file locking or NFS, but maybe someone here knows
more than I here.
Quoting the bug:
Pulseaudio uses a cookie file (normally ~/.pulse-cookie). This file is
manipulated by the code in src/pulsecore/authkey.c. Currently it does
this to read the key:
1) Open the file
2) Acquire a write-lock for the file.
3) Read the file.
4) If the file is not a good cookie, generate a new cookie and write it
to the file.
5) Close the file.
If more than one thread is opening the cookie at once, then there is
contention at step (2) which is rarely necessary. Instead, step (2)
should acquire only a read-lock, and then step (4) should promote that
to a write-lock before writing the file.
This is particularly bad in the case where the .pulse-cookie file is on
NFS. In that case, the lock contention forces a thirty-second backoff
from whichever thread gets there second.
I am happy to work with y'all in engineering a patch for this. It
requires obviously a change to src/pulsecore/authkey.c, and a
corresponding one in src/pulsecore/core-util.c where the actual lock
syscall occurs.
The following script (if ~ is in NFS) will demonstrate the problem. The
two pactl processes both try to acquire the lock on the file
simultaneously, and whichever one loses will take thirty seconds before
it wins, because of the needless contention (and the unfortunate facts
of how lockd in NFS works).
!/bin/bash
NUM_PROCS=2
procs=()
for i in $(seq 1 $NUM_PROCS); do
pactl list > /dev/null &
procs[$i]=$!
done
for i in $(seq 1 $NUM_PROCS); do
wait ${procs[$i]}
done
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
[1] https://launchpadlibrarian.net/77550336/use-read-locks
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
