| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents the smoother attached to the stream clock from being
updated while the stream is corked, which in turn ensures that once
corking is completed, pa_stream_get_time() always returns the same value
until the stream is uncorked - i.e., the clock does not advance when the
client believes that it will not.
The actual call to pa_smoother_put() happens on things like stream
suspend/unsuspend, which trigger timing updates. This changes the
smoother coefficients, which means that a call to pa_smoother_get() for
the same value of 'x' can return different values before and after a
timing update.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Second version after Tanu's feedback
TODO:
- notify client that volume control is disabled
- change sink rate in passthrough mode if needed
- automatic detection of passthrough mode instead of hard
coded profile names
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
not know anything about
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.
|
|
|
|
|
|
|
| |
This allows easy overriding of a clients latency setting for debugging
purposes.
http://pulseaudio.org/ticket/753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Since the stream identifiers (channels) are monotonically growing integer, it
isn't a good idea to use them as index to a dynamic array, because the array
will grow all the time. This is not a problem with client connections that
don't create many streams, but, for example, long-running clients that use
libcanberra for playing event sounds, this means that the client connection
effectively leaks memory.
|
|
|
|
| |
state change so that in the STARTED/UNDERFLOW callbacks we accurate transport latency information
|
|
|
|
| |
don't want the timer to advance when we are supposedly already paused
|
|
|
|
| |
in corked state
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the mainloop to monotonic based time events.
Introduces 4 helper functions:
pa_{context,core}_rttime_{new,restart}(), that fill correctly a
timeval with the rtclock flag set if the mainloop supports it.
Both mainloop-test and mainloop-test-glib works with rt and timeval
based time events. PulseAudio and clients should be fully functional.
This patch has received several iterations, and this one as been
largely untested.
Signed-off-by: Marc-André Lureau <marca-andre.lureau@nokia.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixups' on resuming
The primary reason for this change is to allow time graphs that do not
go through the origin and hence smoothing starting from the origin is
not desired. This change will allow passing time data into the smoother
while paused and then abruptly use that data without smoothing using the
'quick fixup' flag when resuming.
Primary use case is allowing recording time graphs where the data
recorded originates from a time before the stream was created. The
resulting graft will be shifted and should not be smoothened to go
through the origin.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a bug in pa_stream_set_name. It uses the media.name
property instead of the application.name property when setting a
stream's name
>From aa1bda11d2084365cb0cec57f37d59f07ab80052 Mon Sep 17 00:00:00 2001
From: Omair Majid <omajid@redhat.com>
Date: Wed, 10 Sep 2008 17:02:28 -0400
Subject: [PATCH] Fix bug in pa_stream_set_name
Signed-off-by: Lennart Poettering <lennart@poettering.net>
|
|
|
|
|
|
|
|
|
|
| |
Hello
I came across a bug where the userdata parameter of the
stream_started_callback was always NULL in some cases. I couldn't seem
to make a ticket, so here's the one line patch:
Signed-off-by: Lennart Poettering <lennart@poettering.net>
|
| |
|
|
|
|
|
|
|
| |
PA_STREAM_EARLY_REQUESTS is a new flag that will modify buffering metric
selection behaviour a bit. This code is good for broken ALSA/OSS clients that
ignore 'readability' on the fds in question and schedule audio via usleep()
instead.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
allow prebuf=0
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
check_smoother_status()
|