1. 28 May, 2021 4 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: support NO_PERIOD_WAKEUP in ALSA PCM runtime · d360870a
      Takashi Sakamoto authored
      Drivers of ALSA firewire stack can process packets for IT/IR context in
      process context when the process operates ALSA PCM character device by
      calling ioctl(2) with some requests. The ioctl requests are:
      
       * SNDRV_PCM_IOCTL_HWSYNC
       * SNDRV_PCM_IOCTL_SYNC_PTR
       * SNDRV_PCM_IOCTL_REWIND
       * SNDRV_PCM_IOCTL_FORWARD
       * SNDRV_PCM_IOCTL_WRITEI_FRAMES
       * SNDRV_PCM_IOCTL_READI_FRAMES
       * SNDRV_PCM_IOCTL_WRITEN_FRAMES
       * SNDRV_PCM_IOCTL_READN_FRAMES
      
      This means that general application can process PCM frames apart from
      hardware IRQ invocation, even if they are programmed by either IRQ-based
      scheduling model or Timer-based scheduling model.
      
      This commit add support for Timer-based scheduling model by allowing
      PCM runtime to suppress both process wakeup per period and scheduling
      hardware IRQ.
      
      SNDRV_PCM_INFO_BATCH is obsoleted since ALSA IEC 61883-1/6 packet streaming
      engine can report the number of transferred PCM frames within PCM period
      boundary. The granularity equals to SYT_INTERVAL in blocking transmission.
      In non-blocking transmission, it doesn't equal to SYT_INTERVAL but doesn't
      exceed.
      
      This patch is tested with PulseAudio, and --sched-model option of axfer
      with fix against the issue reported at:
      
       * https://lore.kernel.org/alsa-devel/687f9871-7484-1370-04d1-9c968e86f72b@linux.intel.com/#rSigned-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210527123253.174315-1-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d360870a
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: transfer rx packets on-the-fly when replaying · 2f21a177
      Takashi Sakamoto authored
      Models in below series start transmission of packet after receiving the
      sequence of packets:
      
       * Digidesign Digi00x family
       * RME Fireface series
      
      Additionally, models in Tascam FireWire series start multiplexing PCM
      frames into packets enough after receiving packets. It's required to
      transfer packets on-the-fly for the above models according to nominal
      sampling transfer frequency before starting sequence replay.
      
      This commit allows drivers to decide whether the engine transfers packet
      on-the-fly or not.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2f21a177
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: replay sequence of incoming packets for outgoing packets · 39c2649c
      Takashi Sakamoto authored
      ALSA IEC 61883-1/6 packet streaming engine uses pre-computed parameters
      ideal for nominal sampling transfer frequency (STF) to transfer packets
      to device since it was added 2011. As a result of user experience for a
      decade, it is clear that the sequence is not suitable to some actual
      devices. It takes the devices to generate noise, and causes any type of
      discontinuity in the series of packet transferred from the device. It's
      required for the engine to transfer packets according to effective STF.
      
      The effective STF is given by media clock recovered by the sequence of
      packet transferred from the target device. In the previous commit, the
      sequence is already cached. The media clock recovery can be achieved by
      analyzing the sequence.
      
      In technological world, many ideas are proposed for media clock recovery.
      However, the small part of them could be actually adopted in our case
      since floating point arithmetic is not mostly available in Linux kernel
      land.
      
      This commit adopts the simple way from them; sequence replay, which means
      that the sequence of parameters from incoming packet is used as is to
      transfer outgoing packets. The media clock is not computed internally,
      but the sequence of outgoing packet superficially looks to be generated by
      the media clock.
      
      The association between source and destination is decided when starting
      AMDTP domain. When the target device supports a pair of isochronous packet
      streams, the tx stream is source and the rx stream is destination. When it
      supports two pair of streams, each of tx stream is associated to
      corresponding rx stream in its order. When it supports less number of tx
      streams than rx streams, the fist tx stream is selected for all of rx
      streams. When it supports more tx streams than rx streams, the first tx
      packet is associated to the rx stream.
      
      As I noted in previous commit, the sequence of parameters from incoming
      packet is different between devices, time to time. It is worse idea to
      replay the sequence of parameters from a device for the sequence of
      packet to the other devices even if they are in the same category of
      device.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210527122611.173711-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      39c2649c
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add replay target to cache sequence of packet · f9e5ecdf
      Takashi Sakamoto authored
      In design of audio and music unit in IEEE 1394 bus, feedback of
      effective sampling transfer frequency (STF) is delivered by packets
      transferred from device. The devices supported by ALSA firewire stack
      are categorized to three groups regarding to it.
      
       * Group 1:
         * Echo Audio Fireworks board module
         * Oxford Semiconductor OXFW971 ASIC
         * Digidesign Digi00x family
         * Tascam FireWire series
         * RME Fireface series
      
       * Group 2:
         * BridgeCo. DM1000/DM1100/DM1500 ASICs for BeBoB solution
         * TC Applied Technologies DICE ASICs
      
       * Group 3:
         * Mark of the Unicord FireWire series
      
      In group 1, the effective STF is determined by the sequence of the number
      of events per packet. In group 2, the sequence of presentation timestamp
      expressed in syt field of CIP header is interpreted as well. In group 3,
      the presentation timestamp is expressed in source packet header (SPH) of
      each data block.
      
      I note that some models doesn't take care of effective STF with large
      internal buffer. It's reasonable to name it as group 0:
      
       * Group 0
         * Oxford Semiconductor OXFW970 ASIC
      
      The effective STF is known to be slightly different from nominal STF for
      all of devices, and to be different between the devices. Furthermore, the
      effective STF is known to be shifted for long-period transmission. This
      makes it hard for software to satisfy the effective STF when processing
      packets to the device.
      
      The effective STF is deterministic as a result of analyzing the batch of
      packet transferred from the device. For the analysis, caching the sequence
      of parameter in the packet is required.
      
      This commit adds an option so that AMDTP domain structure takes AMDTP
      stream structure to cache the sequence of parameters in packet transferred
      from the device. The parameters are offset ticks of syt field against the
      cycle to receive the packet and the number of data blocks per packet.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f9e5ecdf
  2. 27 May, 2021 4 commits
  3. 25 May, 2021 15 commits
  4. 22 May, 2021 7 commits
  5. 21 May, 2021 1 commit
  6. 20 May, 2021 8 commits
  7. 19 May, 2021 1 commit