1. 15 Oct, 2015 6 commits
  2. 13 Oct, 2015 4 commits
    • Ricard Wanderlof's avatar
      ALSA: usb-audio: Fix max packet size calculation for USB audio · ab30965d
      Ricard Wanderlof authored
      Rounding must take place before multiplication with the frame size, since
      each packet contains a whole number of frames.
      
      We must also properly consider the data interval, as a larger data
      interval will result in larger packets, which, depending on the sampling
      frequency, can result in packet sizes that are less than integral
      multiples of the packet size for a lower data interval.
      
      Detailed explanation and rationale:
      
      The code before this commit had the following expression on line 613 to
      calculate the maximum isochronous packet size:
      
      	maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3))
      			>> (16 - ep->datainterval);
      
      Here, ep->freqmax is the maximum assumed sample frequency, calculated from the
      nominal sample frequency plus 25%. It is ultimately derived from ep->freqn,
      which is in the units of frames per packet, from get_usb_full_speed_rate()
      or usb_high_speed_rate(), as applicable, in Q16.16 format.
      
      The expression essentially adds the Q16.16 equivalent of 0.999... (i.e.
      the largest number less than one) to the sample rate, in order to get a
      rate whose integer part is rounded up from the fractional value. The
      multiplication with (frame_bits >> 3) yields the number of bytes in a
      packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back
      to an integer, taking into consideration the bDataInterval field of the
      endpoint descriptor (which describes how often isochronous packets are
      transmitted relative to the (micro)frame rate (125us or 1ms, for USB high
      speed and full speed, respectively)). For this discussion we will initially
      assume a bDataInterval of 0, so the second line of the expression just
      converts the Q16.16 value to an integer.
      
      In order to illustrate the problem, we will set frame_bits 64, which
      corresponds to a frame size of 8 bytes.
      
      The problem here is twofold. First, the rounding operation consists
      of the addition of 0x0.ffff and subsequent conversion to integer, but as the
      expression stands, the conversion to integer is done after multiplication
      with the frame size, rather than before. This results in the resulting
      maxsize becoming too large.
      
      Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is
      0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000.
      The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 .
      However, if we do the number of bytes calculation in a less obscure way it's
      more apparent what the true corresponding packet size is: we get
      ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612,
      and the 8000 is the number of isochronous packets per second on a high
      speed USB connection (125 us microframe interval).
      
      This is fixed by performing the complete rounding operation prior to
      multiplication with the frame rate.
      
      The second problem is that when considering the ep->datainterval, this
      must be done before rounding, in order to take the advantage of the fact
      that if the number of bytes per packet is not an integer, the resulting
      rounded-up integer is not necessarily a factor of two when the data
      interval is increased by the same factor.
      
      For instance, assuming a freqency of 41 kHz, the resulting
      bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or
      0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0),
      this means that 6 frames per packet are needed, whereas with a data
      interval of 2 we need 10.25, i.e. 11 frames needed.
      
      Rephrasing the maxsize expression to:
      
      	maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) *
      			 (frame_bits >> 3);
      
      for the above 96 kHz example we instead get
      ((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value.
      
      We can also do the calculation with a non-integer sample rate which is when
      rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn =
      0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)):
      
      Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down)
      True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56
      New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56
      
      This is also corroborated by the wMaxPacketSize check on line 616. Assume
      that wMaxPacketSize = 104, with ep->maxpacksize then having the same value.
      As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to
      (104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize
      calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111
      (with decimals 111.99988). Clearly, we should get back the 104 here,
      which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 .
      
      (The error has not been a problem because it only results in maxsize being
      a bit too big which just wastes a couple of bytes, either as a result of
      the first maxsize calculation, or because the resulting calculation will
      hit the wMaxPacketSize value before the packet is too big, resulting in
      fixing the size to wMaxPacketSize even though the packet is actually not
      too long.)
      
      Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz.
      Signed-off-by: default avatarRicard Wanderlof <ricardw@axis.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ab30965d
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 3c69ea44
      Takashi Iwai authored
      3c69ea44
    • David Henningsson's avatar
      ALSA: hda - Fix inverted internal mic on Lenovo G50-80 · e8d65a8d
      David Henningsson authored
      Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo
      mic input where one channel has reverse polarity.
      
      Alsa-info available at:
      https://launchpadlibrarian.net/220846272/AlsaInfo.txt
      
      Cc: stable@vger.kernel.org
      BugLink: https://bugs.launchpad.net/bugs/1504778Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e8d65a8d
    • Vinod Koul's avatar
      ALSA: hdac: Explicitly add io.h · 42f2bb1c
      Vinod Koul authored
      Compiling the hdac extended core on arm fails with below error:
      
        sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel':
      >> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of
      >> function
      +'writel' [-Werror=implicit-function-declaration]
           writel(value, addr);
           ^
         sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl':
      >> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of
      >> function
      +'readl' [-Werror=implicit-function-declaration]
           return readl(addr);
      
      This is fixed by explicitly including io.h
      
      Fixes: 99463b3a - ('ALSA: hda: provide default bus io ops extended hdac')
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Suggested-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      42f2bb1c
  3. 12 Oct, 2015 5 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: change device probing processing · 53b3ffee
      Takashi Sakamoto authored
      Currently, this driver picks up model name with be32_to_cpu() macro
      to align characters. This is wrong operation because the result is
      different depending on CPU endiannness.
      
      Additionally, vendor released several versions of firmware for this
      series. It's not better to assign model-dependent information to
      device entry according to the version field.
      
      This commit fixes these bugs. The name of model is picked up correctly
      and used to identify model-dependent information.
      
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Fixes: c0949b27 ('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      53b3ffee
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: Turn on/off FireWire LED · e65e2cb9
      Takashi Sakamoto authored
      TASCAM FireWire series has some LEDs on its surface. These LEDs can be
      turned on/off by receiving asynchronous transactions to a certain
      address. One of the LEDs is labels as 'FireWire'. It's better to light it
      up when this driver starts to work. Besides, the LED for 'FireWire' is
      turned off at bus reset.
      
      This commit implements this idea.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e65e2cb9
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: add support for MIDI functionality · 0db18e7e
      Takashi Sakamoto authored
      In former commits, this driver got functionalities to transfer/receive
      MIDI messages to/from TASCAM FireWire series.
      
      This commit adds some ALSA MIDI ports to enable userspace applications
      to use the functionalities.
      
      I note that this commit doesn't support virtual MIDI ports which console
      models support. A physical controls can be assigned to a certain MIDI
      ports including physical and virtual. But the way is not clear.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0db18e7e
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: add support for outgoing MIDI messages by asynchronous transaction · 3beab0f8
      Takashi Sakamoto authored
      TASCAM FireWire series use asynchronous transaction to receive MIDI
      messages. The transaction should be sent to a certain address.
      
      This commit supports the outgoing MIDI messages. The messages in the
      transaction includes some quirks:
       * One MIDI message is transferred in one quadlet transaction, except for
         system exclusives.
       * MIDI running status is not allowed, thus transactions always include
         status byte.
       * The basic data format is the same as transferring MIDI messages
         supported in previous commit.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3beab0f8
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: add support for incoming MIDI messages by asynchronous transaction · 107cc012
      Takashi Sakamoto authored
      TASCAM FireWire series use asynchronous transaction to transfer MIDI
      messages. The transaction is sent to a registered address.
      
      This commit supports the incoming MIDI messages. The messages in the
      transaction include some quirks:
       * Two quadlets are used for one MIDI message and one timestamp.
       * Usually, the first byte of the first quadlet includes MIDI port and MSB
         4 bit of MIDI status. For system exclusive message, the first byte
         includes MIDI port and 0x04, or 0x07 in the end of the message.
       * The rest of the first quadlet includes MIDI bytes up to 3.
       * Several set of MIDI messages and timestamp can be transferred in one
         block transaction, up to 8 sets.
      
      I note that TASCAM FireWire series ignores ID bytes of system exclusive
      message. When receiving system exclusive messages with ID bytes on physical
      MIDI bus, the series transfers the messages without ID bytes on IEEE 1394
      bus, and vice versa.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      107cc012
  4. 11 Oct, 2015 9 commits
  5. 09 Oct, 2015 6 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: avoid endless loop to transfer MIDI messages at fatal error · bde3e288
      Takashi Sakamoto authored
      Currently, when asynchronous transactions finish in error state and
      retries, work scheduling and work running also continues. This
      should be canceled at fatal error because it can cause endless loop.
      
      This commit enables to cancel transferring MIDI messages when transactions
      encounter fatal errors. This is achieved by setting error state.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bde3e288
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add throttle for MIDI data rate · ea848b7b
      Takashi Sakamoto authored
      Typically, the target devices have internal buffer to adjust output of
      received MIDI messages for MIDI serial bus, while the capacity of the
      buffer is limited. IEEE 1394 transactions can transfer more MIDI messages
      than MIDI serial bus can. This can cause buffer over flow in device side.
      
      This commit adds throttle to limit MIDI data rate by counting intervals
      between two MIDI messages. Usual MIDI messages consists of two or three
      bytes. This requires 1.302 to 1.953 mili-seconds interval between these
      messages. This commit uses kernel monotonic time service to calculate the
      time of next transaction.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ea848b7b
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: schedule work again when MIDI substream has rest of MIDI messages · e8a40d9b
      Takashi Sakamoto authored
      Currently, when two MIDI trigger callbacks can be called immediately,
      transactions for the second MIDI messages can be postpone till next trigger
      callback. This is not good for real-time message transmission.
      
      This commit schedules work again at response handling callback if the
      MIDI substream still includes untransferred MIDI messages.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e8a40d9b
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add a restriction for a transaction at once · d3ef9cb9
      Takashi Sakamoto authored
      Currently, when waiting for a response, callers can start another
      transaction by scheduling another work. This is not good for error
      processing of transaction, especially the first response is too late.
      
      This commit serialize request/response transactions, by adding one
      boolean member to represent idling state.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d3ef9cb9
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add helper functions for asynchronous transactions to transfer MIDI messages · 585d7cba
      Takashi Sakamoto authored
      Some models receive MIDI messages via IEEE 1394 asynchronous transactions.
      In this case, MIDI messages are transferred in fixed-length payload. It's
      nice that firewire-lib module has common helper functions.
      
      This commit implements this idea. Each driver adds
      'struct snd_fw_async_midi_port' in its instance structure. In probing,
      it should call snd_fw_async_midi_port_init() to initialize the
      structure with some parameters such as target address, the length
      of payload in a transaction and a pointer for callback function
      to fill the payload buffer. At 'struct snd_rawmidi_ops.trigger()'
      callback, it should call 'snd_fw_async_midi_port_run()' to start
      transactions. Each driver should ensure that the lifetime of MIDI
      substream continues till calling 'snd_fw_async_midi_port_finish()'.
      
      The helper functions support retries to transferring MIDI messages when
      transmission errors occur. When transactions are successful, the helper
      functions call 'snd_rawmidi_transmit_ack()' internally to consume MIDI
      bytes in the buffer. Therefore, Each driver is expected to use
      'snd_rawmidi_transmit_peek()' to tell the number of bytes to transfer to
      return value of 'fill' callback.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      585d7cba
    • Kosuke Tatsukawa's avatar
      ALSA: seq_oss: fix waitqueue_active without memory barrier in snd-seq-oss · 69447027
      Kosuke Tatsukawa authored
      snd_seq_oss_readq_put_event() seems to be missing a memory barrier which
      might cause the waker to not notice the waiter and miss sending a
      wake_up as in the following figure.
      
          snd_seq_oss_readq_put_event		    snd_seq_oss_readq_wait
      ------------------------------------------------------------------------
      					/* wait_event_interruptible_timeout */
      					 /* __wait_event_interruptible_timeout */
      					  /* ___wait_event */
      					  for (;;) {									 prepare_to_wait_event(&wq, &__wait,
      					    state);
      spin_lock_irqsave(&q->lock, flags);
      if (waitqueue_active(&q->midi_sleep))
      /* The CPU might reorder the test for
         the waitqueue up here, before
         prior writes complete */
      					  if ((q->qlen>0 || q->head==q->tail)
      					  ...
      					  __ret = schedule_timeout(__ret)
      if (q->qlen >= q->maxlen - 1) {
      memcpy(&q->q[q->tail], ev, sizeof(*ev));
      q->tail = (q->tail + 1) % q->maxlen;
      q->qlen++;
      ------------------------------------------------------------------------
      
      There are two other place in sound/core/seq/oss/ which have similar
      code.  The attached patch removes the call to waitqueue_active() leaving
      just wake_up() behind.  This fixes the problem because the call to
      spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.
      
      I found this issue when I was looking through the linux source code
      for places calling waitqueue_active() before wake_up*(), but without
      preceding memory barriers, after sending a patch to fix a similar
      issue in drivers/tty/n_tty.c  (Details about the original issue can be
      found here: https://lkml.org/lkml/2015/9/28/849).
      Signed-off-by: default avatarKosuke Tatsukawa <tatsu@ab.jp.nec.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      69447027
  6. 08 Oct, 2015 2 commits
  7. 07 Oct, 2015 3 commits
  8. 06 Oct, 2015 2 commits
  9. 05 Oct, 2015 3 commits