Some HD-audio codecs (at least ALC269VB and ALC283) become quite noisy on
high Mic Boost levels. So e g, if there is a "Mic Boost" and a "Capture"
control, both ranging from 0 dB to +30 dB, you get better quality if
"Mic Boost" is 0 dB and "Capture" is +30 dB, than the other way around.
By changing the order in the configuration files, this patch makes us prefer
leaving "Mic Boost" low and "Capture" high if the user selects a medium gain.
(This is based on limited experience, and there is no guarantee that there are
no sound cards that work the other way around, and therefore this patch could
potentially regress quality on those machines. Hopefully those are fewer, so
this is what we should default to.)
BugLink: https://bugs.launchpad.net/1085402
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Currently the biggest possible sink latency is 10 seconds. The total
latency of the loopback is divided evenly for the source, an
intermediate buffer and the sink, so if I want to test 10 s sink
latency, the total needs to be three times that, i.e. 30 seconds.
Usually, you want to use one input or output at a time: e g,
you expect your speaker to mute when you plug in headphones.
Therefore, the headphones+speaker port should have lower priority
and both headphones and speaker.
A practical formula to do this is 1/x = 1/xa + 1/xb + .. + 1/xn.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We document the default values in daemon.conf, but this was not
updated when we changed the default from speex-float-3 to speex-float-1.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The log message didn't match the code, so one of them was wrong. It's
entirely possible that the code is wrong, but I didn't have the
motivation to study the code enough to understand what the code is
supposed to do.
Dependant in British English is a person who is financially supported by
someone else. To express software dependency relations "dependent"
should be used instead, which is correct for both British and US
English.
u->sink->state is not yet updated, so the state must be read from
u->sink->thread_info.state. This makes pausing and resuming of the
smoother happen at the right time.
Thanks to Pierre Ossman for the patch.
Previously, if there were no modules loaded when the daemon exited,
pa_module_unload_all() would crash due to giving zero count to
pa_xnew().
Thanks to Pierre Ossman for the patch.
The reference ratio should always be kept up-to-date. If the reference
ratio is not updated when the input volume changes, the stale
reference ratio ends up being used as the new input volume when the
input is moved.
All pa_cvolume_snprint(), pa_volume_snprint(),
pa_sw_cvolume_snprint_dB() and pa_sw_volume_snprint_dB() calls have
been replaced with pa_cvolume_snprint_verbose() and
pa_volume_snprint_verbose() calls, making the log output more
informative and the code sometimes simpler.
The source output and sink inputs should be corked if the corresponding
sink/source is suspended, as handled during module initialization. This
also needs to be handled during stream move, because the suspend state
of the destination sink/source might be different to the previous one.
This fixes the issue with an infinite number of "Requesting rewind due
to end of underrun" traces after a stream move.
A dynamic array is a nice simple container, but the old interface
wasn't quite what I wanted it to be. I like GLib's way of providing
the free callback at the container creation time, because that way
the free callback doesn't have to be given every time something is
removed from the array.
The allocation pattern was changed too: instead of increasing the
array size always by 25 when the array gets full, the size gets
doubled now (the lowest non-zero size is still 25).
The array can't store NULL pointers anymore, and pa_dynarray_get() was
changed so that it's forbidden to try to access elements outside the
valid range.
The set of supported operations may seem a bit arbitrary. The
operation set is by no means complete at this point. I have included
only those operations that are required by the current code and some
unpublished code of mine.
It's easier to work with the port description if it can be assumed
that it's always non-NULL. I have checked that the current code base
always ensures a non-NULL description.
With the new behaviour, you will not always get a callback after a
successful write. Make sure the callers can properly handle this.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
