This should make it unlikely that we loop on SIGHUP indefinitely.
Also, this makes it possible for callbacks not to process all events and
still not busy loop.
If two clients try to cleanup the SHM directory at the same time, they
might want to open and then delete the same segment at the same time, in
which case one client might win, the other one lose. In this case, don't
warn about ENOENT.
Apperently reading from an eventfd can fail, which results in an assert
to be hit. I am not sure about the reason for the failure, but in
attempt to track down the issue the next time is hit this prints a more
useful log message.
https://bugzilla.redhat.com/attachment.cgi?id=386380
All seeks/flushes that depend on the playback buffer read pointer cannot
be accounted for properly in the client since it does not know the
actual read pointer. Due to that the clients do not account for it at
all. We need do the same on the server side. And we did, but a little
bit too extreme. While we properly have not applied the changes to the
"request" counter we still do have to apply it to the "missing" counter.
This patch fixes that.
Do not subtract bytes the client sends us beyond what we requested from
our missing bytes counter.
This was mostly a thinko that caused servers asking for too little data
when the client initially sent more data than requested, because that
data sent too much was accounted for twice.
This commit fixes this miscalculation.
http://bugzilla.redhat.com/show_bug.cgi?id=534130
Unless the port number is explicitly configured we will now fallback to
a kernel picked port if the one we'd like by default we cannot get.
http://pulseaudio.org/ticket/773
Hi,
I found that volume ramping is inside PA now.
there's a minor fix here, it is a bug i found after the patch is submitted:
line 1781 of sink-input.c :
if ((i->thread_info.ramp_info.envelope_dying - nbytes) <= 0) {
need to be changed to
if ((i->thread_info.ramp_info.envelope_dying - (ssize_t) nbytes) <= 0) {
otherwise this argument will never be negative since nbytes is of type
size_t which is unsigned.
Please change it when you have time, sorry if bring any inconvenience. :)
Note also the willneed/will_need inconsistency. I guess it could be nice to ASAP
choose one of them and introduce a backward compatibility hack for the other.
The issues was mostly found with:
for a in $(grep -r '^[ /]\*.*()' $(
find -name '*.[ch]') |
sed 's,^.* \([^ ]*\)().*$,\1,g' |
sort |
uniq |
grep ^pa_)
do
grep -rq "^.[^*].*\<$a(" $(find * -name '*.h') || echo $a
done
On all the platforms I tested, PulseAudio is frequently awaken and
doesn't sleep for the duration specified for the poll timeout.
Sometimes wake-ups occur within milliseconds of the poll call for no
good reason; this seems to be related to ALSA issues (see my posts on
the ALSA mailing list on null poll events).
This patch enables a better log of requested sleep times v. actual
sleep times. Enable DEBUG_TIMING to see actual messages. Please let me
know if you see odd behaviors like the one below
- Pierre
E: rtpoll.c: rtpoll_run
E: rtpoll.c: poll timeout: 188 ms
E: rtpoll.c: Process time 0 ms; sleep time 48 ms
E: rtpoll.c: rtpoll_run
E: rtpoll.c: rtpoll finish
E: rtpoll.c: rtpoll_run
E: rtpoll.c: poll timeout: 139 ms
E: rtpoll.c: Process time 0 ms; sleep time 49 ms
E: rtpoll.c: rtpoll_run
E: rtpoll.c: rtpoll finish
E: rtpoll.c: rtpoll_run
E: rtpoll.c: poll timeout: 189 ms
E: rtpoll.c: Process time 0 ms; sleep time 0 ms
E: rtpoll.c: rtpoll_run
E: rtpoll.c: rtpoll finish
E: rtpoll.c: rtpoll_run
E: rtpoll.c: poll timeout: 189 ms
E: rtpoll.c: Process time 0 ms; sleep time 49 ms
Fix missing argument to pa_read(), and be consistent with declaration of
state variable in pa_cpu_init_arm().
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
pulsecore/cpu-arm.c: In function 'get_cpuinfo':
pulsecore/cpu-arm.c:70: warning: implicit declaration of function 'pa_read' [-Wimplicit-function-declaration]
pulsecore/cpu-arm.c:72: warning: implicit declaration of function 'pa_close' [-Wimplicit-function-declaration]
pulsecore/cpu-arm.c: In function 'pa_cpu_init_arm':
pulsecore/cpu-arm.c:110: warning: implicit declaration of function 'pa_split_spaces' [-Wimplicit-function-declaration]
pulsecore/cpu-arm.c:110: warning: assignment makes pointer from integer without a cast
Function `pa_split_spaces' implicitly converted to pointer at pulsecore/cpu-arm.c:110
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
At least for pipes, recv() with MSG_PEEK does actually eat up data from
file descriptors. Hence, this can't be used for PULLHUP emulation.
Use another ioctl hack for that.
Even on 10.5.8, poll() does not do the right thing. Haven't checked on
newer versions. Hence, wrap all occurences of poll() to pa_poll and
emulate that call with select() on OSX. This is totally embarassing.
On Wed, Sep 16, 2009 at 11:57:04PM +0200, Lennart Poettering wrote:
> On Wed, 16.09.09 15:15, Daniel Mack (daniel@caiaq.de) wrote:
>
> > + s = pa_xnew(pa_semaphore, 1);
> > + MPCreateSemaphore(UINT_MAX, value, &(s->sema));
> > + pa_assert(s->sema != 0);
>
> Hmm, I'd prefer if the ret val of MPCreateSemaphore() would be checked
> here.
>
> Also I find it a bit weird checking for s->sema, though not
> initializing it to 0 in the beginning. If the call actually failed,
> then the assert will check uninitialized memory. Also, comparing
> pointers with 0 sucks. That should be NULL.
>
> Given that this can not realisitically fail, only in OOM or OOM-like
> situations in which case we abort anyway it mght be enough just writing:
>
> pa_assert_se(MPCreateSemaphore(UINT_MAX, value, &s->sema) == 0);
>
> (Assuming that success is signalled by retval == 0 on MacOSX)
>
> > +void pa_semaphore_free(pa_semaphore *s) {
> > + pa_assert(s);
> > + MPDeleteSemaphore(s->sema);
>
> Same here.
>
> > + pa_xfree(s);
> > +}
> > +
> > +void pa_semaphore_post(pa_semaphore *s) {
> > + pa_assert(s);
> > + MPSignalSemaphore(s->sema);
>
> And here.
>
> > +}
> > +
> > +void pa_semaphore_wait(pa_semaphore *s) {
> > + pa_assert(s);
> > + /* should probably check return value (-ve is error), noErr is ok. */
> > + MPWaitOnSemaphore(s->sema, kDurationForever);
>
> And here.
Ok, done. See the patch below.
Daniel
>From 26df2fbae6d9215a3ae084876fb5f79e4d9cf4f0 Mon Sep 17 00:00:00 2001
From: Kim Lester <kim@dfusion.com.au>
Date: Wed, 16 Sep 2009 09:23:39 +0800
Subject: [PATCH] Mac OS X: add semaphore implementation
On Wed, Sep 16, 2009 at 11:48:58PM +0200, Lennart Poettering wrote:
> On Wed, 16.09.09 15:15, Daniel Mack (daniel@caiaq.de) wrote:
>
> > From: Kim Lester <kim@dfusion.com.au>
> >
> > OS X does not define clockid_t or clock_gettime() and friends.
> > Add a wrapper to fix this.
>
> Hmpf. I am not particularly happy with this. This adds a lot of
> unnecessary compat code. We don't actually need implementations of
> clock_getres(). All we need is some kind of check whether system
> timers are accurate or whether they are rounded up to scheduling
> slices. On Linux we do that check with clock_getres(), but all the
> information it returns is actually not intertesting at all. We just
> check if this is below some trheshold, that's all.
>
> clock_settime() we don't use at all! We shouldn't carry compat code
> for that.
>
> And clock_gettime we don't really need either. We need some kind of
> accurate system timers (preferably monotonic), and on Linux we use
> clock_gettime() for that. But we already have a fallback there for
> gettimeofday().
>
> Or in other words, the current APIs pa_rtclock_get(),
> pa_rtclock_hrtimer() is supposed to be the abstract API that has
> different backends on different systems. I'd very much prefer if any
> MacOS specific code would simply be plugged in there instead of
> creating various new abstraction interfaces!
Ok - what about the version below? I don't particularily like the
Daniel
>From 9f0a051953ec354ccdb8aa44a9845c408b26ae0b Mon Sep 17 00:00:00 2001
From: Kim Lester <kim@dfusion.com.au>
Date: Wed, 16 Sep 2009 14:40:01 +0800
Subject: [PATCH] Implement pa_rtclock_get() and pa_rtclock_hrtimer() for Darwin
OS X does not define clockid_t or clock_gettime() and friends.
Add wrappers to fix this. Based on a patch from Kim Lester
<kim@dfusion.com.au>.
