While reading from the SCO socket, there is no guarantee regarding the
resulting packet size. In some rare cases, it might not even match the
alignment expected in pa_source_post(), resulting in an assertion
failure inside pa_volume_memchunk():
I: [alsa-sink] module-loopback.c: Could not peek into queue
I: [alsa-sink] module-loopback.c: Could not peek into queue
I: [alsa-sink] module-loopback.c: Could not peek into queue
E: [bluetooth] sample-util.c: Assertion 'pa_frame_aligned(c->length, spec)' failed at pulsecore/sample-util.c:725, function pa_volume_memchunk(). Aborting.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffda98f700 (LWP 8058)]
0x00007ffff6177935 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install alsa-lib-1.0.26-1.fc17.x86_64 dbus-libs-1.4.10-7.fc17.x86_64 flac-1.2.1-9.fc17.x86_64 glibc-2.15-58.fc17.x86_64 gsm-1.0.13-6.fc17.x86_64 json-c-0.10-2.fc17.x86_64 libICE-1.0.8-1.fc17.x86_64 libSM-1.2.1-1.fc17.x86_64 libX11-1.5.0-2.fc17.x86_64 libXau-1.0.6-3.fc17.x86_64 libXext-1.3.1-1.fc17.x86_64 libXi-1.6.1-1.fc17.x86_64 libXtst-1.2.0-3.fc17.x86_64 libogg-1.3.0-1.fc17.x86_64 libsndfile-1.0.25-2.fc17.x86_64 libtool-ltdl-2.4.2-3.1.fc17.x86_64 libudev-182-3.fc17.x86_64 libuuid-2.21.2-3.fc17.x86_64 libvorbis-1.3.3-1.fc17.x86_64 libxcb-1.9-1.fc17.x86_64 speex-1.2-0.14.rc1.fc17.x86_64
Make sure the reply to SetConfiguration() is sent before the internal
hook is fired. This is important because the hook could have side
effects including D-Bus interfactions (i.e. transport Acquire() being
called during module startup).
The assertion in hsp_process_render() assumes that, if a memory block is
already set by the time the function is reached, its size matches
write_block_size.
This can however fail if a transport has been released and acquired
back, in the unlikely case where the MTU has changed in the meantime,
assuming the memory block wasn't released.
The u->channels <= 0 check failed if the channels argument was not
given at all, making the whole module loading fail. I don't think the
check is necessary at all - negative values are not possible, and if
someone gives 0 as the argument, it's probably ok if we act as if
there was no channels argument at all.
Calling change_cb() whenever anything happens in the ownership of the
bus name caused trouble in PulseAudio in this scenario:
1. PulseAudio is using a device and owns the corresponding service
name.
2. Another application requests device release.
3. PulseAudio releases the device.
4. Change in the bus name ownership: PulseAudio gives up the
ownership, and nobody owns the name.
5. reserve-monitor notices that, and notifies PulseAudio.
6. Since reserve-monitor reports the device as "not busy", PulseAudio
decides to reserve the bus name immediately back to itself and
opens the device again.
The other application will forcibly take the bus name to itself, as
it should according to the protocol, but the other application may
have trouble opening the device if it tries to do that before
PulseAudio has had time to react to the NameLost signal.
This can be solved by not calling change_cb() if there are no changes
in the device busy status. In this scenario the device is considered
"not busy" while PulseAudio is owning the bus name, so PulseAudio gets
no notification when the ownership changes from PulseAudio to nobody.
As pointed out by Tanu, checking both error conditions is redundant and
raises the question whether it's possible that one of the conditions is
true while the other is false.
Therefore, simplify the condition by just checking one part of the
disjunction.
The function was used to check whether the basic properties of the
Bluetooth device have been received. This can be simplified by just
checking d->device_info_valid, since the state of the audio interface
is only relevant inside pa_bluetooth_device_any_audio_connected(), which
is used to trigger the discovery callback.
While checking device_info_valid, special care must be taken with all
three possible values: when set to -1, it means some error was triggered
while getting the device properties. Therefore, these devices can also
be ignored outside bluetooth-util.
Besides that, the patch slightly modifies the behavior of the internal
API affecting pa_bluetooth_discovery_get_by_address() and
pa_bluetooth_discovery_get_by_path(), since they will return the device
no matter the state of the audio interface. This however makes sense and
should have no influence in the current codebase given that the modules
make use of devices only after the discovery hook has been triggered.
The function is used to make sure some basic information has already
been gathered before the device is being used. At this point profile
states can be ignored, since their initial value will be
PA_BT_AUDIO_STATE_INVALID and thus effectively similar to
PA_BT_AUDIO_STATE_DISCONNECTED due to audio_state_to_transport_state().
The change should make no difference given that the behavior of
pa_bluetooth_device_any_audio_connected() doesn't change: by the time
TRUE is returned, a transport needs to exist. This means a profile
will exist in CONNECTING or CONNECTED state and thus the old
implementation of device_audio_is_ready() would also have returned TRUE.
Trivially fix some style issues affecting line wrap (128 chars max with
the exception of multi-line comments, which are limited to 80),
indentation and unnecessary parentheses.
Allow configuration of number of channels when using module-jackdbus-detect
to load jack-sink and jack-source. This is useful when the default channel
count doesn't match the logical channel count desired, e.g. with multi-
channel audio interfaces.
Signed-off-by: Peter Nelson <peter@fuzzle.org>
pa_bluetooth_discovery_sync() waited until all pending method calls
had completed. I don't understand what the benefit of that could be,
so I removed the function. We should avoid blocking as much as
possible, and the code that used pa_bluetooth_discovery_sync() didn't
look like it really needed to wait for anything.
The new null implementation works with arbitrary sample specs for source
and sink. In particular, it handles a different number of channels for
source and sink.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
In order to support different blocksizes for source and sink (e.g, for
4-to-1 beamforming/echo canceling which involves 4 record channels and 1
playback channel) the AEC API is altered:
The blocksize for source and sink may differ (due to different sample
specs) but the number of frames that are processed in one invokation of
the AEC implementation's run() function is the same for the playback and
the record stream. Consequently, the AEC implementation's init()
function initalizes 'nframes' instead of 'blocksize' and the source's
and sink's blocksizes are derived from 'nframes'. The old API also
caused code duplication in each AEC implementation's init function for
the compution of the blocksize, which is eliminated by the new API.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
In case that source and sink use different sample specs (e.g., different
number of channels) the computation of the latency difference fails.
To fix this, we obtain the corresponding latencies in terms of time using
the respective sample specs instead of buffer sizes.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
In main() of echo-cancel-test it is wrongly assumed that the EC
implementation's init() function properly initializes sink_ss. In
contrast, pa__init() sets sink_ss by default to
sink_master->sample_spec. Fix this by setting sink_ss to default
parameters and let EC implementation's init() override these settings.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
Argument argv[5] is accessed when argc>4, which leads to an invalid
access for argc==5. Fix this.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
In addition to moving the freeing a bit later, unnecessary checks for
t->device are removed. t->device is initialized to a non-NULL value
when the transport is created, and it's never changed.
pa__done() calls stop_thread(), and stop_thread() already
frees the smoother. The duplicate freeing is not strictly
a bug, but static analyzers (in this case Coverity) may
complain about double-freeing, because when pa__done()
"frees" the smoother (which doesn't actually ever happen),
the pointer is not nulled. pa__done() then calls
bt_transport_release(), which will also free the smoother
if it's not NULL.
The analyzer complaint could be silenced also by nulling
the pointer in pa__done(), but since this is clearly
redundant code, I chose to remove it.
Make the internal function bt_transport_acquire() consistent with the
API in bluetooth-util by replacing the old 'start' parameter with
exactly the opposite: 'optional'.
Therefore, all calls to the function need to negate the second
parameter.
Note also that the name is more accurate now that setup_stream() is not
called inside bt_transport_acquire().
Do not call setup_stream() automatically inside bt_transport_acquire().
Instead, the caller is responsible to use both functions as necessary.
As a first trivial step, setup_stream() is now called manually after
all calls to bt_transport_acquire(u, TRUE), with the exception of
setup_transport() where the thread is still about to start and thus
setup_stream() will be called later on from thread_func().
All D-Bus infrastructure is now unused after bluetooth-util has covered
the pieces that were pending. Therefore, all D-Bus related code in
module-bluetooth-device can be safely removed.
The transport state also reflects the state of the audio interface. The
state redundancy can thus be minimized by always using the first one,
and avoiding the use of profile-specific states with the exception of
finding out the initial state of a transport.
The state of this interface is needed for one single reason: we need to
wait until all profiles have been connected (or more precisely, until
are connection attempts are finished). This can be made more explicit in
the code by just checking the CONNECTING state (and not loading
module-bluetooth-device during that state), but otherwise treating all
transport types equally.
Ideally, audio_state should be completely removed but it's left there to
avoid an issue with module-card-restore, as documented in the source
code's comments.
Transports can be acquired with different access rights, but in practice
"rw" was always used inside module-bluetooth-device. In addition, this
feature is removed in BlueZ 5.0 and therefore it is convenient to
abstract all this inside bluetooth-util.
Use transport state to calculate the corresponding port availability,
and while doing so use bluetooth-util to receive profile state updates
instead of directly parsing D-Bus PropertyChanged signals.
Move the function to the utility library where the enum is defined. At
same time avoid using the default clause in order to make sure the
compiler will complain if the enum type gets extended.
Similarly to the microphone gain, the speaker gain can be abstracted
inside the transport object, even though the actual D-Bus interface in
BlueZ differs.
The microphone gain represents the volume of the incoming audio stream
from the headset. This can be nicely abstracted inside the transport
object in bluetooth-util, so the modules don't have to take care about
the D-Bus details.
memcpy() of the null implementation's run() copied data for only one
channel. Set the number of channels to 1 in init() in order to guarantee
this.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
apply_diff_time() fails when dropping bytes from the playback stream
and the sample spec of sink and source differ as source's sample spec is
used. Fix this by using sink's sample spec.
Signed-off-by: Stefan Huber <s.huber@bct-electronic.com>
Acked-by: Peter Meerwald <p.meerwald@bct-electronic.com>
This module works pretty similar to the module-role-cork.
It should be used as an alternative to that module. Basically
it decreases the volume of the streams specified in ducking_roles
in the presence of at least one stream specified in trigger_roles.
Also, it's possible to choice the volume that will be used in the
ducking streams and if it should operates in all devices or not.
For basic reference: http://en.wikipedia.org/wiki/Ducking
