Positive base volume can happen, if the alsa volume range has been limited. For
example, in an embedded environment it may be known that the sound device is
capable of louder output than what the speakers can handle, so setting the max
volume below 0 dB makes sense.
The syntactically correct error meant that the timestamp was always
marked as found and only the first header was checked.
In the case where the timestamp was the first header, things
would have worked as expected.
Thanks to pino for reporting via bug refs #818
Rewinding the ring buffer completely causes audible issues with DMAs.
Previous solution didn't work with tsched=0, and used tsched_watermark
for guardband, which isn't linked to hardware and could become really high
if underflows occurred.
Added separate parameter that can be tuned to hardware limitations and size
of DMA bursts.
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
