Rather than write all the keys out for each port, simply write a 'null'
port entry and modify the read code to 'fallback' to this when it cannot
find a key. This is needed as the code used when writing the key may not
actually have the sink ports available at the time it uses them,
and thus can cause a segv. This approach adds some degree of overhead
but it's relatively minimal and it can be mitigated by compiling
without support for legacy database formats if so desired.
Thanks to David Henningsson for pointing out the problem.
I've seen more than one system where the volume control named
"Front" is a part of audio path for headphones. This is somewhat
of a compromise: While we don't merge it into the path, as that
would be regressing machines where "Front" isn't a part of the
audio path, it would still enable sound on these machines.
BugLink: http://bugs.launchpad.net/bugs/804178
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Unlinked streams can not be moved, so don't try.
BugLink: http://bugs.launchpad.net/bugs/837386
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Since none of our types is derived from GType, explicitly signal this.
The default value for this attribute changed at some point, breaking our
bindings.
When unloading, some module may end up trin to move a sink-input or
source-output back onto our virtual sink/source, causing an infinite
loop of us moving the stream away and having it moved back.
We prevent this from happening by preventing any stream from being
attached during unload.
Pacat remembers the number of cork requests, and then cork/uncork the stream
accordingly.
With this change, it makes below test script work correctly:
pacat -p --property=media.role="music" <long-sound> &
sleep 2
pacat -p --property=media.role="phone" <short-sound>
wait
Initial idea by Lu Guanqun, but modified by Colin Guthrie (so blame
me if it's broken)
The priorities should be set in the approximately likeliness that someone
would like to use them. This is hard to guess of course, but this is
a better guess compared to the existing configuration.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This will allow for volumes to be saved separately for e.g. Headphones vs. Speakers.
At present it is possible that no volume will be saved for the device prior to the port
switch. In this case the volume will not change from the value set under the other port.
In an ideal world we would save the volume before switching port, but that would require
a new hook.
The device restore saves both the current port for a device, and the volume/mute/formats.
The latter three are really related to the device+port, not the device on it's own.
Thus we store just the port for a device in one key and the volume/mute/formats
under a different key that includes both the device and the port.
I initially included put the Speex preprocessing assuming that we'd want
to use the digital gain control and noise suppression from Speex for all
echo cancelling implementations. In practice, we're probably going to
get entire implementations all processing in one package (WebRTC, custom
modules from various vendors, etc.).
This moves out this preprocessing and related knobs into the speex
implementation, which serves to clean out all implementation-specific
details from the module-echo-cancel core.
This is for bits of code or API where the concepts and constructs are
extensibly the same for sinks and sources. To avoid duplication we can
simply define our structure/API and then use this enum to differentiate
the two.
This reverts commit ba163b8b23.
After discussion with Colin, decided that we don't want to do this
piecemeal -- need some discussion on the mailing-list and then we should
do this across the tree in one fell swoop post 1.0.
Conflicts:
src/modules/module-device-restore.c
This is required for E-AC3 streams, as well as to let receivers we're
sending non-PCM data (which avoids playing noise if the data is
incorrect for some reason).
