| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has the advantage of allowing versioned updates in the future,
thus allowing us to be more user friendly going forward (as opposed
to just ignoring entries from old versions).
The primary motivation for this, however, is to allow variable length
storage in each entry which will be needed for upcoming work.
At present this commit will ignore any legacy entries but support
for reading and subsequently converting legacy entries will be added
shortly.
|
|
|
|
|
|
|
|
|
|
| |
After the rework to the add pa_sink_input_new_data_set_sink() (and
the source equiv) calling with a NULL sink object will hit an assert.
This caused crashes with the esd protocol and there was the potential
(albeit unlikely) for a crash when creating a sink input without any
sinks available (module-always-sink mitigates this risk but it's still
a potential crasher).
|
| |
|
|
|
|
| |
Makes diff'ing with sink-input.c easier
|
|
|
|
|
|
| |
This was added to ensure symmetry between playback and recording streams
code, but in reality this makes little sense practically speaking and thus
it is removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with capture.
The previous logic in ade0a6f88464d8aecf83982d400ccfc402341920
does not work with for input volumes.
This was discussed on the mailing list:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html
This approach can introduce a problem when setting the volumes
for sources. What follows is Tanu Kaskinen's analysis:
[quote]
I'll quote the log:
D: protocol-native.c: Client pavucontrol changes volume of source alsa_input.pci-0000_00_1b.0.analog-stereo.
D: alsa-source.c: Requested volume: 0: 45% 1: 45%
D: alsa-source.c: in dB: 0: -20.71 dB 1: -20.71 dB
D: alsa-source.c: Got hardware volume: 0: 45% 1: 45%
D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB
D: alsa-source.c: Calculated software volume: 0: 101% 1: 101% (accurate-enough=no)
D: alsa-source.c: in dB: 0: 0.29 dB 1: 0.29 dB
D: source.c: Volume going up to 29273 at 270475970821
D: source.c: Volume change to 29273 at 270475970821 was written 34 usec late
D: alsa-source.c: Written HW volume did not match with the request: 0: 45% 1: 45% (request) != 0: 42% 1: 42%
D: alsa-source.c: in dB: 0: -21.00 dB 1: -21.00 dB (request) != 0: -22.50 dB 1: -22.50 dB
Looking at the last line, the requested volume seems to hit exactly the
right step (-21.00dB), but for some reason Alsa decides to choose
something else. I'm pretty sure that this happens because of rounding
errors. In the first phase we ask Alsa what dB value we should set, and
it returns -21.00 dB. The value is given as a long int, but we convert
that to pa_cvolume. Then when we set the volume, we convert the
pa_cvolume value back to a long integer. At this point I believe it gets
converted to -2101. This is not visible in the debug message for some
reason - the rounding algorithm must be different from what was used
with the pa_cvolume -> long conversion.
[/quote]
The commit after this contains a patch that addresses this issue.
|
| |
|
| |
|
|
|
|
|
|
| |
This gets the negotiated format of source outputs in
pa_context_get_source_output*(). Also prints the format and volume
in 'pactl list'.
|
|
|
|
|
|
|
| |
This piggy backs onto the previous changes for protocol 22 and
thus does not bump the version. This and the previous commits should be
seen as mostly atomic. Apologies for any bisecting issues this causes
(although I would expect these to be minimal)
|
|
|
|
|
| |
This gets the list of supported formats for a source in
pa_context_get_source_info*(). Also prints these in 'pactl list'.
|
|
|
|
|
| |
This helps to keep the API more symmetrical and also potentially
allows support for passthrough monitor sources at some point in the future.
|
|
|
|
|
| |
These flags will be required in upcoming work to integrate format and volume
support for source outputs.
|
| |
|
|
|
|
|
| |
Mostly typo fixes but also a change to make a function relating
to sink inputs use more generic variable names.
|
|
|
|
|
|
| |
These were supposed to be removed already in 13849f153, but
at that time I missed the ifdefs in
module-bluetooth-discover.c.
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
It has no new functionality over the existing macro that is relevant for
us, but it is good to have use a macro with a clearly defined upstream.
|
| |
| |
| |
| |
| | |
It has no new functionality over the existing macro that is relevant for
us, but it is good to have use a macro with a clearly defined upstream.
|
| |
| |
| |
| | |
The file is so small, that it is clearer just to do it in the main file.
|
| |
| |
| |
| | |
For more logical grouping of functionality.
|
| |
| |
| |
| | |
Mostly whitespace and other trivial stuff.
|
| |
| |
| |
| | |
To ensure that all the changes to CFLAGS are also stored into PA_CFLAGS.
|
| | |
|
| |
| |
| |
| | |
Use os_is_* shell variables instead of pulse_target_os.
|
| |
| |
| |
| | |
These HAVE_* variables are only used as AM_CONDITIONAL, so AC_SUBST is not needed.
|
| |
| |
| |
| |
| |
| |
| |
| | |
The "rm" basm constraint doesn't work with my version of gcc (4.5.2),
not even in a simple example. Since we usually only have 5 registers
available on i386, force it to be memory on that architecture.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
|
| |
| |
| |
| |
| |
| | |
Passing a NULL-terminated array of pa_format_info pointers is a bit
unwieldy for clients. Instead of this, let's pass in an array of
pointers and the number of elements in the array.
|
| | |
|
|/
|
|
|
| |
This clarifies some ownership issues with the formats idxset on the
server side so we don't end up leaking formats on errors.
|
|
|
|
| |
And do not use sched_get_priority on mingw with win32 pthreads installed
|
|
|
|
|
|
|
|
| |
We were calculating new latency based on the latency set on the old
sink/source, rather than the actual latency requested by the client.
Over a series of moves, this will lead the latency being ~halved each
time, resulting in an eventual rewind flood from a latency that cannot
be handled.
|
|
|
|
|
| |
The speex_preprocess_ctl() function takes a spx_int32_t, but we've been
passing a pa_bool_t, which could potentially crash.
|
|
|
|
|
|
| |
We were using the block size in bytes instead of samples, which meant
preprocessing was broken. This fix makes a large-ish difference in the
quality of echo-cancellation with speex.
|
|
|
|
|
| |
This makes windows.h include less headers.
Otherwise boolean is typedef'ed and that clashes with libjson.
|
| |
|
|
|
|
|
| |
The test wasn't updated after we changed the pa_format_info proplist
format.
|
|
|
|
| |
By using module indexes rather than module pointers we avoid this posibility.
|
| |
|
| |
|
|
|
|
|
| |
This makes process_render_null consistent with render_memblock and
avoids introducing slight inaccuracies in early latency estimates.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The smoother is paused on initialization and resumed when the sink
state is set to running. Otherwise, early latency estimates are
too low since there is some delay between module initialization and
entering the running state.
After the smoother is initially resumed, it is paused when the sink
state is not running. The previous behavior was to pause only when
the sink enters suspended state, however, this would lead to large
errors in latency estimates after the sink has been idle for some
time.
|
|
|
|
|
| |
The smoother was being initialized with offset zero, which caused
the sink latency to be unconditionally reported as zero.
|
| |
|
|
|
|
|
| |
This option won't make it to the actual libtool command which does the
linking when not prefixed with -Wl,
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a variable to track whether the actual volume is set or not.
Suppose this:
min volume: -126 max volume: 0
then when user wants to set some constant volume to -10, it would fail.
While the alsa values are typically positive, some values are "funky"
and have negative values. It is desirable to fix this at the alsa
level so that the numbers are positive, but it's not technically
invalid, and thus we have to support it.
Discussed here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/9832
and
http://thread.gmane.org/gmane.linux.alsa.devel/85459
|
|
|
|
|
|
| |
If module initialisation fails, the speex done() function might try to
free a value that's not been allocated yet. Adding protection for this
condition.
|