This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
Previously max_rewind was always set to the full hw buffer size, but
the actual maximum rewind amount is limited to the part of the hw buffer
that is in use.
The rewind request that was done when lowering the sink latency had to
be moved to happen before updating max_rewind.
The practical benefit of this change: When using a filter source on a
monitor source, the filter source latency is increased by max_rewind.
Without this change the max_rewind of an alsa sink is often
unnecessarily high, which leads to unnecessarily high latency with
filter sources.
Monitor sources themselves don't suffer from the latency issue, because
they use the current sink latency instead of max_rewind for the extra
buffer that they keep to deal with rewinds.
This rejigs the update_rate() logic to encompass changes to the sample
spec as a whole, as well as passthrough status. As a result,
sinks/sources provide a reconfigure() method which allows
reconfiguration as required.
The behaviour itself is currently unchanged -- alsa-sink/-source do not
actually implement anything other than rate updates for now (nor are
they ever requested to). This can be modified in the future, to allow,
for example 24-bit output when incoming media supports it, as well as
channel count changes for passthrough sinks.
Another related change is that passthrough status is now part of
sink/source reconfiguration, and we can stop doing a suspend/unsuspend
when entering/leaving passthrough state. So that part is now divided
in two -- pa_sink_reconfigure() sets the sink in passthrough mode if
required, and pa_sink_enter_passthrough() sets up everything else
(this currently means only volumes, but could disable other processing)
for passthrough mode.
This reverts commit ca63fbc1d8.
I applied the patch too hastily. force-speaker.conf is supposed to be
used only when the alsa mixer doesn't contain any elements that would
indicate the existence of a speaker port, but the reverted patch is a
workaround for a different problem. On the two affected EeePC machines
the Headphone element needs to be unmuted when using speakers. The
analog-output-speaker-always path happens to do that, but that's
unintentional. analog-output-speaker was changed[1] to mute the
headphone output when using the speaker port, and
analog-output-speaker-always should have been changed too, but that was
forgotten.
The kernel driver is buggy if it has a Headphone mixer element that
mutes both headphones and speakers, so this should be fixed in alsa. If
we end up having a workaround in PulseAudio for the broken driver, it
should be implemented with a new profile set and path configuration
files.
[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=22aac4e9fdb3786178f7815a0cb2150f588b1582
Pulseaudio tries to pick the best profile (on startup or
hotplugged), the best profile is the profile with the highest
priority which isn't unavailable.
Due to the facts that iec958 ports available status always (?)
is unknown, and that it is generally more likely that a user use
hdmi than iec958, lets prioritze hdmi over iec958.
This patch shift the analog-* mappings +5 and hdmi-* mappings +5.
Some sound cards don't have any alsa-lib configuration, but they used to
work well enough up to PulseAudio 10. PulseAudio 11 stopped using "hw:0"
for the analog-stereo mapping, and instead defined it as a fallback
mapping without any mixer handling. As a result, switching between
headphones and speakers stopped working without changing the mixer
settings manually at least on Toshiba Chromebook 2. This patch adds the
mixer handling back to the fallback mapping.
I also renamed "unknown-stereo" to "stereo-fallback", because I like
that name more.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102560
to_alsa_dB() returns a result rounded to two decimal places (instead of
using integer truncation) to avoid small errors when converting between
dB and volume.
Consider playback at -22 dB (which is supported by ALSA) but results in
the higher level of -21 dB plus software attenuation.
pa_sw_volume_from_dB(-22) = 28172
pa_sw_volume_to_dB(28172) = -21.9997351
to_alsa_dB(-21.9997351) = -2199
ALSA value 106 = -2200
ALSA value 107 = -2100
...
rounding = +1 /* "accurate or first above" */
snd_mixer_selem_ask_playback_dB_vol(me, -2199, rounding, &alsa_val)
alsa_val = -2100
Signed-off-by: Ian Ray <ian.ray@ge.com>
It was reported that on a certain USB card, identified as
"0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device",
the "PCM Capture Source" element had to be set to "IEC958 In" before
the iec958 input would work.
The iec958-stereo-input.conf file didn't exist before, although the path
was referenced in the default.conf profile configuration file.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=101973
There are one headset jack on the front panel of TB16, through this
jack, we have one stereo headphone output (hw:%f,0,0) and one mono
headset-mic input (hw:%f,0,0); and there is one speaker output jack
(hw:%f,1,0) on the rear panel of TB16.
The detail information of the Dell dock TB16:
http://www.dell.com/support/article/sg/en/sgbsdt1/SLN301105
Signed-off-by: Hui Wang <hui.wang@canonical.com>
There are two reasons for this change:
1. If it is a Dell desktop machine with the realtek codec, and there
is no internal microphone on it, there is one physical audio jack
which can support headphone, headset and microphone, but this audio
jack does not have hardware capability to distinguish what is plugged
in, after users plug in a headphone and select headphone from UI
program, the headphone can't output any sound. There are many reasons
for this issue, one of them is the active_port of pa_source is set
to headphone-mic, that means the kernel audio driver will configure
this audio jack to be a microphone jack instead of headphone jack.
If we make the priority of headset-mic a bit higher than headphone-mic,
the headset-mic will be the active_port of pa_source unless users
select the headphone-mic on purpose, then this issue will be fixed.
2. Nowadays, the headset is more popular than traditional microphone,
It is highly possible that users plug in a headset instead of
microphone, it makes sense to make the headset-mic's priority higher
than headphone-mic's.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Previously, if front:x didn't work, we would try to use hw:x for analog
stereo output. There's no guarantee that hw:x is an analog output,
however. For example, the Intel HDMI LPE driver uses hw:x for HDMI
output, and PulseAudio incorrectly created analog profiles for that
card, because front:x doesn't work but hw:x does.
This patch changes things so that the analog stereo mapping doesn't any
more use hw:x as a fallback. A separate "unknown stereo" fallback
mapping is added to handle the rare case where hw:x is the only PCM
device that works.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
If the ALSA device supports granular pointer reporting, we end up in a
situation where we write out a bunch of data, iterate, and then find a
small amount of data available in the buffer (consumed while we were
writing data into the available buffer space). We do this 10 times
before quitting the write loop.
This is inefficient in itself, but can also have wider consequences. For
example, with module-combine-sink, this will end up pushing the same
small chunks to all other devices too.
Given both of these, it just makes sense to not try to write out data
unless a minimum threshold is available. This could potentially be a
fragment, but it's likely most robust to just work with a fraction of
the total available buffer size.
In alsa-lib, snd_pcm_hw_params() internally calls snd_pcm_prepare(), thus
user space applications have no need to call snd_pcm_prepare() after calls
of snd_pcm_hw_params(). An explicit calls of snd_pcm_prepare() is expected
in a case to recover PCM substreams.
Current implementation of PulseAudio modules for ALSA playbacking/capturing
results in double calls of snd_pcm_prepare(). The second call for hw plugin
of alsa-lib executes ioctl(2) with SNDRV_PCM_IOCTL_PREPARE command in state
of SNDRV_PCM_STATE_PREPARED for the PCM substream. This has no effects to
the PCM substream as long as corresponding drivers are implemented
correctly.
This commit removes the second call for the reason.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Bug 96741 shows a case where an assertion is hit, because
pa_asyncq_new() failed due to running out of file descriptors.
pa_asyncq_new() is used in only one place (not counting the call in
asyncq-test): pa_asyncmsgq_new(). Now pa_asyncmsgq_new() can fail too,
which requires error handling in many places. One of those places is
pa_thread_mq_init(), which can now fail too, and that needs additional
error handling in many more places. Luckily there weren't any places
where adding better error handling wouldn't have been easy, so there are
many changes in this patch, but they are not complicated.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96741
The alsa card hasn't so far set any availability for profiles. That
caused an issue with some HDMI hardware: the sound card has two HDMI
outputs, but only the second of them is actually usable. The
unavailable port is marked as unavailable and the available port is
marked as available, but this information isn't propagated to the
profile availability. Without profile availability information, the
initial profile policy picks the unavailable one, since it has a
higher priority value.
This patch adds simple logic for marking some profiles unavailable:
if the profile only contains unavailable ports, the profile is
unavailable too. This can be improved in the future so that if a
profile contains sinks or sources that only contain unavailable ports,
the profile should be marked as unavailable. Implementing that
requires adding more information about the sinks and sources to
pa_card_profile, however.
BugLink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8448
I want module-alsa-card to set the availability of unavailable
profiles before the initial card profile gets selected, so that the
selection logic can use correct availability information.
module-alsa-card initializes the jack state after calling
pa_card_new(), however, and the profile selection happens in
pa_card_new(). This patch solves that by moving parts of pa_card_new()
to pa_card_choose_initial_profile() and pa_card_put().
pa_card_choose_initial_profile() applies the profile selection policy,
so module-alsa-card can first call pa_card_new(), then initialize the
jack state, and then call pa_card_choose_initial_profile(). After that
module-alsa-card can still override the profile selection policy, in
case module-alsa-card was loaded with the "profile" argument. Finally,
pa_card_put() finalizes the card creation.
An alternative solution would have been to move the jack
initialization to happen before pa_card_new() and use pa_card_new_data
instead of pa_card in the jack initialization code, but I disliked
that idea (I want to get rid of the "new data" pattern eventually).
The order in which the initial profile policy is applied is reversed
in this patch. Previously the first one to set it won, now the last
one to set it wins. I think this is better, because if you have N
parties that want to set the profile, we avoid checking N times
whether someone else has already set the profile.
If a card has been hot-plugged after pulseaudio start, alsa-lib still has
old configuration in memory, which doesn't have PCM definitions for the
new card. Thus, this error appears, and the device doesn't work:
I: [pulseaudio] (alsa-lib)confmisc.c: Unable to find definition 'cards.USB-Audio.pcm.front.0:CARD=0'
I: [pulseaudio] (alsa-lib)conf.c: function snd_func_refer returned error: No such file or directory
I: [pulseaudio] (alsa-lib)conf.c: Evaluate error: No such file or directory
I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:0
I: [pulseaudio] alsa-util.c: Error opening PCM device front:0: No such file or directory
The snd_config_update_free_global() function makes alsa-lib forget any
cached configuration and reparse all PCM definitions from scratch next
time it is told to open anything.
The trick has been copied from Phonon.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=54029
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
This is needed so we don't keep stale jack availability information
while the card is suspended.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93259
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
`Mic` is now detected as `Mic-In/Mic Array` (there are 2 microphones physically, nice to se this being understood).
`Line` is now detected as `Line In`.
Removed all output modes except officially supported stereo, 5.1 and stereo S/PDIF.
Also microphone/line in now might be used simultaneously with either output mode, yay!
By refactoring volume probing into its own function, we can reduce
indentation a lot. Also, if an error occurs during the volume probe,
that volume element is now always skipped (instead of taking down
the entire path with it).
Also, a bug for elements with more than two channels is fixed, as
previously, the volume parsing code was continuing, potentially
referencing somewhere outside the array (which has max two channels).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This isn't a great fix, but we need ALSA API to do this right. In the
mean time, USB devices work fine with timer-based scheduling, so there's
no reason to force a large minimum latency by disabling tsched on them.
This allows a configuration scheme where after loading configuration
from "somefile", the parser loads configuration from files in
directory "somefile.d". This feature needs to be enabled on a per-file
basis, though, and this patch doesn't yet enable the feature for any
files.
When synthesized alsa path is freed there is an assert from NULL
proplist. Create empty proplist for the path to fix.
Signed-off-by: Juho Hämäläinen <juho.hamalainen@nomovok.com>
It doesn't work currently (fails and falls back to PCM), due to channel
count mismatch between the sink sample spec and the sample spec required
by IEC61937.
To be reverted when someone implements changing channel count without
switching profiles. This would also be required for HBR passthrough over
HDMI.
Reported-by: Xamindar <junkxamindar@gmail.com>
Signed-off-by: Alexander E. Patrakov <patrakov@gmail.com>
We encountered an alsa plugin a while ago (not sure if the source
can be shared) which had mixer controls, but no descriptors to
poll for changes.
Quit early to avoid latter assertion failures.
BugLink: https://bugs.launchpad.net/bugs/1092377
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
The combination "Front Headphone" + "Headset Mic Phantom"
was found on one the machines we enable. Without this patch,
the headset mic appeared plugged in when nothing was plugged
into the jack.
BugLink: https://bugs.launchpad.net/bugs/1513384
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We currently only support one and two channels for volumes, and
bail out otherwise. This makes Xonar users unhappy because they
have a volume with eight channels, and bailing out means they
don't have a path/port at all.
This way they will at least have a port, which will in turn make
the gnome/unity UI behave better.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=84983
BugLink: https://bugzilla.gnome.org/show_bug.cgi?id=745017
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
In case the same jack causes one port to become available and another
one unavailable, the available should be reported first.
This is to avoid unnecessary changes: e g, consider a 'Headphone Jack'
making 'Headphone' available and 'Speaker' unavailable. In case the
unavailable change triggers first, and there is also a currently available
third port (e g 'Digital out'), the routing system might choose to route
to this port because neither of the 'Speaker' and 'Headphone' ports are
available.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
I'm not sure how much they are needed nowadays with the latest
changes to the subset elimination (I found this while
researching a bug on an older PA version), but I guess they could
be added for consistency at least.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
