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>
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.
Commit 65ef80b fixed building with xcb-util >= 0.3.8, but the reply is never
checked (possible SIGSEGV if the reply is NULL) nor freed (memory leak at each
call of the functions).
Also, remove include and dependencies on xcb-atom, as it was only meaningful
for xcb_atom_get() and STRING, and depend instead on xcb >= 1.6 for
XCB_ATOM_STRING.
Just picking up a crash report from Ubuntu, here's the result.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From 934c52c79bb6faed56a64d6e15f9b285f687afee Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Mon, 28 Mar 2011 14:30:44 +0200
Subject: [PATCH] module-jack-sink/source: protect against null return in jack_get_ports
According to jack_get_ports documentation, it seems like returning NULL
is valid, and that it should be freed using jack_free.
Reported-by: Grayson Peddie
BugLink: http://bugs.launchpad.net/bugs/733424
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Wrong order of libraries causes libtool to link primarily from lirc
library location and not from $(libdir) location in install
phase. This is a problem if you have an older version pulseaudio libs
installed under same directory as liblirc and you are building a
newer version with some other directory prefix.
Build appeared to fails when a new function is added to
libpulsecommon. This is because build uses libpulsecommon that is
installed into system instead of the one that is being built. Explicit
linking to libpulsecommon fixes the problem.
This is required to make sure that the source output between
module-echo-cancel and ALSA can't get plugged to the virtual source or
monitor of the virtual sink that we expose. This could be triggered by
changing the profile of the underlying ALSA device.
This forces us to get native-endian samples in the adrian module so that
we can rely on the existing endianness conversion mechanisms instead of
doing it in the module.
The adrian module was using home-brewed endianness conversion instead of
the appropriate mactos, and speex assumed a little-endian host. This
fixes both of these.
Since all algorithms will need to specify a block size (the amount of
data to be processed together), we make this a common parameter and have
the implementation set it at initialisation time.
This adds Andre Adrian's AEC implementation from his intercom project
(http://andreadrian.de/intercom/) as an alternative to the speex echo
cancellation routines. Since the implementation was in C++ and not in
the form of a library, I have converted the code to C and made a local
copy of the implementation.
The implementation actually works on floating point data, so we can
tweak it to work with both integer and floating point samples (currently
we just use S16LE).
Since the source and sink specification will need to be determined by
the AEC algorithm (can it handle multi-channel audio, does it work with
a fixed sample rate, etc.), we negotiate these using inout parameters at
initialisation time.
There is opportunity to make the sink-handling more elegant. Since the
sink data isn't used for playback (just processing), we could pass
through the data as-is and resample to the required spec before using in
the cancellation algorithm. This isn't too important immediately, but
would be nice to have.
The speex echo canceler prefers a power of 2 for the frame size. Round down the
ideal frame_size to the nearest power of two. This makes sure we don't create
more than the requested frame_size_ms latency while still providing a power of 2
to the speex echo canceller.
Try to keep the drift between source and sink within 4ms now that we have more
accurate timings.
Don't force a resync on latency changes but let the drift code handle it.
Tag the source and sink with the phone media roles so that they automatially
connect to phone streams such as Empathy when using the intended-rols module.
Make a new echo-cancel module that exposes a new sink and source. All data sent
to the sink is matched against the data captured from the source and
echo-canceled using the speex echo canceler.
Vala uses the name of the *.vapi file to determine the libraries to link
against. Since the pa_glib_mainloop_*() functions are in a separate
library (libpulse-mainloop-glib.so) the corresponding objects in the
Vala bindings have to be in a separate *.vapi file.
If you are compiling an app without the GLib integration you could use:
$ valac --pkg=libpulse test.vala
but if you do use GLib you can use:
$ valac --pkg=libpulse-mainloop-glib test.vala
(libpulse is a dep of the libpulse-mainloop-glib so no need to specify
it explicitly)
1. PA uses Vala's "Posix" package (see line 23 of libpulse.vapi).
These dependencies have to be declared in the *.deps file.
2. Fix obvious copy/paste error.
3. Rename the parameter to match the C function. This simplifies
understanding what this parameter means.
4. According to the official documentation the "dev" parameter
for playback/capture streams on connection may be NULL and this
is the default. Change the method definition accordingly.
This value is not a technical upper limit, it's just a 'sensible'
value that is not crazy high, but also allows software amplification
above 0dB (aka 100%) for very quiet audio sources.
We recommend that a comprehensive volume control UI should allow
users to set volumes up to this limit, although of course should
deal gracefully if the user has set the volume even higher than this
without resulting in a feedback loop that effectively limits the
upper volume.
The value chosen is +11dB. This was selected somewhat subjectively
and is very similar to the current 150% that gnome-volume-control
uses (which is ~+10.57dB).
On the plus side, we now recommend that everyone allows
'Volumes up to 11' which is pretty awesome.
http://en.wikipedia.org/wiki/Up_to_elevenhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006945.htmlhttps://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-April/006950.html
