License cleanup: add SPDX GPL-2.0 license identifier to files with no license
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: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2010-03-04 21:46:13 +03:00
|
|
|
#ifndef __USBAUDIO_CARD_H
|
|
|
|
|
#define __USBAUDIO_CARD_H
|
|
|
|
|
|
2012-02-14 14:18:48 +04:00
|
|
|
#define MAX_NR_RATES 1024
|
ALSA: improve buffer size computations for USB PCM audio
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: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
|
|
|
#define MAX_PACKS 6 /* per URB */
|
2010-03-04 21:46:13 +03:00
|
|
|
#define MAX_PACKS_HS (MAX_PACKS * 8) /* in high speed mode */
|
ALSA: improve buffer size computations for USB PCM audio
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: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
|
|
|
#define MAX_URBS 12
|
2010-03-04 21:46:13 +03:00
|
|
|
#define SYNC_URBS 4 /* always four urbs for sync */
|
ALSA: improve buffer size computations for USB PCM audio
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: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
|
|
|
#define MAX_QUEUE 18 /* try not to exceed this queue length, in ms */
|
2010-03-04 21:46:13 +03:00
|
|
|
|
|
|
|
|
struct audioformat {
|
|
|
|
|
struct list_head list;
|
2010-03-04 21:46:15 +03:00
|
|
|
u64 formats; /* ALSA format bits */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int channels; /* # channels */
|
|
|
|
|
unsigned int fmt_type; /* USB audio format type (1-3) */
|
2019-02-18 01:17:21 +03:00
|
|
|
unsigned int fmt_bits; /* number of significant bits */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int frame_size; /* samples per frame for non-audio */
|
2020-11-23 11:53:40 +03:00
|
|
|
unsigned char iface; /* interface number */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned char altsetting; /* corresponding alternate setting */
|
2021-01-08 10:52:18 +03:00
|
|
|
unsigned char ep_idx; /* endpoint array index */
|
2021-07-05 15:00:52 +03:00
|
|
|
unsigned char altset_idx; /* array index of alternate setting */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned char attributes; /* corresponding attributes of cs endpoint */
|
|
|
|
|
unsigned char endpoint; /* endpoint */
|
|
|
|
|
unsigned char ep_attr; /* endpoint attributes */
|
2020-11-23 11:53:14 +03:00
|
|
|
bool implicit_fb; /* implicit feedback endpoint */
|
|
|
|
|
unsigned char sync_ep; /* sync endpoint number */
|
|
|
|
|
unsigned char sync_iface; /* sync EP interface */
|
|
|
|
|
unsigned char sync_altsetting; /* sync EP alternate setting */
|
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
|
|
|
unsigned char sync_ep_idx; /* sync EP array index */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned char datainterval; /* log_2 of data packet interval */
|
2018-03-21 03:03:59 +03:00
|
|
|
unsigned char protocol; /* UAC_VERSION_1/2/3 */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int maxpacksize; /* max. packet size */
|
|
|
|
|
unsigned int rates; /* rate bitmasks */
|
|
|
|
|
unsigned int rate_min, rate_max; /* min/max rates */
|
|
|
|
|
unsigned int nr_rates; /* number of rate table entries */
|
|
|
|
|
unsigned int *rate_table; /* rate table */
|
2010-05-31 16:51:31 +04:00
|
|
|
unsigned char clock; /* associated clock */
|
2012-11-26 19:24:02 +04:00
|
|
|
struct snd_pcm_chmap_elem *chmap; /* (optional) channel map */
|
2013-04-16 20:01:38 +04:00
|
|
|
bool dsd_dop; /* add DOP headers in case of DSD samples */
|
2013-04-16 20:01:39 +04:00
|
|
|
bool dsd_bitrev; /* reverse the bits of each DSD sample */
|
2018-06-13 01:43:01 +03:00
|
|
|
bool dsd_raw; /* altsetting is raw DSD */
|
2010-03-04 21:46:13 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct snd_usb_substream;
|
2021-01-08 10:52:17 +03:00
|
|
|
struct snd_usb_iface_ref;
|
2022-05-16 13:48:07 +03:00
|
|
|
struct snd_usb_clock_ref;
|
2012-04-12 15:51:11 +04:00
|
|
|
struct snd_usb_endpoint;
|
2018-07-31 15:28:43 +03:00
|
|
|
struct snd_usb_power_domain;
|
2010-03-04 21:46:13 +03:00
|
|
|
|
|
|
|
|
struct snd_urb_ctx {
|
|
|
|
|
struct urb *urb;
|
|
|
|
|
unsigned int buffer_size; /* size of data buffer, if data URB */
|
|
|
|
|
struct snd_usb_substream *subs;
|
2012-04-12 15:51:11 +04:00
|
|
|
struct snd_usb_endpoint *ep;
|
2010-03-04 21:46:13 +03:00
|
|
|
int index; /* index for urb array */
|
|
|
|
|
int packets; /* number of packets per urb */
|
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01 19:24:55 +03:00
|
|
|
int queued; /* queued data bytes by this urb */
|
2012-04-12 15:51:11 +04:00
|
|
|
int packet_size[MAX_PACKS_HS]; /* size of packets for next submission */
|
|
|
|
|
struct list_head ready_list;
|
2010-03-04 21:46:13 +03:00
|
|
|
};
|
|
|
|
|
|
2012-04-12 15:51:11 +04:00
|
|
|
struct snd_usb_endpoint {
|
|
|
|
|
struct snd_usb_audio *chip;
|
2021-01-08 10:52:17 +03:00
|
|
|
struct snd_usb_iface_ref *iface_ref;
|
2022-05-16 13:48:07 +03:00
|
|
|
struct snd_usb_clock_ref *clock_ref;
|
2012-04-12 15:51:11 +04:00
|
|
|
|
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
|
|
|
int opened; /* open refcount; protect with chip->mutex */
|
2020-11-23 11:53:34 +03:00
|
|
|
atomic_t running; /* running status */
|
2012-04-12 15:51:11 +04:00
|
|
|
int ep_num; /* the referenced endpoint number */
|
|
|
|
|
int type; /* SND_USB_ENDPOINT_TYPE_* */
|
2020-11-23 11:53:40 +03:00
|
|
|
|
|
|
|
|
unsigned char iface; /* interface number */
|
|
|
|
|
unsigned char altsetting; /* corresponding alternate setting */
|
|
|
|
|
unsigned char ep_idx; /* endpoint array index */
|
|
|
|
|
|
2021-02-06 23:30:51 +03:00
|
|
|
atomic_t state; /* running state */
|
2012-04-12 15:51:11 +04:00
|
|
|
|
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
|
|
|
int (*prepare_data_urb) (struct snd_usb_substream *subs,
|
|
|
|
|
struct urb *urb,
|
|
|
|
|
bool in_stream_lock);
|
2012-04-12 15:51:11 +04:00
|
|
|
void (*retire_data_urb) (struct snd_usb_substream *subs,
|
|
|
|
|
struct urb *urb);
|
|
|
|
|
|
|
|
|
|
struct snd_usb_substream *data_subs;
|
2020-11-23 11:53:39 +03:00
|
|
|
struct snd_usb_endpoint *sync_source;
|
|
|
|
|
struct snd_usb_endpoint *sync_sink;
|
2012-04-12 15:51:11 +04:00
|
|
|
|
|
|
|
|
struct snd_urb_ctx urb[MAX_URBS];
|
|
|
|
|
|
|
|
|
|
struct snd_usb_packet_info {
|
|
|
|
|
uint32_t packet_size[MAX_PACKS_HS];
|
|
|
|
|
int packets;
|
|
|
|
|
} next_packet[MAX_URBS];
|
2020-11-23 11:53:32 +03:00
|
|
|
unsigned int next_packet_head; /* ring buffer offset to read */
|
|
|
|
|
unsigned int next_packet_queued; /* queued items in the ring buffer */
|
|
|
|
|
struct list_head ready_playback_urbs; /* playback URB FIFO for implicit fb */
|
2012-04-12 15:51:11 +04:00
|
|
|
|
|
|
|
|
unsigned int nurbs; /* # urbs */
|
|
|
|
|
unsigned long active_mask; /* bitmask of active urbs */
|
|
|
|
|
unsigned long unlink_mask; /* bitmask of unlinked urbs */
|
2021-09-29 11:08:37 +03:00
|
|
|
atomic_t submitted_urbs; /* currently submitted urbs */
|
2012-04-12 15:51:11 +04:00
|
|
|
char *syncbuf; /* sync buffer for all sync URBs */
|
|
|
|
|
dma_addr_t sync_dma; /* DMA address of syncbuf */
|
|
|
|
|
|
|
|
|
|
unsigned int pipe; /* the data i/o pipe */
|
2020-06-29 05:59:34 +03:00
|
|
|
unsigned int packsize[2]; /* small/large packet sizes in samples */
|
|
|
|
|
unsigned int sample_rem; /* remainder from division fs/pps */
|
2020-04-24 05:24:48 +03:00
|
|
|
unsigned int sample_accum; /* sample accumulator */
|
2020-06-29 05:59:34 +03:00
|
|
|
unsigned int pps; /* packets per second */
|
2012-04-12 15:51:11 +04:00
|
|
|
unsigned int freqn; /* nominal sampling rate in fs/fps in Q16.16 format */
|
|
|
|
|
unsigned int freqm; /* momentary sampling rate in fs/fps in Q16.16 format */
|
|
|
|
|
int freqshift; /* how much to shift the feedback value to get Q16.16 */
|
|
|
|
|
unsigned int freqmax; /* maximum sampling rate, used for buffer management */
|
|
|
|
|
unsigned int phase; /* phase accumulator */
|
|
|
|
|
unsigned int maxpacksize; /* max packet size in bytes */
|
|
|
|
|
unsigned int maxframesize; /* max packet size in frames */
|
ALSA: improve buffer size computations for USB PCM audio
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: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
|
|
|
unsigned int max_urb_frames; /* max URB size in frames */
|
2012-04-12 15:51:11 +04:00
|
|
|
unsigned int curpacksize; /* current packet size in bytes (for capture) */
|
|
|
|
|
unsigned int curframesize; /* current packet size in frames (for capture) */
|
|
|
|
|
unsigned int syncmaxsize; /* sync endpoint packet size */
|
|
|
|
|
unsigned int fill_max:1; /* fill max packet size always */
|
2016-08-22 09:53:37 +03:00
|
|
|
unsigned int tenor_fb_quirk:1; /* corrupted feedback data */
|
2012-04-12 15:51:11 +04:00
|
|
|
unsigned int datainterval; /* log_2 of data packet interval */
|
|
|
|
|
unsigned int syncinterval; /* P for adaptive mode, 0 otherwise */
|
|
|
|
|
unsigned char silence_value;
|
|
|
|
|
unsigned int stride;
|
2012-09-04 12:23:07 +04:00
|
|
|
int skip_packets; /* quirks for devices to ignore the first n packets
|
|
|
|
|
in a stream */
|
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
|
|
|
bool implicit_fb_sync; /* syncs with implicit feedback */
|
2021-09-29 11:08:38 +03:00
|
|
|
bool lowlatency_playback; /* low-latency playback mode */
|
2022-10-09 13:42:12 +03:00
|
|
|
bool need_setup; /* (re-)need for hw_params? */
|
|
|
|
|
bool need_prepare; /* (re-)need for prepare? */
|
2022-12-15 18:30:37 +03:00
|
|
|
bool fixed_rate; /* skip rate setup */
|
2012-04-12 15:51:11 +04:00
|
|
|
|
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
|
|
|
/* for hw constraints */
|
2020-11-23 11:53:33 +03:00
|
|
|
const struct audioformat *cur_audiofmt;
|
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
|
|
|
unsigned int cur_rate;
|
|
|
|
|
snd_pcm_format_t cur_format;
|
|
|
|
|
unsigned int cur_channels;
|
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
|
|
|
unsigned int cur_frame_bytes;
|
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
|
|
|
unsigned int cur_period_frames;
|
|
|
|
|
unsigned int cur_period_bytes;
|
|
|
|
|
unsigned int cur_buffer_periods;
|
|
|
|
|
|
2012-04-12 15:51:11 +04:00
|
|
|
spinlock_t lock;
|
|
|
|
|
struct list_head list;
|
|
|
|
|
};
|
|
|
|
|
|
media: sound/usb: Use Media Controller API to share media resources
Media Device Allocator API to allows multiple drivers share a media device.
This API solves a very common use-case for media devices where one physical
device (an USB stick) provides both audio and video. When such media device
exposes a standard USB Audio class, a proprietary Video class, two or more
independent drivers will share a single physical USB bridge. In such cases,
it is necessary to coordinate access to the shared resource.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.
Change the ALSA driver to use the Media Controller API to share media
resources with DVB, and V4L2 drivers on a AU0828 media device.
The 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().
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Shuah Khan <shuah@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-04-02 03:40:22 +03:00
|
|
|
struct media_ctl;
|
|
|
|
|
|
2010-03-04 21:46:13 +03:00
|
|
|
struct snd_usb_substream {
|
|
|
|
|
struct snd_usb_stream *stream;
|
|
|
|
|
struct usb_device *dev;
|
|
|
|
|
struct snd_pcm_substream *pcm_substream;
|
|
|
|
|
int direction; /* playback or capture */
|
|
|
|
|
int endpoint; /* assigned endpoint */
|
2020-11-23 11:53:33 +03:00
|
|
|
const struct audioformat *cur_audiofmt; /* current audioformat pointer (for hw_params callback) */
|
2018-07-31 15:28:43 +03:00
|
|
|
struct snd_usb_power_domain *str_pd; /* UAC3 Power Domain for streaming path */
|
2012-11-26 19:24:02 +04:00
|
|
|
unsigned int channels_max; /* max channels in the all audiofmts */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int txfr_quirk:1; /* allow sub-frame alignment */
|
ALSA: USB-audio: Add quirk for Zoom R16/24 playback
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: Ricard Wanderlof <ricardw@axis.com>
Tested-by: Panu Matilainen <pmatilai@laiskiainen.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-19 09:52:53 +03:00
|
|
|
unsigned int tx_length_quirk:1; /* add length specifier to transfers */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int fmt_type; /* USB audio format type (1-3) */
|
2013-04-13 07:33:59 +04:00
|
|
|
unsigned int pkt_offset_adj; /* Bytes to drop from beginning of packets (for non-compliant devices) */
|
2020-08-10 11:24:00 +03:00
|
|
|
unsigned int stream_offset_adj; /* Bytes to drop from beginning of stream (for non-compliant devices) */
|
2010-03-04 21:46:13 +03:00
|
|
|
|
|
|
|
|
unsigned int running: 1; /* running status */
|
ALSA: usb-audio: Reduce latency at playback start, take#2
This is another attempt for the reduction of the latency at the start
of a USB audio playback stream. The first attempt in the commit
9ce650a75a3b caused an unexpected regression (a deadlock with pipewire
usage) and was later reverted by the commit 4b820e167bf6. The devils
are always living in details, of course; the cause of the deadlock was
the call of snd_pcm_period_elapsed() inside prepare_playback_urb()
callback. In the original code, this callback is never called from
the stream lock context as it's driven solely from the URB complete
callback. Along with the movement of the URB submission into the
trigger START, this prepare call may be also executed in the stream
lock context, hence it deadlocked with the another lock in
snd_pcm_period_elapsed(). (Note that this happens only conditionally
with a small period size that matches with the URB buffer length,
which was a reason I overlooked during my tests. Also, the problem
wasn't seen in the capture stream because the capture stream handles
the period-elapsed only at retire callback that isn't executed at the
trigger.)
If it were only about avoiding the deadlock, it'd be possible to use
snd_pcm_period_elapsed_under_stream_lock() as a solution. However, in
general, the period elapsed notification must be sent after the actual
stream start, and replacing the call wouldn't satisfy the pattern.
A better option is to delay the notification after the stream start
procedure finished, instead. In the case of USB framework, one of the
fitting place would be the complete callback of the first URB.
So, as a workaround of the deadlock and the order fixes above, in
addition to the re-applying the changes in the commit 9ce650a75a3,
this patch introduces a new flag indicating the delayed period-elapsed
handling and sets it under the possible deadlock condition
(i.e. prepare callback being called before subs->running is set).
Once when the flag is set, the period-elapsed call is handled at a
later URB complete call instead.
As a reference for the original motivation for the low-latency change,
I cite here again:
| USB-audio driver behaves a bit strangely for the playback stream --
| namely, it starts sending silent packets at PCM prepare state while
| the actual data is submitted at first when the trigger START is
| kicked off. This is a workaround for the behavior where URBs are
| processed too quickly at the beginning. That is, if we start
| submitting URBs at trigger START, the first few URBs will be
| immediately completed, and this would result in the immediate
| period-elapsed calls right after the start, which may confuse
| applications.
|
| OTOH, submitting the data after silent URBs would, of course, result
| in a certain delay of the actual data processing, and this is rather
| more serious problem on modern systems, in practice.
|
| This patch tries to revert the workaround and lets the URB
| submission starting at PCM trigger for the playback again. As far
| as I've tested with various backends (native ALSA, PA, JACK, PW), I
| haven't seen any problems (famous last words :)
|
| Note that the capture stream handling needs no such workaround,
| since the capture is driven per received URB.
Link: https://lore.kernel.org/r/4e71531f-4535-fd46-040e-506a3c256bbd@marcan.st
Link: https://lore.kernel.org/r/s5hbl7li0fe.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210707112447.27485-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-07 14:24:47 +03:00
|
|
|
unsigned int period_elapsed_pending; /* delay period handling */
|
2010-03-04 21:46:13 +03:00
|
|
|
|
2021-06-01 19:24:54 +03:00
|
|
|
unsigned int buffer_bytes; /* buffer size in bytes */
|
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01 19:24:55 +03:00
|
|
|
unsigned int inflight_bytes; /* in-flight data bytes on buffer (for playback) */
|
2010-03-04 21:46:13 +03:00
|
|
|
unsigned int hwptr_done; /* processed byte position in the buffer */
|
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01 19:24:55 +03:00
|
|
|
unsigned int transfer_done; /* processed frames since last period update */
|
ALSA: improve buffer size computations for USB PCM audio
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: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
|
|
|
unsigned int frame_limit; /* limits number of packets in URB */
|
2010-03-04 21:46:13 +03:00
|
|
|
|
2012-04-12 15:51:12 +04:00
|
|
|
/* data and sync endpoints for this stream */
|
2012-06-08 11:01:37 +04:00
|
|
|
unsigned int ep_num; /* the endpoint number */
|
2012-04-12 15:51:12 +04:00
|
|
|
struct snd_usb_endpoint *data_endpoint;
|
|
|
|
|
struct snd_usb_endpoint *sync_endpoint;
|
|
|
|
|
unsigned long flags;
|
2012-10-12 17:12:55 +04:00
|
|
|
unsigned int speed; /* USB_SPEED_XXX */
|
2010-03-04 21:46:13 +03:00
|
|
|
|
|
|
|
|
u64 formats; /* format bitmasks (all or'ed) */
|
|
|
|
|
unsigned int num_formats; /* number of supported audio formats (list) */
|
|
|
|
|
struct list_head fmt_list; /* format list */
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
|
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01 19:24:55 +03:00
|
|
|
unsigned int last_frame_number; /* stored frame number */
|
2013-04-16 20:01:38 +04:00
|
|
|
|
|
|
|
|
struct {
|
|
|
|
|
int marker;
|
|
|
|
|
int channel;
|
|
|
|
|
int byte_idx;
|
|
|
|
|
} dsd_dop;
|
2015-02-07 00:55:53 +03:00
|
|
|
|
|
|
|
|
bool trigger_tstamp_pending_update; /* trigger timestamp being updated from initial estimate */
|
2021-09-29 11:08:38 +03:00
|
|
|
bool lowlatency_playback; /* low-latency playback mode */
|
media: sound/usb: Use Media Controller API to share media resources
Media Device Allocator API to allows multiple drivers share a media device.
This API solves a very common use-case for media devices where one physical
device (an USB stick) provides both audio and video. When such media device
exposes a standard USB Audio class, a proprietary Video class, two or more
independent drivers will share a single physical USB bridge. In such cases,
it is necessary to coordinate access to the shared resource.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.
Change the ALSA driver to use the Media Controller API to share media
resources with DVB, and V4L2 drivers on a AU0828 media device.
The 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().
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Shuah Khan <shuah@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-04-02 03:40:22 +03:00
|
|
|
struct media_ctl *media_ctl;
|
2010-03-04 21:46:13 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct snd_usb_stream {
|
|
|
|
|
struct snd_usb_audio *chip;
|
|
|
|
|
struct snd_pcm *pcm;
|
|
|
|
|
int pcm_index;
|
|
|
|
|
unsigned int fmt_type; /* USB audio format type (1-3) */
|
|
|
|
|
struct snd_usb_substream substream[2];
|
|
|
|
|
struct list_head list;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif /* __USBAUDIO_CARD_H */
|
