1. 11 Jul, 2020 1 commit
  2. 10 Jul, 2020 4 commits
  3. 09 Jul, 2020 1 commit
    • huiwang's avatar
      alsa: make the unsuspend more robust · ede8cbb1
      huiwang authored
      We met a weird situation on a couple of Lenovo machines and at least
      on one Dell machine. First we open the gnome-sound-setting, then
      suspend and resume the system, after the system resume back, the audio
      devices change to dummy, the audio doesn't work anymore. And pacmd
      list-cards shows no available sound card.
      
      Through debugging I found after resume, the alsa receives POLLERR
      events and it will call unsuspend to recover the pcm, but at that
      moment, the device nodes in /dev/snd/ is not accessible, so the
      snd_pcm_open() fails and the pulseaudio unload the module-alsa-card.
      
      Here I add retry and pa_msleep if snd_pcm_open fails, I tested it on
      all machines which have this problem, pa_msleep(25) is ok for most of
      them, there is only one machine which needs to call pa_msleep(25)
      twice, so for safety reason, I set the max retry times to 4.
      Signed-off-by: huiwang's avatarHui Wang <hui.wang@canonical.com>
      ede8cbb1
  4. 06 Jul, 2020 2 commits
  5. 30 Jun, 2020 1 commit
  6. 22 Jun, 2020 4 commits
    • Tanu Kaskinen's avatar
      7076e6d0
    • Libin Yang's avatar
      device-port: queue CARD CHANGE event before update default sink · 2ae94c14
      Libin Yang authored
      In single profile mode (headphone and speaker use different PCMs),
      when headphone is plugged in, pa_device_port_set_available() will call
      pa_core_update_default_sink/source() before posting
      PA_SUBSCRIPTION_EVENT_CARD|PA_SUBSCRIPTION_EVENT_CHANGE to the gnome.
      And pa_core_update_default_sink/source() will post
      PA_SUBSCRIPTION_EVENT_SERVER | PA_SUBSCRIPTION_EVENT_CHANGE to the gnome.
      So the original event sequence is:
      1. PA_SUBSCRIPTION_EVENT_SERVER | PA_SUBSCRIPTION_EVENT_CHANGE
      2. PA_SUBSCRIPTION_EVENT_CARD | PA_SUBSCRIPTION_EVENT_CHANGE
      
      In gnome-control-center:
      When it receives PA_SUBSCRIPTION_EVENT_SERVER, it will call
      req_update_server_info () to update the panel;
      When it receives PA_SUBSCRIPTION_EVENT_CARD, it will update
      the card information, for example, when the headphone is connected,
      it will call gtk_list_store_append() to append the headphone.
      
      Let's use an example to clarify the correct sequence.
      Assume we plug in headphone. PA will set the default sink to headphone
      from speaker, and hope gnome sound setting "Output Deivce" to highlight to
      "headphone". PA should send PA_SUBSCRIPTION_EVENT_CARD firstly to notify
      gnome-control-center "headphone" is plugged in. And then it sends
      PA_SUBSCRIPTION_EVENT_SERVER to trigger sound setting to highlight
      to "headphone".
      Signed-off-by: Libin Yang's avatarLibin Yang <libin.yang@intel.com>
      2ae94c14
    • Tanu Kaskinen's avatar
      sink, source: Use the global configuration for the avoid_resampling default · 04c554b7
      Tanu Kaskinen authored
      Previously avoid_resampling was always false unless the sink or source
      implementation explicitly configured the variable. The null sink doesn't
      explicitly configure it, so it didn't switch the sample rate as
      expected when avoid_resampling was enabled.
      
      This change means that also sinks that don't support rate switching can
      have avoid_resampling set to true, but I think that's fine, because
      pa_sink_reconfigure() doesn't try to do anything if the reconfigure()
      callback isn't set.
      
      Fixes: #923
      04c554b7
    • Taahir Ahmed's avatar
      Add a basic test suite for pa_hashmap · d97075c7
      Taahir Ahmed authored
      I spent a little time working through the implementation of
      pa_hashmap, and wrote a test suite while doing so.  It tests a few
      basic edge cases, like saturating all buckets of the hashtable.
      d97075c7
  7. 21 Jun, 2020 1 commit
  8. 20 Jun, 2020 1 commit
  9. 17 Jun, 2020 9 commits
  10. 16 Jun, 2020 1 commit
  11. 10 Jun, 2020 2 commits
    • Libin Yang's avatar
      core-subscribe: add PA_SUBSCRIPTION_EVENT_CARD in dump_event · 1778f76c
      Libin Yang authored
      fac_table[] lacks of PA_SUBSCRIPTION_EVENT_CARD item. This will cause
      pulseaudio crash when it tries to dump the PA_SUBSCRIPTION_EVENT_CARD
      event when DEBUG is defined.
      Signed-off-by: Libin Yang's avatarLibin Yang <libin.yang@intel.com>
      1778f76c
    • huiwang's avatar
      alsa-mixer: store the ucm_device with the order of their priority · 3549a4d9
      huiwang authored
      There is some case that multiple ucm devices share an amixer Jack
      like "Headphones", "Headset" and "Mic2" share the "Headphone Mic Jack",
      When the Jack state is changed, the module-switch-on-port-available
      will process them in the order they are in the jack->ucm_devices, and
      the last device will decide the final setting.
      
      But usually users put priority for those devices and expect the
      final setting is based on the highest priority device if there is no
      other policies like manual selection. So here do some change to store
      the ucm_devices according to their priority (from low to high).
      
      For example, we have ucm devices definition like below (ucm2):
                     SectionDevice."Mic2" {
                              Comment "Headphones Stereo Microphone"
      			...
                              Value {
                                      CapturePriority 200
      				...
                      }
      
                      SectionDevice."Headset" {
                              Comment "Headset Mono Microphone"
      			...
                              Value {
                                      CapturePriority 300
      				...
                              }
                      }
      
      Without this patch, the final setting is based on Mic2, after applying
      this patch, the final setting is based on the Headset (with higher
      priority than Mic2).
      Signed-off-by: huiwang's avatarHui Wang <hui.wang@canonical.com>
      3549a4d9
  12. 04 Jun, 2020 2 commits
    • Tanu Kaskinen's avatar
      raop-sink: Fix compiler warnings · fb3e4bb5
      Tanu Kaskinen authored
      There were three maybe-uninitialized warnings when building with
      Autotools (for some reason I don't see these with Meson):
      
      modules/raop/raop-sink.c: In function ‘thread_func’:
      modules/raop/raop-sink.c:543:16: warning: ‘intvl’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                   if (intvl < now + u->block_usec) {
                      ^
      In file included from ./pulsecore/macro.h:270,
                       from ./pulsecore/cpu-x86.h:25,
                       from ./pulsecore/cpu.h:23,
                       from ./pulsecore/core.h:26,
                       from modules/raop/raop-sink.c:48:
      ./pulsecore/log.h:129:28: warning: ‘check_timing_count’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       #define pa_log_warn(...)   pa_log_level_meta(PA_LOG_WARN,   __FILE__, __LINE__, __func__, __VA_ARGS__)
                                  ^~~~~~~~~~~~~~~~~
      modules/raop/raop-sink.c:404:14: note: ‘check_timing_count’ was declared here
           uint32_t check_timing_count;
                    ^~~~~~~~~~~~~~~~~~
      modules/raop/raop-sink.c:500:27: warning: ‘last_timing’ may be used uninitialized in this function [-Wmaybe-uninitialized]
                       pa_usec_t since = now - last_timing;
                                 ^~~~~
      
      I moved the intvl variable initialization out of the for loop, because
      it looked like the variable value is supposed to be remembered between
      the iterations. I don't know if the variable declaration (without
      initialization) in the beginning of the loop caused the compiler to
      touch the variable between iterations, probably not, but I'm pretty sure
      that's undefined behaviour.
      
      Other than that maybe-undefined behaviour, these compiler warnings may
      be false positives, since the variables are initialized when u->first is
      true.
      
      I initialized the three variables in to the same value as what is used
      when resetting them when u->first is true. I didn't test these changes,
      but they look safe to me.
      fb3e4bb5
    • Hugo Osvaldo Barrera's avatar
      Delete .travis.yml · ee6caebb
      Hugo Osvaldo Barrera authored
      ee6caebb
  13. 01 Jun, 2020 3 commits
    • Tanu Kaskinen's avatar
      stream-restore: Forget pre-14.0 stream routing · 1fe37e6d
      Tanu Kaskinen authored
      Prior to commits f899d5f4 and
      f62a49b8, GNOME's sound settings
      overwrote the routing for all entries in the stream-restore database
      when selecting a device. Now we prevent that from happening (see the
      aforementioned commits), but the old overwritten settings can still be in
      the database after updating to PulseAudio 14.0, and they can cause
      problems, as documented here:
      #832
      
      We can't distinguish between devices set by GNOME's sound settings
      and devices set by the user, so this patch discards all old device
      settings, even though that is going to cause PulseAudio to forget routing
      settings for many users. This is less bad than keeping the incorrect
      routing settings in the database, because it's difficult for users to
      figure out how to fix the situation when e.g. speaker test tones go to
      the internal speakers no matter what device is selected as the default,
      whereas old manual configuration can be restored restored by doing the
      manual configuration again. Also, it's probably more common to have at
      some point changed the default device in GNOME's sound settings than it
      is to have any manual per-stream routing settings.
      
      This is disabled by default, because this causes data loss, but
      distributions that use GNOME are recommended to enable this with
      the --enable-stream-restore-clear-old-devices (Autotools) or
      -Dstream-restore-clear-old-devices=true (Meson) build option.
      
      Fixes: #832
      1fe37e6d
    • Tanu Kaskinen's avatar
      stream-restore: Fix a potential crash in pa_namereg_is_valid_name() · 2ac2b445
      Tanu Kaskinen authored
      pa_namereg_is_valid_name() will hit an assertion if the name string is
      NULL. Maybe it would make sense to change pa_namereg_is_valid_name() so
      that it would return false on NULL, but I didn't want to change the
      function semantics at this time.
      
      e->device and e->card can be NULL even when device_valid and card_valid
      are set to true if the database contains bad data.
      
      I ran into this crash while developing new code, I haven't seen the
      crash in the wild.
      2ac2b445
    • Tanu Kaskinen's avatar
      stream-restore: Drop the version field from the entry struct · 46c263ac
      Tanu Kaskinen authored
      Storing the version in the entry struct is pointless. We should always
      write entries using the current version. When we encounter older
      versions when reading, those need to be converted to the current version
      anyway, because all code that uses the entry struct assumes that the
      data is stored according to the current version semantics.
      
      We're currently at the first version of the database entries, so
      currently there's no version conversion happening. I have a patch that
      will increment the entry version, so this is preparation for that.
      46c263ac
  14. 27 May, 2020 1 commit
  15. 23 Apr, 2020 2 commits
  16. 12 Apr, 2020 1 commit
  17. 10 Apr, 2020 2 commits
  18. 09 Apr, 2020 2 commits