Skip to content

L
linux
Switch branch/tag
  1. 19 Oct, 2015 6 commits
  3. 18 Oct, 2015 2 commits
  5. 17 Oct, 2015 5 commits
  7. 16 Oct, 2015 2 commits
  9. 15 Oct, 2015 6 commits
  11. 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
  13. 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
  15. 11 Oct, 2015 9 commits
  17. 09 Oct, 2015 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7