1. 09 Jun, 2021 2 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 4 commits
    • 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
    • Takashi Sakamoto's avatar
      ALSA: dice: perform sequence replay for media clock recovery · 4121f626
      Takashi Sakamoto authored
      This commit takes ALSA dice driver to perform sequence replay for media
      clock recovery.
      
      Unlike the other types of device, DICE-based devices interpret the value
      of syt field of CIP header in rx packets as presentation time for audio
      playback, thus it's required for driver to compute value for outgoing
      packet adequate to the device. It's done by media clock recovery by
      handling tx packets.
      
      The device starts packet transmission immediately at operation to
      GLOBAL_ENABLE thus on-the-fly mode is not required.
      
      DICE ASICs supports several pairs of isochronous packet streams.
      Actually, maximum two pairs of streams are supported by devices.
      We have three cases regarding to the number of streams:
      
      1. a pair of streams
      2. two tx packet streams and one rx packet streams
      3. one tx packet streams and two rx packet streams
      4. two pair of streams
      
      The decision of playback timing is slightly different in the four cases.
      
      In the case 1, sequence replay in the pair results in suitable playback
      timing.
      
      In the case 2, sequence replay from the first tx packet stream to rx
      packet stream results in suitable playback timing.
      
      In the case 3, sequence replay from tx packet stream to all of rx packet
      stream results in suitable playback timing. Furthermore, the cycle to
      start receiving packets should be the same between all rx packet streams.
      
      In the case 4, sequence replay in each pair results in suitable playback
      timing. Furthermore, the cycle to start receiving packets should be the
      same between all rx packet streams.
      
      The sequence replay is tested with below models:
      
      * For case 1:
        * TC Electronic Konnekt 24d (DiceII)
        * TC Electronic Konnekt 8 (DiceII)
        * TC Electronic Konnekt Live (DiceII)
        * TC Electronic Impact Twin (DiceII)
        * TC Electronic Digital Konnekt X32 (DiceII)
        * TC Electronic Desktop Konnekt 6 (TCD2220)
        * Solid State Logic Duende Classic (DiceII)
        * Solid State Logic Duende Mini (DiceII)
        * PreSonus FireStudio Project (TCD2210)
        * PreSonus FireStudio Mobile (TCD2210)
        * Lexicon I-ONIX FW810s (TCD2220)
        * Avid Mbox 3 Pro (TCD2220)
      
      * For case 2 (but case 1 depends on sampling transfer frequency):
        * Alesis iO 26 (DiceII)
        * Alesis iO 14 (DiceII)
        * Alesis MultiMix 12 FireWire (DiceII)
        * Focusrite Saffire Pro 26 (TCD2220)
      
      * For case 3 (but case 1 depends on sampling transfer frequency):
        * M-Audio Profire 610 (TCD2220)
        * Loud Technology Mackie Onyx Blackbird (TCD2210)
      
      * For case 4:
        * TC Electronic Studio Konnekt 48 (DiceII + TCD2220)
        * PreSonus FireStudio (DiceII)
        * M-Audio Profire 2626 (TCD2220)
        * Focusrite Liquid Saffire 56 (TCD2220)
        * Focusrite Saffire Pro 40 (TCD2220)
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210601081753.9191-3-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4121f626
    • Takashi Sakamoto's avatar
      ALSA: dice: wait just for NOTIFY_CLOCK_ACCEPTED after GLOBAL_CLOCK_SELECT operation · 41319eb5
      Takashi Sakamoto authored
      NOTIFY_CLOCK_ACCEPTED notification is always generated as a result of
      GLOBAL_CLOCK_SELECT operation, however NOTIFY_LOCK_CHG notification
      doesn't, as long as the selected clock is already configured. In the case,
      ALSA dice driver waits so long. It's inconvenient for some devices to lock
      to the sequence of value in syt field of CIP header in rx packets.
      
      This commit wait just for NOTIFY_CLOCK_ACCEPTED notification by reverting
      changes partially done by two commits below:
      
       * commit fbeac84d ("ALSA: dice: old firmware optimization for Dice notification")
       * commit aec045b8 ("ALSA: dice: change notification mask to detect lock status change")
      
      I note that the successful lock to the sequence of value in syt field of
      CIP header in rx packets results in NOTIFY_EXT_STATUS notification, then
      EXT_STATUS_ARX1_LOCKED bit stands in GLOBAL_EXTENDED_STATUS register.
      The notification can occur enough after receiving the batch of rx packets.
      When the sequence doesn't include value in syt field of CIP header in rx
      packets adequate to the device, the notification occurs again and the bit
      is off.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Link: https://lore.kernel.org/r/20210601081753.9191-2-o-takashi@sakamocchi.jpSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      41319eb5
    • Carlos M's avatar
      ALSA: hda: Fix for mute key LED for HP Pavilion 15-CK0xx · 901be145
      Carlos M authored
      For the HP Pavilion 15-CK0xx, with audio subsystem ID 0x103c:0x841c,
      adding a line in patch_realtek.c to apply the ALC269_FIXUP_HP_MUTE_LED_MIC3
      fix activates the mute key LED.
      Signed-off-by: default avatarCarlos M <carlos.marr.pz@gmail.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210531202026.35427-1-carlos.marr.pz@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      901be145