We have no strtof_l calls in the code, so it doesn't make sense to
check that function's availability. We have one strtod_l call, so
let's check that instead.
I don't know if this change makes any practical difference. I just
wondered why we had HAVE_STRTOF_L ifdefs in core-util.c for code that
didn't use strtof_l.
Previously module-alsa-card assigned to pa_alsa_jack.plugged_in
directly, and then did the port availability updating manually. The
idea of pa_alsa_jack_set_plugged_in() is to move the availability
updating to the mixer infrastructure, where it really belongs.
Similarly, pa_alsa_jack.has_control was previously modified directly
from several places. The has_control field affects the port
availability, and pa_alsa_jack_set_has_control() takes care of
updating the availability.
For now, pa_alsa_jack_set_plugged_in() and
pa_alsa_jack_set_has_control() only update the port availability
when using UCM. My plan is to adapt the traditional mixer code later.
We have crashes related to modules loaded after unload. This added
warning can provide some information about what that module is,
which in turn can help us solve the crashes, hopefully.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90108
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Modern versions of MinGW and Visual Studio provide socket errno
defines that make no sense (no API sets them). Make sure we
continue to use the old WSAE ones that are actually returned by
Windows' socket API.
Signed-off-by: Pierre Ossman <ossman@cendio.se>
pulsecore/sink.c: In function 'pa_sink_put':
pulsecore/sink.c:648:53: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
pa_assert(!(s->flags & PA_SINK_DYNAMIC_LATENCY) == (s->thread_info.fixed_latency != 0));
^
pulsecore/source.c: In function 'pa_source_put':
pulsecore/source.c:599:55: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
pa_assert(!(s->flags & PA_SOURCE_DYNAMIC_LATENCY) == (s->thread_info.fixed_latency != 0));
^
rewrite expression to suppress warning:
!(x & MASK) == (y != 0)
<->
!(x & MASK) == !(y == 0)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
pulsecore/filter/biquad.c: In function 'biquad_lowpass':
pulsecore/filter/biquad.c:52:10: warning: declaration of 'gamma' shadows a global declaration [-Wshadow]
pulsecore/filter/biquad.c: In function 'biquad_highpass':
pulsecore/filter/biquad.c:86:10: warning: declaration of 'gamma' shadows a global declaration [-Wshadow]
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This fixes buffer attr calculation so that we set the source latency to
the requested latency. This makes sense because the intermediate
delay_memblockq is just a mechanism to send data to the client. It
should not actually add to the total latency over what the source
already provides.
With this, the meaning of fragsize and maxlength become more
meaningful/accurate with regards to ADJUST_LATENCY mode -- fragsize
becomes the latency the source is configured for (which is then
approximately the total latency until the buffer reaches the client).
Maxlength, as before, continues to be the maximum amount of data we
might hold for the client before overrunning.
Fix the following warnings.
CC pulsecore/filter/libpulsecore_6.0_la-lfe-filter.lo
pulsecore/filter/lfe-filter.c: In function 'pa_lfe_filter_rewind':
pulsecore/filter/lfe-filter.c:179:9: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat=]
pa_log_debug("Rewinding LFE filter %lu samples to position %lli. No saved state found", samples, (long long) f->index);
^
pulsecore/filter/lfe-filter.c:183:5: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat=]
pa_log_debug("Rewinding LFE filter %lu samples to position %lli. Found saved state at position %lli",
^
CC pulsecore/filter/libpulsecore_6.0_la-biquad.lo CC pulsecore/filter/libpulsecore_6.0_la-lfe-filter.lo
pulsecore/filter/lfe-filter.c: In function 'pa_lfe_filter_rewind':
pulsecore/filter/lfe-filter.c:179:9: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat=]
pa_log_debug("Rewinding LFE filter %lu samples to position %lli. No saved state found", samples, (long long) f->index);
^
pulsecore/filter/lfe-filter.c:183:5: warning: format '%lu' expects argument of type 'long unsigned int', but argument 6 has type 'size_t' [-Wformat=]
pa_log_debug("Rewinding LFE filter %lu samples to position %lli. Found saved state at position %lli",
^
Previously pa_parse_volume() clamped the value to fit in the valid
range, but I think it's better to reject values outside the valid
range.
This also changes the percentage parsing to allow non-integer values.
We currently use pa_yes_no to write module arguments, so they can not be
localised. Instead add a new pa_yes_no_localised function and use it in pactl
(and thus, revert all other places to use the non-localised version).
BugLink: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1445358
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We don't and probably never will have any pa_atod() callers that would
require "NaN" to be accepted, so let's filter those out in pa_atod(),
instead of requiring the callers to handle not-a-numbers appropriately
(which they generally forget to do).
This small helper will simplify code in many modules.
The hooks added through pa_module_hook_connect will be freed just
before pa__done is called (so trying to add hooks during pa__done
will result in assertion failure).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
When a sink or source is freed, there may be pending volume changes that
didn't get applied before the IO thread got torn down. Those pending
changes need to be freed.
The memory leak was reported here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/23162/focus=23169
Reported-by: Alexander E. Patrakov <patrakov@gmail.com>
When crossover_freq is set to 0, this restores the old behaviour
of letting the LFE channel be the average of the source channels,
without additional processing. This can be useful e g in case the
user already has a hardware crossover.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The resampler framework just forwards the request to the lfe filter.
There are no resampler impl that can rewind yet, so just reset the
resampler impl instead of properly rewinding yet.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Store current filter state at every normal block process.
When a rewind happens, rewind back to the nearest saved state,
then calculate forward to the actual sample position.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
To avoid the macro trap: I call pa_memblock_new_malloced with
"pa_xmemdup" as data parameter, and that would expand to *two*
calls to pa_xmemdup in case that remains a macro, which is clearly
not intended.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Add a user defined parameter lfe-crossover-freq for the lfe-filter,
to pass this parameter to the lfe-filter, we need to change the
pa_resampler_new() API as well.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
- Remove imported dead code
- Fix compiler warnings
- Fix non-GCC compiler compilation (use more portable macros)
- Change lr4 struct to include a biquad struct
Thanks to Alexander Patrakov for suggesting many of these changes.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
When enable-lfe-remixing is set, an LFE channel is present in the
resampler's destination channel map but not in the source channel map,
we insert a low-pass filter instead of just averaging the channels.
Other channels will get a high-pass filter.
In this patch, the crossover frequency is hardcoded to 120Hz (to be fixed
in later patches).
Note that in current state the LFE filter is
- not very optimised
- not rewind friendly (rewinding can cause audible artifacts)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The chrome OS audio server has some already existing code, which
has been made available under a BSD-style license, which should be
safe to import by us.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
While investigating bug 89672 it was found that pa_thread_mq_done
was called recursively. Regardless of whether the recursion should
be stopped by other means, it seems to make sense to make
pa_thread_mq_done more robust so that it can be called twice
(and even recursively) without harm.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89672
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
pa_atou(), pa_atol() and pa_atod() are stricter than the libc
counterparts (the PA functions reject strings that have trailing extra
stuff in them). I have been under the impression that the PA functions
only accept "obviously valid numbers", that is, I have assumed that
these would be rejected: " 42" (leading whitespace), "" (empty
string) and "-18446744073709551615" in case of pa_atou().
I noticed that empty strings are accepted, however, and on closer
inspection I found that leading whitespace is accepted too, and even
that pa_atou() thinks that "-18446744073709551615" is the same thing
as "1"! This patch makes the parsing functions more strict, so that
they indeed only accept "obviously valid numbers". I decided to also
disallow leading plus signs, just because I don't like them.
In src/pulsecore/core-util.c:set_nice() we currently use a temporary
dbus-connection to set the nice-level via rtkit. However, we never
close that connection. This is fine, as the connection is shared and
dbus-core will manage it. But no other part of pulseaudio (except
set_scheduler()) uses the libdbus1 managed connections. Therefore,
we effectively end up with an unused dbus-connection that is not
integrated into any main-loop. dbus-daemon will send bus-notifications
to the connection (as libdbus1 installs matches for those by default
(it has to!)) until the outgoing queue is full. Thus, we waste several
KBs (or MBs? I didn't look it up) of memory for a message queue that
is never dispatched.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In case SHM is full or disabled, audio data is sent through the
io/srbchannel. When this channel in turn gets full, memblocks
could previously be split up. This could lead to crashes in case
the split was on non-frame boundaries (in combination with full
memblock queues).
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=88452
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
a separate free-list is used to recycle memory of fixed-sized packets
with up to MAX_APPENDED_SIZE of data
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
if length exceeds maximum appended size, create a packet of
type dynamic instead of type appended
this is a preparation to use a separate free-list for packets
document semantics of pa_packet_new_*() functions
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
v2: (thanks David Henningson)
* fix double assignment of data in pa_tagstruct_new_fixed(), two statements on one line
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
add 128 bytes of storage in each tagstruct that will initially
be used; if this storage is exceeded the type changes to _DYNAMIC
v3: (thanks David Henningson)
* add comments explaining how memory is handled by different tagstruct types
v2: (thanks Alexander Patrakov)
* replace constant 100 with GROW_TAG_SIZE (the increment in with a dynamic tagstruct grows when extend()ed)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
pa_tagstruct_free_data() is used in only one place
to pass data from a tagstruct to a packet
this patch is a temporary solution which introduces an extra
malloc(); will be resolved shortly...
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
... in order to prepare for a new type _APPENDED
remove the assert() for dynamic in pa_tagstruct_data() as
the function makes sense for all tagstruct types (and the returned pointer
is const)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
pa_tagstruct_new() is called either with no data, i.e. (NULL, 0)
to create a dynamic tagstruct or with a pointer to fixed data
introduce a new function pa_tagstruct_new_fixed() for the latter case
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
While adding functions for writing and reading pa_bvolume structs, I
found myself wondering if I could make it simpler to write and read
the basic types that a pa_bvolume consists of, without having to worry
about network byte ordering, remembering to call extend() and getting
the length and read index adjustments just right. This is what I came
up with.
There is a functional change too: previously the
pa_tagstruct_get_foo() functions didn't modify the read index in case
of errors, but now, due to read_tag() modifying the read index at an
early stage, the read index gets modified also in case of errors. I
have checked the call sites, and I believe there's no code that would
rely on the "no read index modification on error" property of the old
functions. If reading anything from a tagstruct fails, the whole
tagstruct is considered invalid (typically resulting in a protocol
error and client connection teardown).
Added ID and names for the resampler presets and also updated the working sample rate deduction to take the new resampler into account. The initial libsoxr backend version does not variable rate resampling, so it is disabled in this case.
