A transport should be considered connected only after the connection
procedure is complete, as expressed in audio_state_to_transport_state().
module-bluetooth-device should be loaded only after at least one
transport is not only created (during configuration), but also
connected.
This fixes the issue of premature acquire attempts sometimes experienced
when a headset is connected (issue not present in v3.0 though).
The previous patch removed module-gconf's dependency on the userdata
pointer of the free callback, and that was the only place where the
userdata pointer of pa_free2_cb_t was used, so now there's no need for
pa_free2_cb_t in pa_hashmap_free(). Using pa_free_cb_t instead allows
removing a significant amount of repetitive code.
idea is to allow optimized code path (similar to volume code)
and rework/specialize mixing cases to enable runtime performance improvements
no functionality changes in this patch
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Initialize the variable to zero by using pa_xnew0() instead of
pa_xnew(). This also allows us to remove a bunch of other zero
initialization statements.
Reported-by: Peter Meerwald <p.meerwald@bct-electronic.com>
bug probably caused by alignment requirement; sizeof(a->w) is a pointer, sizeof(a->w_arr) is an array
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
computes EC block size in frames (rounded down to nearest power-of-2) based
on sample rate and milliseconds
move code from speex AEC implementation to module-echo-cancel such that
functionality can be reused by other AEC implementations
Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com>
prevents
CC module_ladspa_sink_la-module-ladspa-sink.lo
modules/module-ladspa-sink.c:1332:5: warning: "HAVE_DBUS" is not defined
modules/module-ladspa-sink.c:1370:5: warning: "HAVE_DBUS" is not defined
in case HAVE_DBUS is not available
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
If 'PlaybackChannels' and 'CaptureChannels' are absent in the UCM
file for a device, assume the device is stereo duplex.
Reported-by: Luke Yelavich <luke.yelavich@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Now you can actually see *which* sink/source that sends a specific
message to the log, which is quite useful if you have more than
one sound card.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The use of the pseudo-blocking D-Bus calls leads to the problem that
NameLost signals are received after the reply to ReleaseName().
The problem with this is that a later acquisition of the same audio
device can potentially receive the NameLost signal corresponding to
the previous instance, due to the fact that the signal hasn't been
popped from the D-Bus message queue.
The simplest approach to solve this problem is to poll the actual name
owner from the D-Bus daemon, in order to make sure that we did really
lose the name.
The proposal uses a blocking call to GetNameOwner to avoid incosistent
states in the internal APIs: it would otherwise be possible to have a
"busy" device before the reservation has been lost, in the unlikely
case if some other process acquires the name before we got the
confirmation that the NameLost was actually true.
The function is interesting for both rd_device and rd_monitor so make
it part of the rd_device public API to avoid duplicated code.
The decision to move the function to reserve.c is motivated by the fact
that other projects (i.e. jack) use reserve.c only. Therefore, adding a
reserve->reserve-monitor dependency should be avoided.
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>
