A race condition prevents the AES non-audio bit from being set
when enabling IEC61937 passthrough on resume with no sink-input
connected (pa_sink_is_passthrough returns false). The non-audio
bit should really be set when opening the sink.
Force the sink to suspend/resume when actually entering passthrough
mode, and likewise force a suspend-resume on leaving passthrough mode.
Tested with E-AC3 streams which do need the AES bit set for my
Onkyon receiver to detect the format instead of playing it as
PCM.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This is basically a copy of module-always-sink but doing the same for
sources. Whenever no source is available, a module-null-source is loaded
and whenever a new source is available again, module-null-source is
unloaded.
By this, anything using a source will automatically be switched to the
null source when the actual source disappears, and back to the actual
source if it appears again.
There are actually two HSP HS UUIDs. My theory is that the second one
was added, because someone was not happy with the old UUID being used
for identifying two different things (the HSP profile as a whole, and
the HS role within the HSP profile). Some headsets only use the new
UUID, and those headsets won't work if we don't recognize the new UUID.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93898
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>
Some modules may only be loaded once, and trying to load them
twice from default.pa makes PulseAudio startup fail. While that could
be considered a user error, it's nicer to not be so strict. It's not
necessarily easy to figure what went wrong, if for example the user
plays with RAOP and adds module-raop-discover to default.pa, which first
works fine, but suddenly stops working when the user at some point
enables RAOP support in paprefs. Enabling RAOP in paprefs makes
module-gconf load the module too, so the module gets loaded twice.
This patch adds a way to differentiate module load errors, and
make cli-command ignore the error when the module is already
loaded.
It was reported that PulseAudio weakens the umask to 022 if it's
initially set to 077. That's not as big problem as it might seem,
but it's still a problem. The umask affects the permissions of the state
files, and those aren't readable by other users anyway in the per-user
mode, because PulseAudio puts them in directories that aren't
accessible to other users. In the system mode the state files will be
readable by everyone, though, even by those users that don't otherwise
have access to PulseAudio. The state files are slightly
privacy-sensitive, because they contain e.g. history of applications
that have used PulseAudio.
I can't think of any use cases where access to the state files by other
users would be necessary, either in the per-user mode or in the system
mode, so let's use umask 077. This doesn't prevent access to any
sockets in the system mode, because all directories that PulseAudio
creates in the system mode will have permissions 755 regardless of the
umask, and the sockets themselves always have permissions 777.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102060
Users may want to change the parameters of some load-once modules in
~/.config/pulse/default.pa. That should be possible by including
/etc/pulse/default.pa from the per-user configuration file, and then
unloading a module and reloading it with different parameters. However,
that doesn't work, because the unload-module command will not unload the
module immediately, so the subsequent load-module command will fail when
the module can be loaded only once.
This patch makes the module unloading synchronous. "pacmd unload-module
module-cli-protocol-unix" is something that might not like this change,
since the command will unload the code that is processing the command,
but I tested it and it works fine. When pa_module_unload() is called,
that won't yet remove the module code from memory, the lt_dlclose() call
is postponed until it's safe to remove the code from memory.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102205
module-switch-on-port-available didn't do anything when a port changes
its status if the card didn't have any sinks or sources. This was to
avoid bad things during card initialization, but the if condition also
prevented any profile switches away from the "off" profile, because the
card has no sinks or sources when the "off" profile is active.
pa_card nowadays has the "linked" flag that
module-switch-on-port-available could have checked instead, but since it
doesn't make sense to emit port status change events before the card has
been initialized, I added the check in pa_device_port_set_available()
instead.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=101794
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
When connecting a headset via the native backend, the transport state was
not updated correctly.
This patch sets the state to PLAYING in transport_acquire() if necessary.
If the description is not updated when moving, the old automatically
generated description will refer to the old master sink after the move,
which is not nice.
Setting the allow_negative flag of pa_{source,sink}_get_latency_within_thread() to true
leads to improved end to end latency estimation and to correct handling of negative port
latency offsets.
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>
Currently, if a stream is manually moved to a filter sink or source managed by
module-filter-apply, the stream will be silently re-routed to the master sink
or source, because the filter.apply property is not set on that stream. We can
assume, that the users intention however was to have the stream filtered.
Therefore this patch changes the logic, so that the stream will not be moved
to the master but remains on the filter sink or source. To handle the change
of a property correctly, the filter.apply property must be set temporarily.
An additional property filter.apply.set_by_mfa was introduced to mark those
streams, so that filter.apply can be removed again when the stream moves away
from the filter.
When a phone is connected via bluetooth and switches to HFP, the sinks
and sources will have higher priority than the built-in devices.
Therefore they are chosen as default and module-bluetooth-policy will
incorrectly insert loopback modules that loop the phone back to itself.
This patch fixes the problem by lowering the priority of sink and source
if PulseAudio is in the headset role. The priority is also lowered if the
device is an a2dp source. In both cases it does not make sense to make the
source or sink default unless there is no other sound device available.
Sources should probably be added to pa_core.sources in pa_source_put(),
but currently they're added in pa_source_new(). A lot of stuff can
happen between the pa_source_new() and pa_source_put() calls, and
it has happened that the default source was updated during this time.
Therefore, pa_core_update_default_source() needs to take it into account
that not every source is necessarily linked.
Currently pulseaudio crashes with an assertion in pa_rtpoll_item_new_asyncmsgq_read()
or pa_rtpoll_item_new_asyncmsgq_write() if a loopback is applied to a tunnel-new
sink or source, because tunnel-{sink,source}-new do not set thread_info.rtpoll.
The same applies to module-combine-sink and module-rtp-recv.
This patch is not a complete fix for the problem but provides a temporary band-aid
by initializing thread_info.rtpoll properly. The rtpoll created is never run, but
loopback and combine-sink nevertheless work, see comments in the code.
This patch does not work for module-rtp-recv, but using rtp-recv with a remote
sink does not seem to make a lot of sense anyway.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=73429
PA builds fine on MinGW except for the use of the scandir function in
pulsecore/conf-parser.c, so I provided a Win32 implementation. With this
patch the latest code builds on Win32 without problems.
If only part of the buffer is written into stdout by stdout_callback,
the buffer_index variable is increased by the number of written bytes,
buffer_length variable is decreased while the allocated buffer size
remains the same. That suggests that the current allocated size is
calculated as (buffer_index + buffer_length). However the current
stream_read_callback implementation writes new data to the start of the
buffer and allocates too little space, so that (buffer + buffer_index +
buffer_length - 1) could actully point outside of the allocated buffer.
pa_usec_t is an unsigned type, but there were calculations that used it
as if it were a signed type.
If the latency is negative, pa_simple_get_latency() now reports 0.
Added some comments too.
The on_the_fly_snapshot variable contains the amount of bytes that has
been sent from the source IO thread to the main thread, but not yet
pushed to the stream memblockq. The data is in the stream format, but
the bytes-to-usec conversion used the source format, which caused random
latency reporting errors.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=81075
This allows us to restore the default device properly when a
hotpluggable device (e.g. a USB sound card) is set as the default, but
unplugged temporarily. Previously we would forget that the unplugged
device was ever set as the default, because we had to set
configured_default_sink to NULL to avoid having a stale pa_sink pointer,
and also because module-default-device-restore couldn't resolve the name
of a currently-unplugged device to a pa_sink pointer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89934
This reverts commit 69c212f8c1.
Reasons:
The original reason for the patch was to work around some issue
regarding the profile not connecting immediately (sorry, I don't really
know the details), but that issue was fixed later by commit 998dfdf4cc,
so the original reason doesn't apply any more.
Automatically changing the profile when the transport state changes to
PLAYING has traditionally been handled by module-bluetooth-policy, and
as far as I can tell, there's no reason to change that.
The assertion is unsafe. It's not guaranteed that the profile change
will always succeed (at least pa_thread_mq_init() can fail due to
reaching the maximum file descriptor limit).
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>
module-stream-restore primarily uses the role of a stream for restoring. The sink-inputs
and source-outputs of filters all have role "filter", therefore currently all filters are
treated equally and are restored to the same device and volume.
This patch lets module-stream-restore ignore the streams that connect the filter to the
master.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
