1. 16 Jul, 2019 1 commit
  2. 15 Jul, 2019 1 commit
    • Arun Raghavan's avatar
      svolume: Mark channel parameter as earlyclobber · e8fe04b2
      Arun Raghavan authored
      For all our MMX/SSE code, we use a temporary channel variable, assigned
      to the DI register, which is zero'ed as the very first operation in the
      inline assembly code, before any other code is run.
      With GCC 9.1, while using -O2, the DI register is also used for the
      input operand. This is perfectly legal, but causes our code to become
      incorrect because the output operand that is assigned to DI is not
      explicitly marked as being clobbered before inputs are read.
      This change fixes the problem by adding an earlyclobber annotation (&)
      to the DI output argument.
  3. 11 Jul, 2019 3 commits
  4. 05 Jul, 2019 1 commit
  5. 04 Jul, 2019 2 commits
    • Arun Raghavan's avatar
      build-sys: Bump libpulse soversion · b427dfcd
      Arun Raghavan authored
      We've added new API and updated an enum. A bunch of function parameters
      have been marked as const, but this probably shouldn't count as a change
    • Arun Raghavan's avatar
      core-util: Fix detection when running in a VM · 2ed4f388
      Arun Raghavan authored
      The original code that was written was trying to detect what hypervisor
      we were running under, rather than testing the presence bit first. We
      don't really need the former, so let's use the more comprehensive latter
      Fixes: #684
  6. 03 Jul, 2019 2 commits
    • Georg Chini's avatar
      sink-input: fix rewriting render memblockq when nothing should be rewound · 4c6bab43
      Georg Chini authored
      If process_rewind() is called with nbytes = 0, process_rewind() will
      nevertheless request a rewrite of the render memblockq.
      This patch fixes the problem by adding the render memblockq length to the
      rewrite amount only if nbytes > 0.
    • Georg Chini's avatar
      source-output: Fix rewinding bug · 1240afab
      Georg Chini authored
      Currently the rewind logic for the source output is broken if the output
      does not implement a process_rewind() callback. In that case, the read
      index of the delay memblockq is rewound. This is wrong, because the data
      that is going to be re-written was not yet read. Instead the write index
      should be rewound and the read index left untouched. This is the reason
      for the rewind glitches of monitor sources.
  7. 02 Jul, 2019 2 commits
    • Frédéric Danis's avatar
      bluetooth: Fix crash when disabling Bluetooth adapter · f89d64b9
      Frédéric Danis authored
      This crash occurs when PA is connected to a phone through the oFono
      When disabling the Bluetooth adapter, pa_bluetooth_device is removed before
      hf_audio_card. Both keep refs on pa_bluetooth_transport. Those removal will
      call pa_bluetooth_transport_free() from device_free() (bluez5-util.c) and
      hf_audio_card_free() (backend-ofono.c).
      In the end, the call to pa_bluetooth_transport_free() calls
      pa_hasmap_remove() through pa_bluetooth_transport_unlink(), but since
      memory has already been freed, the second try results in a segfault.
      Triggering hf_audio_card removal during pa_bluetooth_device removal allows
      hf_audio_card to be freed at the right time.
    • Frédéric Danis's avatar
      bluetooth: Fix crash in setup_stream() · 661b13d5
      Frédéric Danis authored
      setup_stream() crashes when calling set_nonblock() with an invalid
      On a new call, the ofono backend gets notified of a new connection.
      The ofono backend sets the transport state to playing, and that triggers
      a profile change, which sets up the stream for the first time.
      Then module-bluetooth-policy sets up the loopbacks. The loopbacks get
      fully initialized before the crash.
      After module-bluetooth-policy has done its things, the execution
      continues in the transport state change hook. The next hook user is
      module-bluez5-device, whose handle_transport_state_change() function
      gets called. It will then set up the stream again even though it's
      already set up. I'm not sure if that's a some kind of a bug.
      setup_stream() can handle the case where it's unnecessarily called,
      though, so this second setup is not a big problem.
      The crash happens, because the connection died due to POLLHUP in the IO
      thread before the second setup_stream() call.
  8. 01 Jul, 2019 3 commits
  9. 30 Jun, 2019 1 commit
  10. 23 Jun, 2019 1 commit
  11. 22 Jun, 2019 1 commit
  12. 17 Jun, 2019 1 commit
  13. 16 Jun, 2019 1 commit
    • Tanu Kaskinen's avatar
      a2dp-codec-sbc: get rid of compiler warnings · 4e08c14c
      Tanu Kaskinen authored
      The warnings:
      modules/bluetooth/a2dp-codec-sbc.c: In function ‘default_bitpool’:
      modules/bluetooth/a2dp-codec-sbc.c:161:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
                   switch (mode) {
      modules/bluetooth/a2dp-codec-sbc.c:169:9: note: here
               case SBC_SAMPLING_FREQ_44100:
      modules/bluetooth/a2dp-codec-sbc.c:170:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
                   switch (mode) {
      modules/bluetooth/a2dp-codec-sbc.c:180:9: note: here
               case SBC_SAMPLING_FREQ_48000:
      These were valid warnings in that an invalid channel mode would result
      in unintended fallthroughs, but the end result would anyway been a crash
      in the pa_assert_not_reached() at the end of the function, so
      functionally there's no change.
  14. 15 Jun, 2019 1 commit
  15. 11 Jun, 2019 1 commit
    • Thomas Hutschenreuther's avatar
      atomic: fix load and store for armv7 and higher · d4ff4adc
      Thomas Hutschenreuther authored
      The original atomic implementation in pulseaudio based on
      libatomic stated that the intent was to use full memory barriers.
      According to [1], the load and store implementation based on
      gcc builtins matches sequential consistent (i.e. full memory barrier)
      load and store ordering only for x86.
      I observed random crashes in client applications using memfd srbchannel
      transport on an armv8-aarch64 platform (cortex-a57).
      In all those crashes the first read on the pstream descriptor
      (the size field) was wrong and looked like it contained old data.
      I boiled the relevant parts of the srbchannel implementation down to
      a simple test case and could observe random test failures.
      So I figured that the atomic implementation was broken for armv8
      with respect to cross-cpu memory access ordering consistency.
      In order to come up with a minimal fix, I used the newer
      __atomic_load_n/__atomic_store_n builtins from gcc.
      aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425
      they compile to
      ldar and stlxr on arm64, which is correct according to [1] and [2].
      The other atomic operations based on __sync builtins don't need
      to be touched since they already are of the full memory barrier
      [1] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
      [2] <https://community.arm.com/developer/ip-products/processors
  16. 10 Jun, 2019 2 commits
  17. 09 Jun, 2019 3 commits
    • shdown's avatar
      mainloop: fix timeout assignment in pa_mainloop_prepare · 6b1719d0
      shdown authored
      The function calculates the correct timeout (in microseconds) to assign 
      in the `u` variable, but then assigns `m->prepared_timeout` the value   
      of the `timeout` argument (in milliseconds).
    • huiwang's avatar
      stream-restore: Don't restore if the active_port is PA_AVAILABLE_NO · cbaeea4a
      huiwang authored
      We met two problems recently, one happened on a Lenovo machine with
      dual analogue codecs, the other happened on a Dell machine with
      a digital mic directly connected to PCH. The two problems are
      basically same, there is an internal mic and an external mic, the
      internal mic always shows up in the gnome-control-center, the external
      mic only shows up when it is plugged. After the external mic is
      plugged and users select it from gnome-control-center, the
      gnome-control-center will read all saved streams through extension_cb,
      and bind the source of external mic to all streams, after that the
      apps only record sound via the source of external mic, after the
      external mic is unplugged, the internal mic will automatically be
      selected since it is the only left input device in the
      gnome-control-center, since users don't select it, all streams are
      still bond the source of external mic. When users record sound via
      apps, they can't record any sound even the default_source is the
      source of internal mic and the internal mic is selected in the UI.
      It is very common that a machine has internal mic and external mic,
      but this problem didn't expose before, that is because both internal
      mic and external mic belong to one source, but for those two
      machines, the internal mic belongs to one source, while the external
      mic belongs to another source (they are in differnt codecs or one is
      in the codec and the other is from PCH),
      To fix it with a mininal change, we just check if the active_port is
      PA_AVAILABLE_NO or not when building a new stream, if it is, don't
      restore the device to the new built stream, let pa_source_output_new()
      decide the source device for this stream.
      And we also do the same change to sink_input.
      This change only affects the new built streams, it will not change
      the database, so the users' preference is still saved in the database,
      after the active_port is not PA_AVAILABLE_NO, the new streams will
      still restore to the preferred device.
      Signed-off-by: huiwang's avatarHui Wang <hui.wang@canonical.com>
    • Mark Filion's avatar
      i18n: Fix copyright information in pt_BR.po · 54931e86
      Mark Filion authored
  18. 08 Jun, 2019 13 commits