We need to resume audio devices even for streams that are created in
corked stat, so that the latency ranges of the audio device are known
during the initial latency negotiation. If we don't the latency
negotiation will be based on placeholder data and changed later on which
clients do not expect.
This should fix issues with Skype.
https://bugzilla.redhat.com/show_bug.cgi?id=554929
Create the 'Handsfree Gateway' profile for bluetooth cards and add
filters for 'org.bluez.HandsfreeGateway' to the discover module so
module-bluetooth-device is loaded with the correct profile when a
Handsfree Gateway connects to bluetoothd (in this case bluetoothd
is acting as the headset).
All seeks/flushes that depend on the playback buffer read pointer cannot
be accounted for properly in the client since it does not know the
actual read pointer. Due to that the clients do not account for it at
all. We need do the same on the server side. And we did, but a little
bit too extreme. While we properly have not applied the changes to the
"request" counter we still do have to apply it to the "missing" counter.
This patch fixes that.
This is not 100% ideal as we have not way to tie specific boosts to specific
inputs and this particular chipset (as noted in #772) appears to
support just that.
For the time being incorporate it into the normal boost logic.
See http://pulseaudio.org/ticket/772
When an GetProperties() reply arrives after we already deleted the
device structure for it make sure we don't accidentaly touch the
invalidated object.
https://bugzilla.redhat.com/show_bug.cgi?id=543205
If the user specifically removes the device element from the stream
restore rule, we have to clear the save_sink/save_source flag of the
stream. This means that other stream routing systems
(e.g. module-device-manager) can take over routing for this
stream. In order to facilitate the reapplication of other routing
rules, we fire a stream change event. Arguably the stream itself
has not changed, but the rules governing its routing have, so
I feel this is justified.
Unless the port number is explicitly configured we will now fallback to
a kernel picked port if the one we'd like by default we cannot get.
http://pulseaudio.org/ticket/773
Avahi and dbus is too heavy for OSX just for the sake of publishing our
services via mDNS/Zeroconf. Apple has its own Zeroconf implementation
called Bonjour, and this patch adds a module that implements service
announcement with that API.
All data gathering is copied from module-zeroconf-publish.c, but
unfortunately the code there is too specifically made for avahi, so I
couldn't factor it out to reuse it.
This patch adds support for CoreAudio driven devices under Mac OS X. It
is typically instanciated by the CoreAudio device detection module and
handles all available streams on a specific device.
Sinks are created according to the reported stream configuration.
Float32 is used as default audio sample format at it is the only format
CoreAudio speaks natively.
Hardware volume control is not implemented yet.
This adds a new module for CoreAudio device detection. It registers a
callback to detect hotplugged devices and creates/destroys modules named
'module-coreaudio-device'. Devices are identified via a system-wide
unique AudioDeviceID.
Even on 10.5.8, poll() does not do the right thing. Haven't checked on
newer versions. Hence, wrap all occurences of poll() to pa_poll and
emulate that call with select() on OSX. This is totally embarassing.