Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 10月, 2015 1 次提交
  3. 13 10月, 2015 1 次提交
    • R
      ALSA: usb-audio: Fix max packet size calculation for USB audio · ab30965d
      由 Ricard Wanderlof 提交于 
      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: NRicard Wanderlof <ricardw@axis.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ab30965d
  5. 12 10月, 2015 1 次提交
  7. 28 9月, 2015 1 次提交
  9. 07 9月, 2015 1 次提交
    • J
      ALSA: usb-audio: Change internal PCM order · 5ee20bc7
      由 Johan Rastén 提交于 
      New PCMs will now be added to the end of the chip's PCM list instead of to the
front. This changes the way streams are combined so that the first capture
stream will now be merged with the first playback stream instead of the last.

This fixes a problem with ASUS U7. Cards with one playback stream and cards
without capture streams should be unaffected by this change.

Exception added for M-Audio Audiophile USB (tm) since it seems to have a fix to
swap capture stream numbering in alsa-lib conf/cards/USB-audio.conf
Signed-off-by: NJohan Rastén <johan@oljud.se>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      5ee20bc7
  11. 28 8月, 2015 1 次提交
  13. 26 8月, 2015 3 次提交
    • T
      ALSA: usb-audio: Handle normal and auto-suspend equally · 0662292a
      由 Takashi Iwai 提交于 
      In theory, the device may get suspended even at runtime PM suspend.
Currently we don't save the mixer state for autopm, and it may bring
inconsistency.

This patch removes the special handling for autosuspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0662292a
    • T
      ALSA: usb-audio: Replace probing flag with active refcount · a6da499b
      由 Takashi Iwai 提交于 
      We can use active refcount for preventing autopm during probe.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a6da499b
    • T
      ALSA: usb-audio: Avoid nested autoresume calls · 47ab1545
      由 Takashi Iwai 提交于 
      After the recent fix of runtime PM for USB-audio driver, we got a
lockdep warning like:

  =============================================
  [ INFO: possible recursive locking detected ]
  4.2.0-rc8+ #61 Not tainted
  ---------------------------------------------
  pulseaudio/980 is trying to acquire lock:
   (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]
  but task is already holding lock:
   (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio]

This comes from snd_usb_autoresume() invoking down_read() and it's
used in a nested way.  Although it's basically safe, per se (as these
are read locks), it's better to reduce such spurious warnings.

The read lock is needed to guarantee the execution of "shutdown"
(cleanup at disconnection) task after all concurrent tasks are
finished.  This can be implemented in another better way.

Also, the current check of chip->in_pm isn't good enough for
protecting the racy execution of multiple auto-resumes.

This patch rewrites the logic of snd_usb_autoresume() & co; namely,
- The recursive call of autopm is avoided by the new refcount,
  chip->active.  The chip->in_pm flag is removed accordingly.
- Instead of rwsem, another refcount, chip->usage_count, is introduced
  for tracking the period to delay the shutdown procedure.  At
  the last clear of this refcount, wake_up() to the shutdown waiter is
  called.
- The shutdown flag is replaced with shutdown atomic count; this is
  for reducing the lock.
- Two new helpers are introduced to simplify the management of these
  refcounts; snd_usb_lock_shutdown() increases the usage_count, checks
  the shutdown state, and does autoresume.  snd_usb_unlock_shutdown()
  does the opposite.  Most of mixer and other codes just need this,
  and simply returns an error if it receives an error from lock.

Fixes: 9003ebb1 ('ALSA: usb-audio: Fix runtime PM unbalance')
Reported-and-tested-by: NAlexnader Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      47ab1545
  15. 21 8月, 2015 1 次提交
  17. 20 8月, 2015 1 次提交
  19. 19 8月, 2015 1 次提交
    • T
      ALSA: usb-audio: Fix runtime PM unbalance · 9003ebb1
      由 Takashi Iwai 提交于 
      The fix for deadlock in PM in commit [1ee23fe0: ALSA: usb-audio:
Fix deadlocks at resuming] introduced a new check of in_pm flag.
However, the brainless patch author evaluated it in a wrong way
(logical AND instead of logical OR), thus usb_autopm_get_interface()
is wrongly called at probing, leading to unbalance of runtime PM
refcount.

