Some bad quality BT-headsets block bluez socket sometimes for hundreds
of milliseconds, especially when changing mode. When the module tries
catch up the lost time it may SBC encode up to half a second of audio
without yielding. On slow machine this may cause maximum RT time slice
to be exceeded. Cleaned out the minor fix that slipped into first version
of the patch.
This has the benefit that we can properly support ALSA devices where
only the raw 'hw' device exists but no 'front' although it's a proper
2ch stereo device.
Lennart Poettering <lennart@poettering.net> wrote:
> On Wed, 15.04.09 16:26, Erich Boleyn (erich@uruk.org) wrote:
>
> > Just noticed the new 0.9.15 release, got it building on Gentoo, and then
> > found that the non-dbus build's ALSA modules appear to be broken:
...
> > Is this something that can stubbed out (relatively) safely?
>
> Hmm, yes. As it seems I broke the build for non-dbus builds. Should be
> easy to fix. Best way is probably to make the reserver wrapper mostly
> a noop if D-Bus is not available.
>
> Please understand that I don't really focus on making every weird
> combination of build deps work. So I won't fix this for you. But I am
> happy to merge good patches!
No problem, I was mainly looking for a hint that to your knowledge there
should be no wierd side-effects from stubbing out the reserve and dbus
functions inside reserve_wrapper. Thanks for said hint. ;-)
Attached is a patch to include "reserve_wrapper.[ch]" in the non-dbus
builds, and do said stubbing when HAVE_DBUS is not defined. It has
passed moderate testing: built both versions, both pass
"pulseaudio --dump-modules" with no weird messages, and the
"--disable-dbus" build works and produces audio as expected in some
simple tests including RTP.
Lennart wrote,
>
> Hmm, yes. As it seems I broke the build for non-dbus builds.
Well, you also broke the solaris module between 0.9.15-test8 and 0.9.15.
Have you considered release candidates?
Patch follows. It would be nice if API changes could be made without
breaking things when the effort to avoid that is trivial.
Finn
The reference volume is to be used as reference volume for stored stream
volumes. Previously if a new stream was created the relative volume was
taken relatively to the virtual device volume. Due to the flat volume
logic this could then be fed back to the virtual device volume.
Repeating the whole story over and over would result in a device volume
that would go lower, and lower and lower.
This patch introduces a 'reference' volume for each sink which stays
unmodified by stream volume changes even if flat volumes are used. It is
only modified if the sink volumes are modified directly by the user.
For further explanations see http://pulseaudio.org/wiki/InternalVolumes
