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 use pa_memblockq_pop_missing() for all request handling,
including the initial request, because otherwise the counters will be
stay off during the entire runtime.
This should fix:
https://bugzilla.redhat.com/show_bug.cgi?id=559467
This should make it unlikely that we loop on SIGHUP indefinitely.
Also, this makes it possible for callbacks not to process all events and
still not busy loop.
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).
Commits e8cb96c and 0c836aa created mixer paths but did not update
src/Makefile.am. Building a snapshot containing these two commits
therefore results in the user being unable to adjust the volume or
(un)mute through PA. Fix this by adding the two new mixer paths
files to src/Makefile.am.
Likewise, commit 66e1a2d created a profile for the M-Audio FastTrack
Pro USB but did not update src/Makefile.am. Fix this by adding the
profile to src/Makefile.am.
The pretty name is suspposed to be understandable by non-technical
folks, and they are generally more used to the term "Subwoofer" than
"Low Frequency Emitter", so let's change the name here.
If two clients try to cleanup the SHM directory at the same time, they
might want to open and then delete the same segment at the same time, in
which case one client might win, the other one lose. In this case, don't
warn about ENOENT.
Apperently reading from an eventfd can fail, which results in an assert
to be hit. I am not sure about the reason for the failure, but in
attempt to track down the issue the next time is hit this prints a more
useful log message.
https://bugzilla.redhat.com/attachment.cgi?id=386380
