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
If the user specifically removes the device element from the stream
restore rule, we have to clear the save_sink/save_source flag of the
stream. This means that other stream routing systems
(e.g. module-device-manager) can take over routing for this
stream. In order to facilitate the reapplication of other routing
rules, we fire a stream change event. Arguably the stream itself
has not changed, but the rules governing its routing have, so
I feel this is justified.
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
Compiler optimisations have been seen to initialise
m->n_waiting_for_accept to a positive non-zero value, so the while() in
pa_threaded_mainloop_signal() never proceeds. Fix this by properly
initializing m->n_waiting_for_accept in pa_threaded_mainloop_new().
Patch from Iain Bucław.
https://bugs.launchpad.net/bugs/502992
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>
Avahi and dbus is too heavy for OSX just for the sake of publishing our
services via mDNS/Zeroconf. Apple has its own Zeroconf implementation
called Bonjour, and this patch adds a module that implements service
announcement with that API.
All data gathering is copied from module-zeroconf-publish.c, but
unfortunately the code there is too specifically made for avahi, so I
couldn't factor it out to reuse it.
This patch adds support for CoreAudio driven devices under Mac OS X. It
is typically instanciated by the CoreAudio device detection module and
handles all available streams on a specific device.
Sinks are created according to the reported stream configuration.
Float32 is used as default audio sample format at it is the only format
CoreAudio speaks natively.
Hardware volume control is not implemented yet.
This adds a new module for CoreAudio device detection. It registers a
callback to detect hotplugged devices and creates/destroys modules named
'module-coreaudio-device'. Devices are identified via a system-wide
unique AudioDeviceID.
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.
This patch serves two purposes:
1) Allows something other than the de-facto standard udev rules dir or
/lib/udev/rules.d to be used (the udev build system allows you to
customise this)
2) Allows a prefixed, non-root install (right now, the /lib/... path
is hard-coded into the build system
'n_waiting' and 'n_waiting_for_accept' may be accessed from mulitple
threads, and thus need to be marked as volatile to suppres certain
compiler optimisations. All uses are protected by a mutex, so we don't
need to worry about cache issues (added documentation for this as well).
This addresses bug #738.
