1. 09 Jun, 2021 5 commits
  2. 08 Jun, 2021 5 commits
  3. 07 Jun, 2021 9 commits
  4. 06 Jun, 2021 3 commits
  5. 05 Jun, 2021 5 commits
  6. 04 Jun, 2021 1 commit
  7. 03 Jun, 2021 2 commits
  8. 02 Jun, 2021 9 commits
  9. 01 Jun, 2021 1 commit
    • Takashi Sakamoto's avatar
      ALSA: bebob: perform sequence replay for media clock recovery · 1bd1b3be
      Takashi Sakamoto authored
      This commit takes ALSA bebob driver to perform sequence replay for media
      clock recovery.
      
      Many users have reported discontinuity of data block counter field of CIP
      header in tx packet from the devices based on BeBoB ASICs. In the worst
      case, the device corrupts not to respond to any transaction, then generate
      bus-reset voluntarily for recovery. The sequence replay for media clock
      recovery is expected to suppress most of the problems.
      
      In the beginning of packet streaming, the device transfers NODATA packets
      for a while, then multiplexes any event and syt information. ALSA
      IEC 61883-1/6 packet streaming engine has implementation for it to drop
      the initial NODATA packets. It starts sequence replay when detecting any
      event multiplexed to tx packets.
      
      The sequence replay is tested with below models:
      
       * Focusrite Saffire
       * Focusrite Saffire LE
       * Focusrite Saffire Pro 10 I/O
       * Focusrite Saffire Pro 26 I/O
       * M-Audio FireWire Solo
       * M-Audio FireWire Audiophile
       * M-Audio Ozonic
       * M-Audio FireWire 410
       * M-Audio FireWire 1814
       * Edirol FA-66
       * ESI Quatafire 610
       * Apogee Ensemble
       * Phonic Firefly 202
       * Behringer F-Control Audio 610
      
      Unfortunately, below models doesn't generate sound. This seems regression
      introduced recent few years:
      
       * Stanton Final Scratch ScratchAmp at middle sampling transfer frequency
       * Yamaha GO44
       * Yamaha GO46
       * Terratec Phase x24
      
      As I reported, below model has quirk of discontinuity:
      
       * M-Audio ProFire Lightbridge
      
      DM1000/DM1100 ASICs in BeBoB solution are known to have bugs at switch of
      sampling transfer frequency between low/middle/high rates. The switch
      generates the similar problems about which I mention in the above. Some
      vendors customizes firmware so that the switch of frequency is done in
      vendor-specific registers, then restrict users to switch the frequency.
      
      For example of Focusrite Saffire Pro 10 i/o and 26 i/o, users allows to
      switch the frequency within the three steps; e.g. 44.1/48.0 kHz are
      available at low step. Between the steps, extra operation is required and
      it always generates bus-reset.
      
      Another example of Edirol FA-66, users are prohibited to switch the
      frequency by software. It's done by hardware switch and power-off.
      
      I note that the sequence replay is not a solution for the ASIC bugs. Users
      need to disconnect the device corrupted by the bug, then reconnect it to
      refresh state machine inner the ASIC.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210601081753.9191-4-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1bd1b3be