1. 13 Dec, 2021 2 commits
    • Takashi Sakamoto's avatar
      ALSA: uapi: use C90 comment style instead of C99 style · 55b71f6c
      Takashi Sakamoto authored
      UAPI headers are built with compiler option for C90, thus double-slashes
      comment introduced in C99 is not preferable.
      
      Fixes: fb6723da ("ALSA: pcm: comment about relation between msbits hw parameter and [S|U]32 formats")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20211213081257.36097-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      55b71f6c
    • Takashi Sakamoto's avatar
      ALSA: pcm: comment about relation between msbits hw parameter and [S|U]32 formats · fb6723da
      Takashi Sakamoto authored
      Regarding to handling [U|S][32|24] PCM formats, many userspace
      application developers and driver developers have confusion, since they
      require them to understand justification or padding. It easily
      loses consistency and soundness to operate with many type of devices. In
      this commit, I attempt to solve the situation by adding comment about
      relation between [S|U]32 formats and 'msbits' hardware parameter.
      
      The formats are used for 'left-justified' sample format, and the available
      bit count in most significant bit is delivered to userspace in msbits
      hardware parameter (struct snd_pcm_hw_params.msbits), which is decided by
      msbits constraint added by pcm drivers (snd_pcm_hw_constraint_msbits()).
      
      In driver side, the msbits constraint includes two elements; the physical
      width of format and the available width of the format in most significant
      bit. The former is used to match SAMPLE_BITS of format. (For my
      convenience, I ignore wildcard in the usage of the constraint.)
      
      As a result of interaction between ALSA pcm core and ALSA pcm application,
      when the format in which SAMPLE_BITS equals to physical width of the
      msbits constaint, the msbits parameter is set by referring to the
      available width of the constraint. When the msbits parameter is not
      changed in the above process, ALSA pcm core set it alternatively with
      SAMPLE_BIT of chosen format.
      
      In userspace application side, the msbits is only available after calling
      ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS request. Even if the hardware
      parameter structure includes somewhat value of SAMPLE_BITS interval
      parameter as width of format, all of the width is not always available
      since msbits can be less than the width.
      
      I note that [S|U]24 formats are used for 'right-justified' 24 bit sample
      formats within 32 bit frame. The first byte in most significant bit
      should be invalidated. Although the msbits exposed to userspace should be
      zero as invalid value, actually it is 32 from physical width of format.
      
      [ corrected typos -- tiwai ]
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210529033353.21641-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb6723da
  2. 12 Dec, 2021 4 commits
  3. 07 Dec, 2021 4 commits
  4. 06 Dec, 2021 3 commits
  5. 02 Dec, 2021 2 commits
  6. 01 Dec, 2021 1 commit
  7. 30 Nov, 2021 3 commits
  8. 29 Nov, 2021 1 commit
    • Thomas Gleixner's avatar
      ALSA: hda: Make proper use of timecounter · 6dd21ad8
      Thomas Gleixner authored
      HDA uses a timecounter to read a hardware clock running at 24 MHz. The
      conversion factor is set with a mult value of 125 and a shift value of 0,
      which is not converting the hardware clock to nanoseconds, it is converting
      to 1/3 nanoseconds because the conversion factor from 24Mhz to nanoseconds
      is 125/3. The usage sites divide the "nanoseconds" value returned by
      timecounter_read() by 3 to get a real nanoseconds value.
      
      There is a lengthy comment in azx_timecounter_init() explaining this
      choice. That comment makes blatantly wrong assumptions about how
      timecounters work and what can overflow.
      
      The comment says:
      
           * Applying the 1/3 factor as part of the multiplication
           * requires at least 20 bits for a decent precision, however
           * overflows occur after about 4 hours or less, not a option.
      
      timecounters operate on time deltas between two readouts of a clock and use
      the mult/shift pair to calculate a precise nanoseconds value:
      
          delta_nsec = (delta_clock * mult) >> shift;
      
      The fractional part is also taken into account and preserved to prevent
      accumulated rounding errors. For details see cyclecounter_cyc2ns().
      
      The mult/shift pair has to be chosen so that the multiplication of the
      maximum expected delta value does not result in a 64bit overflow. As the
      counter wraps around on 32bit, the maximum observable delta between two
      reads is (1 << 32) - 1 which is about 178.9 seconds.
      
      That in turn means the maximum multiplication factor which fits into an u32
      will not cause a 64bit overflow ever because it's guaranteed that:
      
           ((1 << 32) - 1) ^ 2 < (1 << 64)
      
      The resulting correct multiplication factor is 2796202667 and the shift
      value is 26, i.e. 26 bit precision. The overflow of the multiplication
      would happen exactly at a clock readout delta of 6597069765 which is way
      after the wrap around of the hardware clock at around 274.8 seconds which
      is off from the claimed 4 hours by more than an order of magnitude.
      
      If the counter ever wraps around the last read value then the calculation
      is off by the number of wrap arounds times 178.9 seconds because the
      overflow cannot be observed.
      
      Use clocks_calc_mult_shift(), which calculates the most accurate mult/shift
      pair based on the given clock frequency, and remove the bogus comment along
      with the divisions at the readout sites.
      
      Fixes: 5d890f59 ("ALSA: hda: support for wallclock timestamps")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/871r35kwji.ffs@tglxSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6dd21ad8
  9. 23 Nov, 2021 1 commit
  10. 20 Nov, 2021 1 commit
  11. 17 Nov, 2021 1 commit
  12. 16 Nov, 2021 8 commits
  13. 15 Nov, 2021 1 commit
  14. 14 Nov, 2021 8 commits