1. 19 Oct, 2015 13 commits
  2. 18 Oct, 2015 2 commits
  3. 17 Oct, 2015 5 commits
  4. 16 Oct, 2015 2 commits
  5. 15 Oct, 2015 6 commits
  6. 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/1504778
      
      Signed-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
  7. 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
  8. 11 Oct, 2015 3 commits