Power Domains in the UAC3 spec are mainly intended to be
associated to an Input or Output Terminal so the host
changes the power state of the entire capture or playback
path within the topology.

This patch adds support for finding Power Domains associated
to an Audio Streaming Interface (bTerminalLink) and adds a
reference to them in the usb audio substreams (snd_usb_substream).
Signed-off-by: NJorge Sanjuan <jorge.sanjuan@codethink.co.uk>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add new mostly generic code with Mytek VID to support native DSD mode.

This implementation should be easier to maintain when manufacturers
release new products.
Signed-off-by: NJussi Laako <jussi@sonarnerd.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Recently released USB Audio Class 3.0 specification
introduces many significant changes comparing to
previous versions, like
 - new Power Domains, support for LPM/L1
 - new Cluster descriptor
 - changed layout of all class-specific descriptors
 - new High Capability descriptors
 - New class-specific String descriptors
 - new and removed units
 - additional sources for interrupts
 - removed Type II Audio Data Formats
 - ... and many other things (check spec)

It also provides backward compatibility through
multiple configurations, as well as requires
mandatory support for BADD (Basic Audio Device
Definition) on each ADC3.0 compliant device

This patch adds initial support of UAC3 specification
that is enough for Generic I/O Profile (BAOF, BAIF)
device support from BADD document.
Signed-off-by: NRuslan Bilovol <ruslan.bilovol@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The quirk seems to be necessary not only for TEAC UD-H01 devices, but to
more that are based on the Tenor 8802TL chipset. Devices built by T+A
are affected too, and they apparently all use the same USB PID:PID.

Extend the quirky handling for that device as well, and rename the
quirks flag.
Reported-and-tested-by: NThomas Gresens <T.Gresens@intershop.de>
Signed-off-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unfortunately, this patch caused several regressions at au0828 and
snd-usb-audio, like this one:
	https://bugzilla.kernel.org/show_bug.cgi?id=115561

It also showed several troubles at the MC core that handles pretty
poorly the memory protections and data lifetime management.

So, better to revert it and fix the core before reapplying this
change.

