linux_old1/sound/usb/endpoint.c

1231 lines
33 KiB
C
Raw Normal View History

/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#include <linux/gfp.h>
#include <linux/init.h>
#include <linux/ratelimit.h>
#include <linux/usb.h>
#include <linux/usb/audio.h>
#include <linux/slab.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/pcm_params.h>
#include "usbaudio.h"
#include "helper.h"
#include "card.h"
#include "endpoint.h"
#include "pcm.h"
#include "quirks.h"
#define EP_FLAG_RUNNING 1
#define EP_FLAG_STOPPING 2
/*
* snd_usb_endpoint is a model that abstracts everything related to an
* USB endpoint and its streaming.
*
* There are functions to activate and deactivate the streaming URBs and
* optional callbacks to let the pcm logic handle the actual content of the
* packets for playback and record. Thus, the bus streaming and the audio
* handlers are fully decoupled.
*
* There are two different types of endpoints in audio applications.
*
* SND_USB_ENDPOINT_TYPE_DATA handles full audio data payload for both
* inbound and outbound traffic.
*
* SND_USB_ENDPOINT_TYPE_SYNC endpoints are for inbound traffic only and
* expect the payload to carry Q10.14 / Q16.16 formatted sync information
* (3 or 4 bytes).
*
* Each endpoint has to be configured prior to being used by calling
* snd_usb_endpoint_set_params().
*
* The model incorporates a reference counting, so that multiple users
* can call snd_usb_endpoint_start() and snd_usb_endpoint_stop(), and
* only the first user will effectively start the URBs, and only the last
* one to stop it will tear the URBs down again.
*/
/*
* convert a sampling rate into our full speed format (fs/1000 in Q16.16)
* this will overflow at approx 524 kHz
*/
static inline unsigned get_usb_full_speed_rate(unsigned int rate)
{
return ((rate << 13) + 62) / 125;
}
/*
* convert a sampling rate into USB high speed format (fs/8000 in Q16.16)
* this will overflow at approx 4 MHz
*/
static inline unsigned get_usb_high_speed_rate(unsigned int rate)
{
return ((rate << 10) + 62) / 125;
}
/*
* release a urb data
*/
static void release_urb_ctx(struct snd_urb_ctx *u)
{
if (u->buffer_size)
usb_free_coherent(u->ep->chip->dev, u->buffer_size,
u->urb->transfer_buffer,
u->urb->transfer_dma);
usb_free_urb(u->urb);
u->urb = NULL;
}
static const char *usb_error_string(int err)
{
switch (err) {
case -ENODEV:
return "no device";
case -ENOENT:
return "endpoint not enabled";
case -EPIPE:
return "endpoint stalled";
case -ENOSPC:
return "not enough bandwidth";
case -ESHUTDOWN:
return "device disabled";
case -EHOSTUNREACH:
return "device suspended";
case -EINVAL:
case -EAGAIN:
case -EFBIG:
case -EMSGSIZE:
return "internal error";
default:
return "unknown error";
}
}
/**
* snd_usb_endpoint_implicit_feedback_sink: Report endpoint usage type
*
* @ep: The snd_usb_endpoint
*
* Determine whether an endpoint is driven by an implicit feedback
* data endpoint source.
*/
int snd_usb_endpoint_implicit_feedback_sink(struct snd_usb_endpoint *ep)
{
return ep->sync_master &&
ep->sync_master->type == SND_USB_ENDPOINT_TYPE_DATA &&
ep->type == SND_USB_ENDPOINT_TYPE_DATA &&
usb_pipeout(ep->pipe);
}
/*
* For streaming based on information derived from sync endpoints,
* prepare_outbound_urb_sizes() will call next_packet_size() to
* determine the number of samples to be sent in the next packet.
*
* For implicit feedback, next_packet_size() is unused.
*/
int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
{
unsigned long flags;
int ret;
if (ep->fill_max)
return ep->maxframesize;
spin_lock_irqsave(&ep->lock, flags);
ep->phase = (ep->phase & 0xffff)
+ (ep->freqm << ep->datainterval);
ret = min(ep->phase >> 16, ep->maxframesize);
spin_unlock_irqrestore(&ep->lock, flags);
return ret;
}
static void retire_outbound_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *urb_ctx)
{
if (ep->retire_data_urb)
ep->retire_data_urb(ep->data_subs, urb_ctx->urb);
}
static void retire_inbound_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *urb_ctx)
{
struct urb *urb = urb_ctx->urb;
if (unlikely(ep->skip_packets > 0)) {
ep->skip_packets--;
return;
}
if (ep->sync_slave)
snd_usb_handle_sync_urb(ep->sync_slave, ep, urb);
if (ep->retire_data_urb)
ep->retire_data_urb(ep->data_subs, urb);
}
static void prepare_silent_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *ctx)
{
struct urb *urb = ctx->urb;
unsigned int offs = 0;
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 14:52:53 +08:00
unsigned int extra = 0;
__le32 packet_length;
int i;
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 14:52:53 +08:00
/* For tx_length_quirk, put packet length at start of packet */
if (ep->chip->tx_length_quirk)
extra = sizeof(packet_length);
for (i = 0; i < ctx->packets; ++i) {
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 14:52:53 +08:00
unsigned int offset;
unsigned int length;
int counts;
if (ctx->packet_size[i])
counts = ctx->packet_size[i];
else
counts = snd_usb_endpoint_next_packet_size(ep);
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 14:52:53 +08:00
length = counts * ep->stride; /* number of silent bytes */
offset = offs * ep->stride + extra * i;
urb->iso_frame_desc[i].offset = offset;
urb->iso_frame_desc[i].length = length + extra;
if (extra) {
packet_length = cpu_to_le32(length);
memcpy(urb->transfer_buffer + offset,
&packet_length, sizeof(packet_length));
}
memset(urb->transfer_buffer + offset + extra,
ep->silence_value, length);
offs += counts;
}
urb->number_of_packets = ctx->packets;
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 14:52:53 +08:00
urb->transfer_buffer_length = offs * ep->stride + ctx->packets * extra;
}
/*
* Prepare a PLAYBACK urb for submission to the bus.
*/
static void prepare_outbound_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *ctx)
{
struct urb *urb = ctx->urb;
unsigned char *cp = urb->transfer_buffer;
urb->dev = ep->chip->dev; /* we need to set this at each time */
switch (ep->type) {
case SND_USB_ENDPOINT_TYPE_DATA:
if (ep->prepare_data_urb) {
ep->prepare_data_urb(ep->data_subs, urb);
} else {
/* no data provider, so send silence */
prepare_silent_urb(ep, ctx);
}
break;
case SND_USB_ENDPOINT_TYPE_SYNC:
if (snd_usb_get_speed(ep->chip->dev) >= USB_SPEED_HIGH) {
/*
* fill the length and offset of each urb descriptor.
* the fixed 12.13 frequency is passed as 16.16 through the pipe.
*/
urb->iso_frame_desc[0].length = 4;
urb->iso_frame_desc[0].offset = 0;
cp[0] = ep->freqn;
cp[1] = ep->freqn >> 8;
cp[2] = ep->freqn >> 16;
cp[3] = ep->freqn >> 24;
} else {
/*
* fill the length and offset of each urb descriptor.
* the fixed 10.14 frequency is passed through the pipe.
*/
urb->iso_frame_desc[0].length = 3;
urb->iso_frame_desc[0].offset = 0;
cp[0] = ep->freqn >> 2;
cp[1] = ep->freqn >> 10;
cp[2] = ep->freqn >> 18;
}
break;
}
}
/*
* Prepare a CAPTURE or SYNC urb for submission to the bus.
*/
static inline void prepare_inbound_urb(struct snd_usb_endpoint *ep,
struct snd_urb_ctx *urb_ctx)
{
int i, offs;
struct urb *urb = urb_ctx->urb;
urb->dev = ep->chip->dev; /* we need to set this at each time */
switch (ep->type) {
case SND_USB_ENDPOINT_TYPE_DATA:
offs = 0;
for (i = 0; i < urb_ctx->packets; i++) {
urb->iso_frame_desc[i].offset = offs;
urb->iso_frame_desc[i].length = ep->curpacksize;
offs += ep->curpacksize;
}
urb->transfer_buffer_length = offs;
urb->number_of_packets = urb_ctx->packets;
break;
case SND_USB_ENDPOINT_TYPE_SYNC:
urb->iso_frame_desc[0].length = min(4u, ep->syncmaxsize);
urb->iso_frame_desc[0].offset = 0;
break;
}
}
/*
* Send output urbs that have been prepared previously. URBs are dequeued
* from ep->ready_playback_urbs and in case there there aren't any available
* or there are no packets that have been prepared, this function does
* nothing.
*
* The reason why the functionality of sending and preparing URBs is separated
* is that host controllers don't guarantee the order in which they return
* inbound and outbound packets to their submitters.
*
* This function is only used for implicit feedback endpoints. For endpoints
* driven by dedicated sync endpoints, URBs are immediately re-submitted
* from their completion handler.
*/
static void queue_pending_output_urbs(struct snd_usb_endpoint *ep)
{
while (test_bit(EP_FLAG_RUNNING, &ep->flags)) {
unsigned long flags;
struct snd_usb_packet_info *uninitialized_var(packet);
struct snd_urb_ctx *ctx = NULL;
int err, i;
spin_lock_irqsave(&ep->lock, flags);
if (ep->next_packet_read_pos != ep->next_packet_write_pos) {
packet = ep->next_packet + ep->next_packet_read_pos;
ep->next_packet_read_pos++;
ep->next_packet_read_pos %= MAX_URBS;
/* take URB out of FIFO */
if (!list_empty(&ep->ready_playback_urbs))
ctx = list_first_entry(&ep->ready_playback_urbs,
struct snd_urb_ctx, ready_list);
}
spin_unlock_irqrestore(&ep->lock, flags);
if (ctx == NULL)
return;
list_del_init(&ctx->ready_list);
/* copy over the length information */
for (i = 0; i < packet->packets; i++)
ctx->packet_size[i] = packet->packet_size[i];
/* call the data handler to fill in playback data */
prepare_outbound_urb(ep, ctx);
err = usb_submit_urb(ctx->urb, GFP_ATOMIC);
if (err < 0)
usb_audio_err(ep->chip,
"Unable to submit urb #%d: %d (urb %p)\n",
ctx->index, err, ctx->urb);
else
set_bit(ctx->index, &ep->active_mask);
}
}
/*
* complete callback for urbs
*/
static void snd_complete_urb(struct urb *urb)
{
struct snd_urb_ctx *ctx = urb->context;
struct snd_usb_endpoint *ep = ctx->ep;
struct snd_pcm_substream *substream;
unsigned long flags;
int err;
if (unlikely(urb->status == -ENOENT || /* unlinked */
urb->status == -ENODEV || /* device removed */
urb->status == -ECONNRESET || /* unlinked */
ALSA: usb-audio: Avoid nested autoresume calls After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-25 22:09:00 +08:00
urb->status == -ESHUTDOWN)) /* device disabled */
goto exit_clear;
/* device disconnected */
if (unlikely(atomic_read(&ep->chip->shutdown)))
goto exit_clear;
if (unlikely(!test_bit(EP_FLAG_RUNNING, &ep->flags)))
goto exit_clear;
if (usb_pipeout(ep->pipe)) {
retire_outbound_urb(ep, ctx);
/* can be stopped during retire callback */
if (unlikely(!test_bit(EP_FLAG_RUNNING, &ep->flags)))
goto exit_clear;
if (snd_usb_endpoint_implicit_feedback_sink(ep)) {
spin_lock_irqsave(&ep->lock, flags);
list_add_tail(&ctx->ready_list, &ep->ready_playback_urbs);
spin_unlock_irqrestore(&ep->lock, flags);
queue_pending_output_urbs(ep);
goto exit_clear;
}
prepare_outbound_urb(ep, ctx);
} else {
retire_inbound_urb(ep, ctx);
/* can be stopped during retire callback */
if (unlikely(!test_bit(EP_FLAG_RUNNING, &ep->flags)))
goto exit_clear;
prepare_inbound_urb(ep, ctx);
}
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err == 0)
return;
usb_audio_err(ep->chip, "cannot submit urb (err = %d)\n", err);
if (ep->data_subs && ep->data_subs->pcm_substream) {
substream = ep->data_subs->pcm_substream;
snd_pcm_stop_xrun(substream);
}
exit_clear:
clear_bit(ctx->index, &ep->active_mask);
}
/**
* snd_usb_add_endpoint: Add an endpoint to an USB audio chip
*
* @chip: The chip
* @alts: The USB host interface
* @ep_num: The number of the endpoint to use
* @direction: SNDRV_PCM_STREAM_PLAYBACK or SNDRV_PCM_STREAM_CAPTURE
* @type: SND_USB_ENDPOINT_TYPE_DATA or SND_USB_ENDPOINT_TYPE_SYNC
*
* If the requested endpoint has not been added to the given chip before,
* a new instance is created. Otherwise, a pointer to the previoulsy
* created instance is returned. In case of any error, NULL is returned.
*
* New endpoints will be added to chip->ep_list and must be freed by
* calling snd_usb_endpoint_free().
*
* For SND_USB_ENDPOINT_TYPE_SYNC, the caller needs to guarantee that
* bNumEndpoints > 1 beforehand.
*/
struct snd_usb_endpoint *snd_usb_add_endpoint(struct snd_usb_audio *chip,
struct usb_host_interface *alts,
int ep_num, int direction, int type)
{
struct snd_usb_endpoint *ep;
int is_playback = direction == SNDRV_PCM_STREAM_PLAYBACK;
if (WARN_ON(!alts))
return NULL;
mutex_lock(&chip->mutex);
list_for_each_entry(ep, &chip->ep_list, list) {
if (ep->ep_num == ep_num &&
ep->iface == alts->desc.bInterfaceNumber &&
ep->altsetting == alts->desc.bAlternateSetting) {
usb_audio_dbg(ep->chip,
"Re-using EP %x in iface %d,%d @%p\n",
ep_num, ep->iface, ep->altsetting, ep);
goto __exit_unlock;
}
}
usb_audio_dbg(chip, "Creating new %s %s endpoint #%x\n",
is_playback ? "playback" : "capture",
type == SND_USB_ENDPOINT_TYPE_DATA ? "data" : "sync",
ep_num);
ep = kzalloc(sizeof(*ep), GFP_KERNEL);
if (!ep)
goto __exit_unlock;
ep->chip = chip;
spin_lock_init(&ep->lock);
ep->type = type;
ep->ep_num = ep_num;
ep->iface = alts->desc.bInterfaceNumber;
ep->altsetting = alts->desc.bAlternateSetting;
INIT_LIST_HEAD(&ep->ready_playback_urbs);
ep_num &= USB_ENDPOINT_NUMBER_MASK;
if (is_playback)
ep->pipe = usb_sndisocpipe(chip->dev, ep_num);
else
ep->pipe = usb_rcvisocpipe(chip->dev, ep_num);
if (type == SND_USB_ENDPOINT_TYPE_SYNC) {
if (get_endpoint(alts, 1)->bLength >= USB_DT_ENDPOINT_AUDIO_SIZE &&
get_endpoint(alts, 1)->bRefresh >= 1 &&
get_endpoint(alts, 1)->bRefresh <= 9)
ep->syncinterval = get_endpoint(alts, 1)->bRefresh;
else if (snd_usb_get_speed(chip->dev) == USB_SPEED_FULL)
ep->syncinterval = 1;
else if (get_endpoint(alts, 1)->bInterval >= 1 &&
get_endpoint(alts, 1)->bInterval <= 16)
ep->syncinterval = get_endpoint(alts, 1)->bInterval - 1;
else
ep->syncinterval = 3;
ep->syncmaxsize = le16_to_cpu(get_endpoint(alts, 1)->wMaxPacketSize);
}
list_add_tail(&ep->list, &chip->ep_list);
__exit_unlock:
mutex_unlock(&chip->mutex);
return ep;
}
/*
* wait until all urbs are processed.
*/
static int wait_clear_urbs(struct snd_usb_endpoint *ep)
{
unsigned long end_time = jiffies + msecs_to_jiffies(1000);
int alive;
do {
alive = bitmap_weight(&ep->active_mask, ep->nurbs);
if (!alive)
break;
schedule_timeout_uninterruptible(1);
} while (time_before(jiffies, end_time));
if (alive)
usb_audio_err(ep->chip,
"timeout: still %d active urbs on EP #%x\n",
alive, ep->ep_num);
clear_bit(EP_FLAG_STOPPING, &ep->flags);
ALSA: usb-audio: Fix irq/process data synchronization Commit 16200948d83 ("ALSA: usb-audio: Fix race at stopping the stream") was incomplete causing another more severe kernel panic, so it got reverted. This fixes both the original problem and its fallout kernel race/crash. The original fix is to move the endpoint member NULL clearing logic inside wait_clear_urbs() so the irq triggering the urb completion doesn't call retire_capture/playback_urb() after the NULL clearing and generate a panic. However this creates a new race between snd_usb_endpoint_start()'s call to wait_clear_urbs() and the irq urb completion handler which again calls retire_capture/playback_urb() leading to a new NULL dereference. We keep the EP deactivation code in snd_usb_endpoint_start() because removing it will break the EP reference counting (see [1] [2] for info), however we don't need the "can_sleep" mechanism anymore because a new function was introduced (snd_usb_endpoint_sync_pending_stop()) which synchronizes pending stops and gets called inside the pcm prepare callback. It also makes sense to remove can_sleep because it was also removed from deactivate_urbs() signature in [3] so we benefit from more simplification. [1] commit 015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start") [2] commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream") [3] commit ccc1696d5 ("ALSA: usb-audio: simplify endpoint deactivation code") Fixes: f8114f8583bb ("Revert "ALSA: usb-audio: Fix race at stopping the stream"") Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-01-05 06:37:46 +08:00
ep->data_subs = NULL;
ep->sync_slave = NULL;
ep->retire_data_urb = NULL;
ep->prepare_data_urb = NULL;
return 0;
}
/* sync the pending stop operation;
* this function itself doesn't trigger the stop operation
*/
void snd_usb_endpoint_sync_pending_stop(struct snd_usb_endpoint *ep)
{
if (ep && test_bit(EP_FLAG_STOPPING, &ep->flags))
wait_clear_urbs(ep);
}
/*
* unlink active urbs.
*/
static int deactivate_urbs(struct snd_usb_endpoint *ep, bool force)
{
unsigned int i;
ALSA: usb-audio: Avoid nested autoresume calls After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-25 22:09:00 +08:00
if (!force && atomic_read(&ep->chip->shutdown)) /* to be sure... */
return -EBADFD;
clear_bit(EP_FLAG_RUNNING, &ep->flags);
INIT_LIST_HEAD(&ep->ready_playback_urbs);
ep->next_packet_read_pos = 0;
ep->next_packet_write_pos = 0;
for (i = 0; i < ep->nurbs; i++) {
if (test_bit(i, &ep->active_mask)) {
if (!test_and_set_bit(i, &ep->unlink_mask)) {
struct urb *u = ep->urb[i].urb;
usb_unlink_urb(u);
}
}
}
return 0;
}
/*
* release an endpoint's urbs
*/
static void release_urbs(struct snd_usb_endpoint *ep, int force)
{
int i;
/* route incoming urbs to nirvana */
ep->retire_data_urb = NULL;
ep->prepare_data_urb = NULL;
/* stop urbs */
deactivate_urbs(ep, force);
wait_clear_urbs(ep);
for (i = 0; i < ep->nurbs; i++)
release_urb_ctx(&ep->urb[i]);
if (ep->syncbuf)
usb_free_coherent(ep->chip->dev, SYNC_URBS * 4,
ep->syncbuf, ep->sync_dma);
ep->syncbuf = NULL;
ep->nurbs = 0;
}
/*
* configure a data endpoint
*/
static int data_ep_set_params(struct snd_usb_endpoint *ep,
snd_pcm_format_t pcm_format,
unsigned int channels,
unsigned int period_bytes,
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-25 03:51:58 +08:00
unsigned int frames_per_period,
unsigned int periods_per_buffer,
struct audioformat *fmt,
struct snd_usb_endpoint *sync_ep)
{
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-25 03:51:58 +08:00
unsigned int maxsize, minsize, packs_per_ms, max_packs_per_urb;
unsigned int max_packs_per_period, urbs_per_period, urb_packs;
unsigned int max_urbs, i;
int frame_bits = snd_pcm_format_physical_width(pcm_format) * channels;
int tx_length_quirk = (ep->chip->tx_length_quirk &&
usb_pipeout(ep->pipe));
if (pcm_format == SNDRV_PCM_FORMAT_DSD_U16_LE && fmt->dsd_dop) {
/*
* When operating in DSD DOP mode, the size of a sample frame
* in hardware differs from the actual physical format width
* because we need to make room for the DOP markers.
*/
frame_bits += channels << 3;
}
ep->datainterval = fmt->datainterval;
ep->stride = frame_bits >> 3;
switch (pcm_format) {
case SNDRV_PCM_FORMAT_U8:
ep->silence_value = 0x80;
break;
case SNDRV_PCM_FORMAT_DSD_U8:
case SNDRV_PCM_FORMAT_DSD_U16_LE:
case SNDRV_PCM_FORMAT_DSD_U32_LE:
case SNDRV_PCM_FORMAT_DSD_U16_BE:
case SNDRV_PCM_FORMAT_DSD_U32_BE:
ep->silence_value = 0x69;
break;
default:
ep->silence_value = 0;
}
/* assume max. frequency is 50% higher than nominal */
ep->freqmax = ep->freqn + (ep->freqn >> 1);
ALSA: usb-audio: Fix max packet size calculation for USB audio Rounding must take place before multiplication with the frame size, since each packet contains a whole number of frames. We must also properly consider the data interval, as a larger data interval will result in larger packets, which, depending on the sampling frequency, can result in packet sizes that are less than integral multiples of the packet size for a lower data interval. Detailed explanation and rationale: The code before this commit had the following expression on line 613 to calculate the maximum isochronous packet size: maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) >> (16 - ep->datainterval); Here, ep->freqmax is the maximum assumed sample frequency, calculated from the nominal sample frequency plus 25%. It is ultimately derived from ep->freqn, which is in the units of frames per packet, from get_usb_full_speed_rate() or usb_high_speed_rate(), as applicable, in Q16.16 format. The expression essentially adds the Q16.16 equivalent of 0.999... (i.e. the largest number less than one) to the sample rate, in order to get a rate whose integer part is rounded up from the fractional value. The multiplication with (frame_bits >> 3) yields the number of bytes in a packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back to an integer, taking into consideration the bDataInterval field of the endpoint descriptor (which describes how often isochronous packets are transmitted relative to the (micro)frame rate (125us or 1ms, for USB high speed and full speed, respectively)). For this discussion we will initially assume a bDataInterval of 0, so the second line of the expression just converts the Q16.16 value to an integer. In order to illustrate the problem, we will set frame_bits 64, which corresponds to a frame size of 8 bytes. The problem here is twofold. First, the rounding operation consists of the addition of 0x0.ffff and subsequent conversion to integer, but as the expression stands, the conversion to integer is done after multiplication with the frame size, rather than before. This results in the resulting maxsize becoming too large. Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is 0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000. The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 . However, if we do the number of bytes calculation in a less obscure way it's more apparent what the true corresponding packet size is: we get ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612, and the 8000 is the number of isochronous packets per second on a high speed USB connection (125 us microframe interval). This is fixed by performing the complete rounding operation prior to multiplication with the frame rate. The second problem is that when considering the ep->datainterval, this must be done before rounding, in order to take the advantage of the fact that if the number of bytes per packet is not an integer, the resulting rounded-up integer is not necessarily a factor of two when the data interval is increased by the same factor. For instance, assuming a freqency of 41 kHz, the resulting bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or 0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0), this means that 6 frames per packet are needed, whereas with a data interval of 2 we need 10.25, i.e. 11 frames needed. Rephrasing the maxsize expression to: maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) * (frame_bits >> 3); for the above 96 kHz example we instead get ((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value. We can also do the calculation with a non-integer sample rate which is when rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn = 0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)): Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down) True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56 New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56 This is also corroborated by the wMaxPacketSize check on line 616. Assume that wMaxPacketSize = 104, with ep->maxpacksize then having the same value. As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to (104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111 (with decimals 111.99988). Clearly, we should get back the 104 here, which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 . (The error has not been a problem because it only results in maxsize being a bit too big which just wastes a couple of bytes, either as a result of the first maxsize calculation, or because the resulting calculation will hit the wMaxPacketSize value before the packet is too big, resulting in fixing the size to wMaxPacketSize even though the packet is actually not too long.) Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz. Signed-off-by: Ricard Wanderlof <ricardw@axis.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-12 02:54:51 +08:00
/* Round up freqmax to nearest integer in order to calculate maximum
* packet size, which must represent a whole number of frames.
* This is accomplished by adding 0x0.ffff before converting the
* Q16.16 format into integer.
* In order to accurately calculate the maximum packet size when
* the data interval is more than 1 (i.e. ep->datainterval > 0),
* multiply by the data interval prior to rounding. For instance,
* a freqmax of 41 kHz will result in a max packet size of 6 (5.125)
* frames with a data interval of 1, but 11 (10.25) frames with a
* data interval of 2.
* (ep->freqmax << ep->datainterval overflows at 8.192 MHz for the
* maximum datainterval value of 3, at USB full speed, higher for
* USB high speed, noting that ep->freqmax is in units of
* frames per packet in Q16.16 format.)
*/
maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) *
(frame_bits >> 3);
if (tx_length_quirk)
maxsize += sizeof(__le32); /* Space for length descriptor */
/* but wMaxPacketSize might reduce this */
if (ep->maxpacksize && ep->maxpacksize < maxsize) {
/* whatever fits into a max. size packet */
unsigned int data_maxsize = maxsize = ep->maxpacksize;
if (tx_length_quirk)
/* Need to remove the length descriptor to calc freq */
data_maxsize -= sizeof(__le32);
ep->freqmax = (data_maxsize / (frame_bits >> 3))
<< (16 - ep->datainterval);
}
if (ep->fill_max)
ep->curpacksize = ep->maxpacksize;
else
ep->curpacksize = maxsize;
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-25 03:51:58 +08:00
if (snd_usb_get_speed(ep->chip->dev) != USB_SPEED_FULL) {
packs_per_ms = 8 >> ep->datainterval;
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-25 03:51:58 +08:00
max_packs_per_urb = MAX_PACKS_HS;
} else {
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-25 03:51:58 +08:00
packs_per_ms = 1;
max_packs_per_urb = MAX_PACKS;
}
if (sync_ep && !snd_usb_endpoint_implicit_feedback_sink(ep))
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-25 03:51:58 +08:00
max_packs_per_urb = min(max_packs_per_urb,
1U << sync_ep->syncinterval);
max_packs_per_urb = max(1u, max_packs_per_urb >> ep->datainterval);
/*
* Capture endpoints need to use small URBs because there's no way
* to tell in advance where the next period will end, and we don't
* want the next URB to complete much after the period ends.
*
* Playback endpoints with implicit sync much use the same parameters
* as their corresponding capture endpoint.
*/
if (usb_pipein(ep->pipe) ||
snd_usb_endpoint_implicit_feedback_sink(ep)) {
urb_packs = packs_per_ms;
/*
* Wireless devices can poll at a max rate of once per 4ms.
* For dataintervals less than 5, increase the packet count to
* allow the host controller to use bursting to fill in the
* gaps.
*/
if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_WIRELESS) {
int interval = ep->datainterval;
while (interval < 5) {
urb_packs <<= 1;
++interval;
}
}
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-25 03:51:58 +08:00
/* make capture URBs <= 1 ms and smaller than a period */
urb_packs = min(max_packs_per_urb, urb_packs);
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-25 03:51:58 +08:00
while (urb_packs > 1 && urb_packs * maxsize >= period_bytes)
urb_packs >>= 1;
ep->nurbs = MAX_URBS;
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-25 03:51:58 +08:00
/*
* Playback endpoints without implicit sync are adjusted so that
* a period fits as evenly as possible in the smallest number of
* URBs. The total number of URBs is adjusted to the size of the
* ALSA buffer, subject to the MAX_URBS and MAX_QUEUE limits.
*/
} else {
/* determine how small a packet can be */
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-25 03:51:58 +08:00
minsize = (ep->freqn >> (16 - ep->datainterval)) *
(frame_bits >> 3);
/* with sync from device, assume it can be 12% lower */
if (sync_ep)
minsize -= minsize >> 3;
minsize = max(minsize, 1u);
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-25 03:51:58 +08:00
/* how many packets will contain an entire ALSA period? */
max_packs_per_period = DIV_ROUND_UP(period_bytes, minsize);
/* how many URBs will contain a period? */
urbs_per_period = DIV_ROUND_UP(max_packs_per_period,
max_packs_per_urb);
/* how many packets are needed in each URB? */
urb_packs = DIV_ROUND_UP(max_packs_per_period, urbs_per_period);
/* limit the number of frames in a single URB */
ep->max_urb_frames = DIV_ROUND_UP(frames_per_period,
urbs_per_period);
/* try to use enough URBs to contain an entire ALSA buffer */
max_urbs = min((unsigned) MAX_URBS,
MAX_QUEUE * packs_per_ms / urb_packs);
ep->nurbs = min(max_urbs, urbs_per_period * periods_per_buffer);
}
/* allocate and initialize data urbs */
for (i = 0; i < ep->nurbs; i++) {
struct snd_urb_ctx *u = &ep->urb[i];
u->index = i;
u->ep = ep;
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-25 03:51:58 +08:00
u->packets = urb_packs;
u->buffer_size = maxsize * u->packets;
if (fmt->fmt_type == UAC_FORMAT_TYPE_II)
u->packets++; /* for transfer delimiter */
u->urb = usb_alloc_urb(u->packets, GFP_KERNEL);
if (!u->urb)
goto out_of_memory;
u->urb->transfer_buffer =
usb_alloc_coherent(ep->chip->dev, u->buffer_size,
GFP_KERNEL, &u->urb->transfer_dma);
if (!u->urb->transfer_buffer)
goto out_of_memory;
u->urb->pipe = ep->pipe;
u->urb->transfer_flags = URB_NO_TRANSFER_DMA_MAP;
u->urb->interval = 1 << ep->datainterval;
u->urb->context = u;
u->urb->complete = snd_complete_urb;
INIT_LIST_HEAD(&u->ready_list);
}
return 0;
out_of_memory:
release_urbs(ep, 0);
return -ENOMEM;
}
/*
* configure a sync endpoint
*/
static int sync_ep_set_params(struct snd_usb_endpoint *ep)
{
int i;
ep->syncbuf = usb_alloc_coherent(ep->chip->dev, SYNC_URBS * 4,
GFP_KERNEL, &ep->sync_dma);
if (!ep->syncbuf)
return -ENOMEM;
for (i = 0; i < SYNC_URBS; i++) {
struct snd_urb_ctx *u = &ep->urb[i];
u->index = i;
u->ep = ep;
u->packets = 1;
u->urb = usb_alloc_urb(1, GFP_KERNEL);
if (!u->urb)
goto out_of_memory;
u->urb->transfer_buffer = ep->syncbuf + i * 4;
u->urb->transfer_dma = ep->sync_dma + i * 4;
u->urb->transfer_buffer_length = 4;
u->urb->pipe = ep->pipe;
u->urb->transfer_flags = URB_NO_TRANSFER_DMA_MAP;
u->urb->number_of_packets = 1;
u->urb->interval = 1 << ep->syncinterval;
u->urb->context = u;
u->urb->complete = snd_complete_urb;
}
ep->nurbs = SYNC_URBS;
return 0;
out_of_memory:
release_urbs(ep, 0);
return -ENOMEM;
}
/**
* snd_usb_endpoint_set_params: configure an snd_usb_endpoint
*
* @ep: the snd_usb_endpoint to configure
* @pcm_format: the audio fomat.
* @channels: the number of audio channels.
* @period_bytes: the number of bytes in one alsa period.
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-25 03:51:58 +08:00
* @period_frames: the number of frames in one alsa period.
* @buffer_periods: the number of periods in one alsa buffer.
* @rate: the frame rate.
* @fmt: the USB audio format information
* @sync_ep: the sync endpoint to use, if any
*
* Determine the number of URBs to be used on this endpoint.
* An endpoint must be configured before it can be started.
* An endpoint that is already running can not be reconfigured.
*/
int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
snd_pcm_format_t pcm_format,
unsigned int channels,
unsigned int period_bytes,
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-25 03:51:58 +08:00
unsigned int period_frames,
unsigned int buffer_periods,
unsigned int rate,
struct audioformat *fmt,
struct snd_usb_endpoint *sync_ep)
{
int err;
if (ep->use_count != 0) {
usb_audio_warn(ep->chip,
"Unable to change format on ep #%x: already in use\n",
ep->ep_num);
return -EBUSY;
}
/* release old buffers, if any */
release_urbs(ep, 0);
ep->datainterval = fmt->datainterval;
ep->maxpacksize = fmt->maxpacksize;
ep->fill_max = !!(fmt->attributes & UAC_EP_CS_ATTR_FILL_MAX);
if (snd_usb_get_speed(ep->chip->dev) == USB_SPEED_FULL)
ep->freqn = get_usb_full_speed_rate(rate);
else
ep->freqn = get_usb_high_speed_rate(rate);
/* calculate the frequency in 16.16 format */
ep->freqm = ep->freqn;
ep->freqshift = INT_MIN;
ep->phase = 0;
switch (ep->type) {
case SND_USB_ENDPOINT_TYPE_DATA:
err = data_ep_set_params(ep, pcm_format, channels,
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-25 03:51:58 +08:00
period_bytes, period_frames,
buffer_periods, fmt, sync_ep);
break;
case SND_USB_ENDPOINT_TYPE_SYNC:
err = sync_ep_set_params(ep);
break;
default:
err = -EINVAL;
}
usb_audio_dbg(ep->chip,
"Setting params for ep #%x (type %d, %d urbs), ret=%d\n",
ep->ep_num, ep->type, ep->nurbs, err);
return err;
}
/**
* snd_usb_endpoint_start: start an snd_usb_endpoint
*
ALSA: usb-audio: Fix irq/process data synchronization Commit 16200948d83 ("ALSA: usb-audio: Fix race at stopping the stream") was incomplete causing another more severe kernel panic, so it got reverted. This fixes both the original problem and its fallout kernel race/crash. The original fix is to move the endpoint member NULL clearing logic inside wait_clear_urbs() so the irq triggering the urb completion doesn't call retire_capture/playback_urb() after the NULL clearing and generate a panic. However this creates a new race between snd_usb_endpoint_start()'s call to wait_clear_urbs() and the irq urb completion handler which again calls retire_capture/playback_urb() leading to a new NULL dereference. We keep the EP deactivation code in snd_usb_endpoint_start() because removing it will break the EP reference counting (see [1] [2] for info), however we don't need the "can_sleep" mechanism anymore because a new function was introduced (snd_usb_endpoint_sync_pending_stop()) which synchronizes pending stops and gets called inside the pcm prepare callback. It also makes sense to remove can_sleep because it was also removed from deactivate_urbs() signature in [3] so we benefit from more simplification. [1] commit 015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start") [2] commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream") [3] commit ccc1696d5 ("ALSA: usb-audio: simplify endpoint deactivation code") Fixes: f8114f8583bb ("Revert "ALSA: usb-audio: Fix race at stopping the stream"") Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-01-05 06:37:46 +08:00
* @ep: the endpoint to start
*
* A call to this function will increment the use count of the endpoint.
* In case it is not already running, the URBs for this endpoint will be
* submitted. Otherwise, this function does nothing.
*
* Must be balanced to calls of snd_usb_endpoint_stop().
*
* Returns an error if the URB submission failed, 0 in all other cases.
*/
ALSA: usb-audio: Fix irq/process data synchronization Commit 16200948d83 ("ALSA: usb-audio: Fix race at stopping the stream") was incomplete causing another more severe kernel panic, so it got reverted. This fixes both the original problem and its fallout kernel race/crash. The original fix is to move the endpoint member NULL clearing logic inside wait_clear_urbs() so the irq triggering the urb completion doesn't call retire_capture/playback_urb() after the NULL clearing and generate a panic. However this creates a new race between snd_usb_endpoint_start()'s call to wait_clear_urbs() and the irq urb completion handler which again calls retire_capture/playback_urb() leading to a new NULL dereference. We keep the EP deactivation code in snd_usb_endpoint_start() because removing it will break the EP reference counting (see [1] [2] for info), however we don't need the "can_sleep" mechanism anymore because a new function was introduced (snd_usb_endpoint_sync_pending_stop()) which synchronizes pending stops and gets called inside the pcm prepare callback. It also makes sense to remove can_sleep because it was also removed from deactivate_urbs() signature in [3] so we benefit from more simplification. [1] commit 015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start") [2] commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream") [3] commit ccc1696d5 ("ALSA: usb-audio: simplify endpoint deactivation code") Fixes: f8114f8583bb ("Revert "ALSA: usb-audio: Fix race at stopping the stream"") Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-01-05 06:37:46 +08:00
int snd_usb_endpoint_start(struct snd_usb_endpoint *ep)
{
int err;
unsigned int i;
ALSA: usb-audio: Avoid nested autoresume calls After the recent fix of runtime PM for USB-audio driver, we got a lockdep warning like: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc8+ #61 Not tainted --------------------------------------------- pulseaudio/980 is trying to acquire lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] but task is already holding lock: (&chip->shutdown_rwsem){.+.+.+}, at: [<ffffffffa0355dac>] snd_usb_autoresume+0x1d/0x52 [snd_usb_audio] This comes from snd_usb_autoresume() invoking down_read() and it's used in a nested way. Although it's basically safe, per se (as these are read locks), it's better to reduce such spurious warnings. The read lock is needed to guarantee the execution of "shutdown" (cleanup at disconnection) task after all concurrent tasks are finished. This can be implemented in another better way. Also, the current check of chip->in_pm isn't good enough for protecting the racy execution of multiple auto-resumes. This patch rewrites the logic of snd_usb_autoresume() & co; namely, - The recursive call of autopm is avoided by the new refcount, chip->active. The chip->in_pm flag is removed accordingly. - Instead of rwsem, another refcount, chip->usage_count, is introduced for tracking the period to delay the shutdown procedure. At the last clear of this refcount, wake_up() to the shutdown waiter is called. - The shutdown flag is replaced with shutdown atomic count; this is for reducing the lock. - Two new helpers are introduced to simplify the management of these refcounts; snd_usb_lock_shutdown() increases the usage_count, checks the shutdown state, and does autoresume. snd_usb_unlock_shutdown() does the opposite. Most of mixer and other codes just need this, and simply returns an error if it receives an error from lock. Fixes: 9003ebb13f61 ('ALSA: usb-audio: Fix runtime PM unbalance') Reported-and-tested-by: Alexnader Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-08-25 22:09:00 +08:00
if (atomic_read(&ep->chip->shutdown))
return -EBADFD;
/* already running? */
if (++ep->use_count != 1)
return 0;
/* just to be sure */
deactivate_urbs(ep, false);
ep->active_mask = 0;
ep->unlink_mask = 0;
ep->phase = 0;
snd_usb_endpoint_start_quirk(ep);
/*
* If this endpoint has a data endpoint as implicit feedback source,
* don't start the urbs here. Instead, mark them all as available,
* wait for the record urbs to return and queue the playback urbs
* from that context.
*/
set_bit(EP_FLAG_RUNNING, &ep->flags);
if (snd_usb_endpoint_implicit_feedback_sink(ep)) {
for (i = 0; i < ep->nurbs; i++) {
struct snd_urb_ctx *ctx = ep->urb + i;
list_add_tail(&ctx->ready_list, &ep->ready_playback_urbs);
}
return 0;
}
for (i = 0; i < ep->nurbs; i++) {
struct urb *urb = ep->urb[i].urb;
if (snd_BUG_ON(!urb))
goto __error;
if (usb_pipeout(ep->pipe)) {
prepare_outbound_urb(ep, urb->context);
} else {
prepare_inbound_urb(ep, urb->context);
}
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err < 0) {
usb_audio_err(ep->chip,
"cannot submit urb %d, error %d: %s\n",
i, err, usb_error_string(err));
goto __error;
}
set_bit(i, &ep->active_mask);
}
return 0;
__error:
clear_bit(EP_FLAG_RUNNING, &ep->flags);
ep->use_count--;
deactivate_urbs(ep, false);
return -EPIPE;
}
/**
* snd_usb_endpoint_stop: stop an snd_usb_endpoint
*
* @ep: the endpoint to stop (may be NULL)
*
* A call to this function will decrement the use count of the endpoint.
* In case the last user has requested the endpoint stop, the URBs will
* actually be deactivated.
*
* Must be balanced to calls of snd_usb_endpoint_start().
*
* The caller needs to synchronize the pending stop operation via
* snd_usb_endpoint_sync_pending_stop().
*/
void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep)
{
if (!ep)
return;
if (snd_BUG_ON(ep->use_count == 0))
return;
if (--ep->use_count == 0) {
deactivate_urbs(ep, false);
set_bit(EP_FLAG_STOPPING, &ep->flags);
}
}
/**
* snd_usb_endpoint_deactivate: deactivate an snd_usb_endpoint
*
* @ep: the endpoint to deactivate
*
* If the endpoint is not currently in use, this functions will
* deactivate its associated URBs.
*
* In case of any active users, this functions does nothing.
*/
void snd_usb_endpoint_deactivate(struct snd_usb_endpoint *ep)
{
if (!ep)
return;
if (ep->use_count != 0)
return;
deactivate_urbs(ep, true);
wait_clear_urbs(ep);
}
/**
* snd_usb_endpoint_release: Tear down an snd_usb_endpoint
*
* @ep: the endpoint to release
*
* This function does not care for the endpoint's use count but will tear
* down all the streaming URBs immediately.
*/
void snd_usb_endpoint_release(struct snd_usb_endpoint *ep)
{
release_urbs(ep, 1);
}
/**
* snd_usb_endpoint_free: Free the resources of an snd_usb_endpoint
*
* @ep: the endpoint to free
*
* This free all resources of the given ep.
*/
void snd_usb_endpoint_free(struct snd_usb_endpoint *ep)
{
kfree(ep);
}
/**
* snd_usb_handle_sync_urb: parse an USB sync packet
*
* @ep: the endpoint to handle the packet
* @sender: the sending endpoint
* @urb: the received packet
*
* This function is called from the context of an endpoint that received
* the packet and is used to let another endpoint object handle the payload.
*/
void snd_usb_handle_sync_urb(struct snd_usb_endpoint *ep,
struct snd_usb_endpoint *sender,
const struct urb *urb)
{
int shift;
unsigned int f;
unsigned long flags;
snd_BUG_ON(ep == sender);
/*
* In case the endpoint is operating in implicit feedback mode, prepare
* a new outbound URB that has the same layout as the received packet
* and add it to the list of pending urbs. queue_pending_output_urbs()
* will take care of them later.
*/
if (snd_usb_endpoint_implicit_feedback_sink(ep) &&
ep->use_count != 0) {
/* implicit feedback case */
int i, bytes = 0;
struct snd_urb_ctx *in_ctx;
struct snd_usb_packet_info *out_packet;
in_ctx = urb->context;
/* Count overall packet size */
for (i = 0; i < in_ctx->packets; i++)
if (urb->iso_frame_desc[i].status == 0)
bytes += urb->iso_frame_desc[i].actual_length;
/*
* skip empty packets. At least M-Audio's Fast Track Ultra stops
* streaming once it received a 0-byte OUT URB
*/
if (bytes == 0)
return;
spin_lock_irqsave(&ep->lock, flags);
out_packet = ep->next_packet + ep->next_packet_write_pos;
/*
* Iterate through the inbound packet and prepare the lengths
* for the output packet. The OUT packet we are about to send
* will have the same amount of payload bytes per stride as the
* IN packet we just received. Since the actual size is scaled
* by the stride, use the sender stride to calculate the length
* in case the number of channels differ between the implicitly
* fed-back endpoint and the synchronizing endpoint.
*/
out_packet->packets = in_ctx->packets;
for (i = 0; i < in_ctx->packets; i++) {
if (urb->iso_frame_desc[i].status == 0)
out_packet->packet_size[i] =
urb->iso_frame_desc[i].actual_length / sender->stride;
else
out_packet->packet_size[i] = 0;
}
ep->next_packet_write_pos++;
ep->next_packet_write_pos %= MAX_URBS;
spin_unlock_irqrestore(&ep->lock, flags);
queue_pending_output_urbs(ep);
return;
}
/*
* process after playback sync complete
*
* Full speed devices report feedback values in 10.14 format as samples
* per frame, high speed devices in 16.16 format as samples per
* microframe.
*
* Because the Audio Class 1 spec was written before USB 2.0, many high
* speed devices use a wrong interpretation, some others use an
* entirely different format.
*
* Therefore, we cannot predict what format any particular device uses
* and must detect it automatically.
*/
if (urb->iso_frame_desc[0].status != 0 ||
urb->iso_frame_desc[0].actual_length < 3)
return;
f = le32_to_cpup(urb->transfer_buffer);
if (urb->iso_frame_desc[0].actual_length == 3)
f &= 0x00ffffff;
else
f &= 0x0fffffff;
if (f == 0)
return;
if (unlikely(sender->tenor_fb_quirk)) {
/*
* Devices based on Tenor 8802 chipsets (TEAC UD-H01
* and others) sometimes change the feedback value
* by +/- 0x1.0000.
*/
if (f < ep->freqn - 0x8000)
f += 0xf000;
else if (f > ep->freqn + 0x8000)
f -= 0xf000;
} else if (unlikely(ep->freqshift == INT_MIN)) {
/*
* The first time we see a feedback value, determine its format
* by shifting it left or right until it matches the nominal
* frequency value. This assumes that the feedback does not
* differ from the nominal value more than +50% or -25%.
*/
shift = 0;
while (f < ep->freqn - ep->freqn / 4) {
f <<= 1;
shift++;
}
while (f > ep->freqn + ep->freqn / 2) {
f >>= 1;
shift--;
}
ep->freqshift = shift;
} else if (ep->freqshift >= 0)
f <<= ep->freqshift;
else
f >>= -ep->freqshift;
if (likely(f >= ep->freqn - ep->freqn / 8 && f <= ep->freqmax)) {
/*
* If the frequency looks valid, set it.
* This value is referred to in prepare_playback_urb().
*/
spin_lock_irqsave(&ep->lock, flags);
ep->freqm = f;
spin_unlock_irqrestore(&ep->lock, flags);
} else {
/*
* Out of range; maybe the shift value is wrong.
* Reset it so that we autodetect again the next time.
*/
ep->freqshift = INT_MIN;
}
}