1. 12 Jun, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: pcm: add 'applptr' event of tracepoint · fccf5388
      Takashi Sakamoto authored
      In design of ALSA PCM core, status and control data for runtime of ALSA
      PCM substream are shared between kernel/user spaces by page frame
      mapping with read-only attribute. Both of hardware-side and
      application-side position on PCM buffer are maintained as a part of
      the status data. In a view of ALSA PCM application, these two positions
      can be updated by executing ioctl(2) with some commands.
      
      There's an event of tracepoint for hardware-side position; 'hwptr'.
      On the other hand, no events for application-side position. This commit
      adds a new event for this purpose; 'applptr'. When the application-side
      position is changed in kernel space, this event is probed with useful
      information for developers.
      
      I note that the event is not probed for all of ALSA PCM applications, When
      applications are written by read/write programming scenario, the event is
      surely probed. The applications execute ioctl(2) with
      SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then
      ALSA PCM core updates the application-side position in kernel land.
      However, when applications are written by mmap programming scenario, if
      maintaining the application side position in kernel space accurately,
      applications should voluntarily execute ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If
      not voluntarily, the application-side position is not changed, thus the
      added event is not probed.
      
      There's a loophole, using architectures to which ALSA PCM core judges
      non cache coherent. In this case, the status and control data is not mapped
      into processe's VMA for any applications. Userland library, alsa-lib, is
      programmed for this case. It executes ioctl(2) with
      SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and
      control data.
      
      ARM is such an architecture. Below is an example with serial sound interface
      (ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community
      with patches from VIA Tech. Inc. for VAB820, and my backport patches for
      relevant features for this patchset. I use Ubuntu 17.04 from
      ports.ubuntu.com as user land for armhf architecture.
      
      $ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256
      Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
      Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0
      Its setup is:
        stream       : PLAYBACK
        access       : MMAP_INTERLEAVED
        format       : S16_LE
        subformat    : STD
        channels     : 1
        rate         : 48000
        exact rate   : 48000 (48000/1)
        msbits       : 16
        buffer_size  : 256
        period_size  : 128
        period_time  : 2666
        tstamp_mode  : NONE
        tstamp_type  : MONOTONIC
        period_step  : 1
        avail_min    : 128
        period_event : 0
        start_threshold  : 256
        stop_threshold   : 256
        silence_threshold: 0
        silence_size : 0
        boundary     : 1073741824
        appl_ptr     : 0
        hw_ptr       : 0
      mmap_area[0] = 0x76f98000,0,16 (16)
      
      $ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr
      $ trace-cmd report
      ...
      60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
      60.210022: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256
      60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210344: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
      60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256
      60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211142: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
      60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
      60.212690: hwptr:   pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256
      60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.212999: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
      60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256
      60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213796: hwptr:   pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
      60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
      60.215356: hwptr:   pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256
      60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215679: hwptr:   pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256
      60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
      60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256
      ...
      
      We can surely see 'applptr' event is probed even if the application run
      for mmap programming scenario ('-M' option and 'hw' plugin). Below is a
      result of strace:
      
      02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.888132 read(3, "..."..., 256) = 256
      02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891228 read(3, "..."..., 256) = 256
      02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
      02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
      
      We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with
      call of poll(2). 128 PCM frames are transferred per loop of one poll(2),
      because the PCM substream is configured with S16_LE format and 1 channel
      (2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM
      buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is
      actually used to commit the number of copied PCM frames to kernel space.
      The other calls are just used to check runtime status of PCM substream;
      e.g. XRUN.
      
      The tracepoint event is useful to investigate this case. I note that below
      modules are related to the above sample.
      
       * snd-soc-dummy.ko
       * snd-soc-imx-sgtl5000.ko
       * snd-soc-fsl-ssi.ko
       * snd-soc-imx-pcm-dma.ko
       * snd-soc-sgtl5000.ko
      
      My additional note is lock acquisition. The event is probed under acquiring
      PCM stream lock. This means that calculation in the event is free from
      any hardware events.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fccf5388
    • Takashi Sakamoto's avatar
      ALSA: pcm: unify codes to operate application-side position on PCM buffer · 66e01a5c
      Takashi Sakamoto authored
      In a series of recent work, ALSA PCM core got some arrangements to handle
      application-side position on PCM buffer. However, relevant codes still
      disperse to two translation units
      
      This commit unifies these codes into a helper function.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      66e01a5c
  2. 11 Jun, 2017 2 commits
  3. 09 Jun, 2017 36 commits