This reverts commit aebb2b89 ("[media] sound/usb: Use Media
Controller API to share media resources")'
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Change ALSA driver to use Media Controller API to share media resources
with DVB and V4L2 drivers on a AU0828 media device. Media Controller
specific initialization is done after sound card is registered. ALSA
creates Media interface and entity function graph nodes for Control,
Mixer, PCM Playback, and PCM Capture devices.

snd_usb_hw_params() will call Media Controller enable source handler
interface to request the media resource. If resource request is
granted, it will release it from snd_usb_hw_free(). If resource is
busy, -EBUSY is returned.

Media specific cleanup is done in usb_audio_disconnect().
Signed-off-by: NShuah Khan <shuahkh@osg.samsung.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The Zoom R16/24 have a nonstandard playback format where each isochronous
packet contains a length descriptor in the first four bytes. (Curiously,
capture data does not contain this and requires no quirk.)

The quirk involves adding the extra length descriptor whenever outgoing
isochronous packets are generated, both in pcm.c (outgoing audio) and
endpoint.c (silent data).

In order to make the quirk as unintrusive as possible, for
pcm.c:prepare_playback_urb(), the isochronous packet descriptors are
initially set up in the same way no matter if the quirk is enabled or not.
Once it is time to actually copy the data into the outgoing packet buffer
(together with the added length descriptors) the isochronous descriptors
are adjusted in order take the increased payload length into account.

For endpoint.c:prepare_silent_urb() it makes more sense to modify the
actual function, partly because the function is less complex to start with
and partly because it is not as time-critical as prepare_playback_urb()
(whose bulk is run with interrupts disabled), so the (minute) additional
time spent in the non-quirk case is motivated by the simplicity of having
a single function for all cases.

The quirk is controlled by the new tx_length_quirk member in struct
snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c
and endpoint.c from quirks.c in a similar manner to the txfr_quirk member
in the same structs.

In contrast to txfr_quirk however, the quirk is enabled directly in
quirks.c:create_standard_audio_quirk() by checking the USB ID in that
function. Another option would be to introduce a new
QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk
very plain to see in the quirk table, but it was felt that the additional
code needed to implement it this way would just make the implementation
more complex with no real gain.

Tested with a Zoom R16, both by doing capture and playback separately
using arecord and aplay (8 channel capture and 2 channel playback,
respectively), as well as capture and playback together using Ardour, as
well as Audacity and Qtractor together with jackd.

The R24 is reportedly compatible with the R16 when used as an audio
interface. Both devices share the same USB ID and have the same number of
inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the
patch.

Regression tested using an Edirol UA-5 in both class compliant (16-bit)
and "advanced" (24 bit, forces the use of quirks) modes.
Signed-off-by: NRicard Wanderlof <ricardw@axis.com>
Tested-by: NPanu Matilainen <pmatilai@laiskiainen.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The first URBs are submitted during the prepare stage. When .trigger is
called, the ALSA core saves a trigger tstamp that doesn't correspond to
the actual time when the samples are submitted. The trigger_tstamp is
now updated when the first data are submitted to avoid any time offsets.

A usb-specific trigger_tstamp_pending_update flag is used for now,
at some point the flag would need to move to the ALSA core, USB
is not the only interface where silent block transfers are programmed
as part of the prepare stage, with actual data enabled when .trigger
is called.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The TEAC UD-H01 firmware sends wrong feedback frequency values, thus
causing the PC to send the samples at a wrong rate, which results in
clicks and crackles in the output.

Add a workaround to detect and fix the corruption.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
[mick37@gmx.de: use sender->udh01_fb_quirk rather than
 ep->udh01_fb_quirk in snd_usb_handle_sync_urb()]
Reported-and-tested-by: NMick <mick37@gmx.de>
Reported-and-tested-by: NAndrea Messa <andr.messa@tiscali.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

As Clemens Ladisch kindly explained:
 "Please note that there are two methods to identify alternate settings:
  the number, which is the value in bAlternateSetting, and the index,
  which is the index in the descriptor array.  There might be some wording
  in the USB spec that these two values must be the same, but in reality,
  [insert standard rant about firmware writers], bAlternateSetting
  must be treated as a random ID value."

This patch changes the name to express the correct usage semantics.
No functional change.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver.  Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur.  This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.

The patch allocates as many URBs as possible, subject to four
limitations:

	The total number of URBs for the endpoint is not allowed to
	exceed MAX_URBS (which the patch increases from 8 to 12).

	The total number of packets per URB is not allowed to exceed
	MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
	decreased from 20 to 6.

	The total duration of queued data is not allowed to exceed
	MAX_QUEUE, which is decreased from 24 ms to 18 ms.

	The total number of ALSA frames in the output queue is not
	allowed to exceed the ALSA buffer size.

The last requirement is the hardest to implement.  Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate.  To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain.  Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames.  As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.

The overall effect of the patch is that playback works better in
low-latency settings.  The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course.  But for values that are within those
capabilities, the performance will be improved.  For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.

A side effect of these changes is that the "nrpacks" module parameter
is no longer used.  The patch removes it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: NDaniel Mack <zonque@gmail.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Instead of reading bInterfaceProtocol from the descriptor whenever it's
needed, store this value in the audioformat structure.  Besides
simplifying some code, this will allow us to correctly handle vendor-
specific devices where the descriptors are marked with other values.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>

There is quite some confusion around the bit-ordering in DSD samples,
and no general agreement that defines whether hardware is supposed to
expect the oldest sample in the MSB or the LSB of a byte.

ALSA will hence set the rule that on the software API layer, bytes
always carry the oldest bit in the most significant bit of a byte, and
the driver has to translate that at runtime in order to match the
hardware layout.

This patch adds support for this by adding a boolean flag to the
audio format struct.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In order to provide a compatibility way for pushing DSD
samples through ordinary PCM channels, the "DoP open Standard" was
invented. See http://www.dsd-guide.com for the official document.

The host is required to stuff DSD marker bytes (0x05, 0xfa,
alternating) in the MSB of 24 bit wide samples on the bus, in addition
to the 16 bits of actual DSD sample payload.

To support this, the hardware and software stride logic in the driver
has to be tweaked a bit, as we make the userspace believe we're
operating on 16 bit samples, while we in fact push one more byte per
channel down to the hardware.

The DOP runtime information is stored in struct snd_usb_substream, so
we can keep track of our state across multiple calls to
prepare_playback_urb_dsd_dop().
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When recording at 176.2KHz or 192Khz, the device adds a 32-bit length
header to the capture packets, which obviously needs to be ignored for
recording to work properly.

Userspace expected:  L0 L1 L2 R0 R1 R2
...but actually got: R2 L0 L1 L2 R0 R1

Also, the last byte of the length header being interpreted as L0 of
the first sample caused spikes every 0.5ms, resulting in a loud 16KHz
tone (about the highest 'B' on a piano) being present throughout
captures.

Tested at all sample rates on an E-Mu 0404USB, and tested for
regressions on a generic USB headset.
Signed-off-by: NCalvin Owens <jcalvinowens@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add the support for channel maps of the PCM streams on USB audio
devices.  The channel map information is already found in
ChannelConfig descriptor entries, which haven't been referred until
now.

Each chmap entry is added to audioformat list entry and copied to TLV
dynamically instead of creating a whole chmap array.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Close some races at disconnection of a USB audio device by adding the
chip->shutdown_mutex and chip->shutdown check at appropriate places.

The spots to put bandaids are:
- PCM prepare, hw_params and hw_free
- where the usb device is accessed for communication or get speed, in
 mixer.c and others; the device speed is now cached in subs->speed
 instead of accessing to chip->dev

The accesses in PCM open and close don't need the mutex protection
because these are already handled in the core PCM disconnection code.

The autosuspend/autoresume codes are still uncovered by this patch
because of possible mutex deadlocks.  They'll be covered by the
upcoming change to rwsem.

Also the mixer codes are untouched, too.  These will be fixed in
another patch, too.
Reported-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The recent fix for USB suspend breakage moved the code to set up EP
from hw_params to prepare, but it means also the EP setup might be
called multiple times unnecessarily because the prepare callback can
be called multiple times without starting the stream (e.g. OSS
emulation).

This patch adds a new flag to struct snd_usb_substream indicating
whether the setup of EP is required, and do it only when necessary,
i.e. right after hw_params or suspend.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move interface and endpoint configuration from hw_params to prepare
callback.  During system suspend/resume when the USB device power isn't
cycled the interface and endpoint configuration need to be set before
audio playback can continue.  Resume involves another call to prepare
but not to hw_params, moving it here allows a playing stream to continue
after resume.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Playback Designs' USB devices have some hardware limitations on their
USB interface. In particular:

 - They need a 20ms delay after each class compliant request as the
   hardware ACKs the USB packets before the device is actually ready
   for the next command. Sending data immediately will result in buffer
   overflows in the hardware.
 - The devices send bogus feedback data at the start of each stream
   which confuse the feedback format auto-detection.

This patch introduces a new quirks hook that is called after each
control packet and which adds a delay for all devices that match
Playback Designs' USB VID for now.

In addition, it adds a counter to snd_usb_endpoint to drop received
packets on the floor. Another new quirks function that is called once
an endpoint is started initializes that counter for these devices on
their sync endpoint.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Reported-and-tested-by: NAndreas Koch <andreas@akdesigninc.com>
Supported-by: NDemian Martin <demianm_1@yahoo.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The two entries are duplicated in struct snd_usb_endpoint.
Seems forgotten in the last clean-up.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In 3.5 kernel, the endpoint is assigned dynamically for the
substreams, but the PCM assignment still checks the presence of the
endpoint pointer.  This ended up in duplicated PCM substream creations
at probing time, resulting in kernel warnings like:

WARNING: at fs/proc/generic.c:586 proc_register+0x169/0x1a6()
Pid: 1152, comm: modprobe Not tainted 3.5.0-rc1-00110-g71fae7e7 #2
Call Trace:
 [<ffffffff8102a400>] warn_slowpath_common+0x83/0x9c
 [<ffffffff8102a4bc>] warn_slowpath_fmt+0x46/0x48
 [<ffffffff813829ad>] ? add_preempt_count+0x39/0x3b
 [<ffffffff811292f0>] proc_register+0x169/0x1a6
 [<ffffffff8112962e>] create_proc_entry+0x74/0x8c
 [<ffffffffa018eb63>] snd_info_register+0x3e/0xc3 [snd]
 [<ffffffffa01fde2e>] snd_pcm_new_stream+0xb1/0x404 [snd_pcm]
 [<ffffffffa024861f>] snd_usb_add_audio_stream+0xd2/0x230 [snd_usb_audio]
 [<ffffffffa0241d33>] ? snd_usb_parse_audio_format+0x252/0x34f [snd_usb_audio]
 [<ffffffff810d6b17>] ? kmem_cache_alloc_trace+0xab/0xbb
 [<ffffffffa0248c29>] snd_usb_parse_audio_interface+0x4ac/0x567 [snd_usb_audio]
 [<ffffffffa023f0ff>] snd_usb_create_stream+0xe9/0x125 [snd_usb_audio]
 [<ffffffffa023f9b1>] usb_audio_probe+0x62a/0x72c [snd_usb_audio]
 .....

This patch fixes the regression by checking the fixed endpoint number
for each substream instead of the endpoint pointer.
Reported-and-tested-by: NJamie Heilman <jamie@audible.transient.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Drop some struct members and definitions that became obsolete during
the refactorization of the driver.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Many fields have been moved to struct snd_usb_endpoint.
Also fix the proc output to correspond to the new structure.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

With the previous commit that added the new streaming model, all
endpoint and streaming related code is now in endpoint.c, and pcm.c
only acts as a wrapper for handling the packet's payload.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch adds a new generic streaming logic for audio over USB.

It defines a model (snd_usb_endpoint) that handles everything that
is related to an USB endpoint and its streaming. There are functions to
activate and deactivate an endpoint (which call usb_set_interface()),
and to start and stop its URBs. It also has function pointers to be
called when data was received or is about to be sent, and pointer to
a sync slave (another snd_usb_endpoint) that is informed when data has
been received.

A snd_usb_endpoint knows about its state and implements a refcounting,
so only the first user will actually start the URBs and only the last
one to stop it will tear them down again.

With this sort of abstraction, the actual streaming is decoupled from
the pcm handling, which makes the "implicit feedback" mechanisms easy to
implement.

In order to split changes properly, this patch only adds the new
implementation but leaves the old one around, so the the driver doesn't
change its behaviour. The switch to actually use the new code is
submitted separately.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

A malicious USB device could feed in a large nr_rates value.  This would
cause the subsequent call to kmemdup() to allocate a smaller buffer than
expected, leading to out-of-bounds access.

This patch validates the nr_rates value and reuses the limit introduced
in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow
in parse_uac2_sample_rate_range()").
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Existing code only updates the audio delay when URBs were
submitted/retired. This can introduce an uncertainty of 8ms
on the number of samples played out with the default settings,
and a lot more when URBs convey more packets to reduce the
interrupt rate and power consumption.

This patch relies on the USB frame counter to reduce the
uncertainty to less than 2ms worst-case. The delay information
essentially becomes independent of the URB size and number of
packets. This should help applications like PulseAudio which
require accurate audio timing. Clemens Ladisch reported
a decrease of mplayer's A-V difference from nrpacks down to at
most 1ms.

Thanks to Clemens for also pointing out that the implementation
of frame counters varies between different HCDs. Only the
8 lowest-bits are used to estimate the delay.
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
[clemens: changed debug code]
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are two USB Audio Class specifications (v1 and v2), but neither of
them clearly defines the feedback format for high-speed UAC v1 devices.
Add to this whatever the Creative and M-Audio firmware writers have been
smoking, and it becomes impossible to predict the exact feedback format
used by a particular device.

Therefore, automatically detect the feedback format by looking at the
magnitude of the first received feedback value.

Also, this allows us to get rid of some special cases for E-Mu devices.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Audio devices which comply to the UAC2 standard can export complex clock
topologies in its descriptors and set up links between them.

The entities that are defined are

 - clock sources, which define the end-leafs.
 - clock selectors, which act as switch to select one out of many
   possible clocks sources.
 - clock multipliers, which have an input clock source, and act as clock
   source again. They can be used to derive one clock from another.

All sample rate changes, clock validity queries and the like must go to
clock source elements, while clock selectors and multipliers can be used
as terminal clock source.

The following patch adds a parser for these elements and functions to
iterate over the tree and find the leaf nodes (clock sources).

The samplerate set functions were moved to the new clock.c file.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In preparation for USB audio 2.0 support, change the audioformat
structure so that it uses a bitmask to specify possible formats.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The snd_usb_substream::format field actually contains the index of the
current alternate setting, so rename it to altset_idx to avoid
confusion.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Clean up the usb audio driver by factoring out a lot of functions to
separate files. Code for procfs, quirks, urbs, format parsers etc all
got a new home now.

Moved almost all special quirk handling to quirks.c and introduced new
generic functions to handle them, so the exceptions do not pollute the
whole driver.

Renamed usbaudio.c to card.c because this is what it actually does now.
Renamed usbmidi.c to midi.c for namespace clarity.
Removed more things from usbaudio.h.

The non-standard drivers were adopted accordingly.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>