| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|
|
|
|
|
|
| |
The echo suppress attenuation value was being incorrectly modified.
Fixed and added 2 arguments to change the attenuation of the residual
echo filter. Default values of the speex preprocessor will be used when
omitted.
|
|
|
|
| |
This is how it is expected to be run.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the selective enabling of speex' preprocessing algorithms
before running the echo-canceller -- for now this includes automatic
gain control, noise suppression and echo suppression. It's all off by
default for now, though at some point in the near future we might want
to enable at least denoising by default.
The denoising works pretty well, though we might want to add a way to
tweak the noise-suppression knob that libspeex provides.
The AGC option is just a stop-gap -- we need a real AGC mechanism that
tweaks the source volume rather than doing this in software.
The speex documentation mentions VAD and dereverb, but it appears that
these are not complete yet.
We don't do all this in a separate module from module-echo-cancel to
avoid the overhead of adding another virtual source. It makes more sense
to make a separate virtual source module that can be used for cases
where preprocessing is useful but AEC is not (for e.g. noise suppression
for fan noise in a recording application).
Another reason to keep this integrated with the AEC module is that the
echo suppression bits use the speex echo canceller state. This does leak
some information about the AEC implementation into module-echo-cancel,
but this is unavoidable.
|
|
|
|
|
| |
Channel map handling in the extended API was broken. Thanks for Milos_SD
for pointing this out on IRC.
|
|
|
|
| |
This was making it impossible to run in debug mode with save_aec=1
|
|
|
|
| |
The padding was to be 16 bytes, not 16 elements.
|
|
|
|
|
|
| |
Linking libpulse with gold or when using ld --no-add-needed fails
as libpulse uses dbus methods directly but isn't explicitly linked to it.
So link to it when needed :)
|
|
|
|
|
|
|
|
|
|
|
| |
support)
The proplist used may never be freed if an error condition was found with
CHECK_VALIDITY macro and the formats idxset was never freed regardless
of error state.
This change fixes adds a new maco CHECK_VALIDITY_GOTO() which allows
for cleanup to be done before returning.
|
| |
|
| |
|
|
|
|
| |
Thanks to Tanu Kaskinen for pointing out the missing return.
|
|
|
|
|
|
|
|
| |
In a setup with one or more filter sinks or sources there is always at
least one stream existing. In such a situation normal mempool
vacuuming never happens. This patch causes suspend-on-idle module to
vacuum memory when ever it notices that all sinks and sources are
suspended. The behavior can be enabled with a module parameter.
|