This patch fixes it by correcting the logic.
Reported-by: NHans Yang <hansy@nvidia.com>
Fixes: 1ee23fe0 ('ALSA: usb-audio: Fix deadlocks at resuming')
Cc: <stable@vger.kernel.org> [v3.15+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      9003ebb1
  21. 16 8月, 2015 2 次提交
    • P
      ALSA: usb: handle descriptor with SYNC_NONE illegal value · 395ae54b
      由 Pierre-Louis Bossart 提交于 
      The M-Audio Transit exposes an interface with a SYNC_NONE attribute.
This is not a valid value according to the USB audio classspec. However
there is a sync endpoint associated to this record. Changing the logic to
try to use this sync endpoint allows for seamless transitions between
altset 2 and altset 3. If any errors happen, the behavior remains the same.

$ more /proc/asound/card1/stream0
M-Audio Transit USB at usb-0000:00:14.0-2, full speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 3 OUT (ADAPTIVE)
    Rates: 48001 - 96000 (continuous)
  Interface 1
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 3 OUT (NONE)
    Rates: 8000 - 48000 (continuous)
  Interface 1
    Altset 3
    Format: S16_LE
    Channels: 2
    Endpoint: 3 OUT (ASYNC)
    Rates: 8000 - 48000 (continuous)
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      395ae54b
    • P
      ALSA: usb: fix corrupted pointers due to interface setting change · 63018447
      由 Pierre-Louis Bossart 提交于 
      When a transition occurs between alternate settings that do not use the
same synchronization method, the substream pointers were not reset.
This prevents audio from being played during the second transition.

Identified and tested with M-Audio Transit device
(0763:2006 Midiman M-Audio Transit)

Details of the issue:

First playback to adaptive endpoint:
$ aplay -Dhw:1,0 ~/24_96.wav
Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
Rate 96000 Hz, Stereo

[ 3169.297556] usb 1-2: setting usb interface 1:1
[ 3169.297568] usb 1-2: Creating new playback data endpoint #3
[ 3169.298563] usb 1-2: Setting params for ep #3 (type 0, 3 urbs), ret=0
[ 3169.298574] usb 1-2: Starting data EP @ffff880035fc8000

first playback to asynchronous endpoint:
$ aplay -Dhw:1,0 ~/16_48.wav
Playing WAVE '/home/plb/16_48.wav' : Signed 16 bit Little Endian,
Rate 48000 Hz, Stereo

[ 3204.520251] usb 1-2: setting usb interface 1:3
[ 3204.520264] usb 1-2: Creating new playback data endpoint #3
[ 3204.520272] usb 1-2: Creating new capture sync endpoint #83
[ 3204.521162] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
[ 3204.521177] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0
[ 3204.521182] usb 1-2: Starting data EP @ffff880035fce000
[ 3204.521204] usb 1-2: Starting sync EP @ffff8800bd616000

second playback to adaptive endpoint: no audio and error on terminal:
$ aplay -Dhw:1,0 ~/24_96.wav
Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
Rate 96000 Hz, Stereo
aplay: pcm_write:1939: write error: Input/output error

[ 3239.483589] usb 1-2: setting usb interface 1:1
[ 3239.483601] usb 1-2: Re-using EP 3 in iface 1,1 @ffff880035fc8000
[ 3239.484590] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
[ 3239.484606] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0

This last line shows that a sync endpoint is used when it shouldn't.
The sync endpoint is no longer valid and the pointers are corrupted
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      63018447
  23. 14 8月, 2015 1 次提交
  25. 29 7月, 2015 1 次提交
  27. 14 7月, 2015 1 次提交
  29. 01 7月, 2015 1 次提交
  31. 11 6月, 2015 1 次提交
  33. 08 6月, 2015 1 次提交
  35. 03 6月, 2015 2 次提交
  37. 30 5月, 2015 1 次提交
  39. 29 5月, 2015 1 次提交
  41. 26 5月, 2015 1 次提交
  43. 24 5月, 2015 1 次提交
  45. 19 5月, 2015 1 次提交
  47. 21 4月, 2015 1 次提交
    • T
      ALSA: usb-audio: Fix audio output on Roland SC-D70 sound module · 6d1f2f60
      由 Takamichi Horikawa 提交于 
      Roland SC-D70 reports its device class as vendor specific class and
the quirk QUIRK_AUDIO_FIXED_ENDPOINT was used for audio output.

In the quirks table the sampling rate was hard-coded to 44100 Hz
and therefore not worked when the sound module was in 48000 Hz mode.

In this change the quirk is changed to QUIRK_AUDIO_STANDARD_INTERFACE
but as the sound module reports incorrect bSubframeSize in its
descriptors, additional change is made in format.c to detect it and
to override it (which uses the existing code for Edirol SD-90).

Tested both when the sound module was in 44100 Hz mode and 48000 Hz
mode and both audio input and output. MIDI related part of the driver
is not touched.
Signed-off-by: NTakamichi Horikawa <takamichiho@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      6d1f2f60
  49. 12 4月, 2015 1 次提交
  51. 09 4月, 2015 1 次提交
  53. 04 4月, 2015 1 次提交
  55. 12 3月, 2015 1 次提交
  57. 05 3月, 2015 1 次提交
  59. 04 3月, 2015 1 次提交
  61. 18 2月, 2015 1 次提交
  63. 17 2月, 2015 1 次提交
    • J
      ALSA: usb-audio: Don't attempt to get Lifecam HD-5000 sample rate · b62b9980
      由 Joe Turner 提交于 
      Adds a quirk to disable the check that the sample rate has been set correctly, as the Lifecam does not support getting the sample rate.

This means that we don't need to wait for the USB timeout when attempting to get the sample rate. Waiting for the timeout causes problems in some applications, which give up on the device acquisition process before it has had time to complete, resulting in no sound.

[minor tidy up by tiwai]
Signed-off-by: NJoe Turner <joe@oampo.co.uk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b62b9980
  65. 12 2月, 2015 1 次提交
  67. 11 2月, 2015 3 次提交