2019-05-27 09:55:05 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2010-03-04 21:46:13 +03:00
/*
*/
2011-09-14 14:46:57 +04:00
# include <linux/gfp.h>
# include <linux/init.h>
2012-01-09 14:37:20 +04:00
# include <linux/ratelimit.h>
2011-09-14 14:46:57 +04:00
# include <linux/usb.h>
# include <linux/usb/audio.h>
2012-04-12 15:51:11 +04:00
# include <linux/slab.h>
2011-09-14 14:46:57 +04:00
# include <sound/core.h>
# include <sound/pcm.h>
2012-04-12 15:51:11 +04:00
# include <sound/pcm_params.h>
2011-09-14 14:46:57 +04:00
# include "usbaudio.h"
# include "helper.h"
# include "card.h"
# include "endpoint.h"
# include "pcm.h"
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
# include "clock.h"
2012-09-04 12:23:07 +04:00
# include "quirks.h"
2011-09-14 14:46:57 +04:00
2021-02-06 23:30:51 +03:00
enum {
EP_STATE_STOPPED ,
EP_STATE_RUNNING ,
EP_STATE_STOPPING ,
} ;
2012-04-12 15:51:11 +04:00
2021-01-08 10:52:17 +03:00
/* interface refcounting */
struct snd_usb_iface_ref {
unsigned char iface ;
bool need_setup ;
int opened ;
2022-10-09 13:42:09 +03:00
int altset ;
2021-01-08 10:52:17 +03:00
struct list_head list ;
} ;
2022-05-16 13:48:07 +03:00
/* clock refcounting */
struct snd_usb_clock_ref {
unsigned char clock ;
atomic_t locked ;
2022-09-20 21:11:26 +03:00
int opened ;
2022-05-16 13:48:07 +03:00
int rate ;
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
bool need_setup ;
2022-05-16 13:48:07 +03:00
struct list_head list ;
} ;
2012-04-12 15:51:15 +04:00
/*
* 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
2012-04-24 21:31:24 +04:00
* optional callbacks to let the pcm logic handle the actual content of the
2012-04-12 15:51:15 +04:00
* packets for playback and record . Thus , the bus streaming and the audio
* handlers are fully decoupled .
*
2012-04-24 21:31:24 +04:00
* There are two different types of endpoints in audio applications .
2012-04-12 15:51:15 +04:00
*
* SND_USB_ENDPOINT_TYPE_DATA handles full audio data payload for both
* inbound and outbound traffic .
*
2012-04-24 21:31:24 +04:00
* 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 ) .
2012-04-12 15:51:15 +04:00
*
2012-04-24 21:31:24 +04:00
* Each endpoint has to be configured prior to being used by calling
* snd_usb_endpoint_set_params ( ) .
2012-04-12 15:51:15 +04:00
*
* 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
2012-04-24 21:31:24 +04:00
* one to stop it will tear the URBs down again .
2012-04-12 15:51:15 +04:00
*/
2011-09-14 14:46:57 +04:00
/*
* 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 )
{
2022-09-30 13:01:29 +03:00
if ( u - > urb & & u - > buffer_size )
2012-04-12 15:51:13 +04:00
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 ;
2022-09-30 13:01:29 +03:00
u - > buffer_size = 0 ;
2011-09-14 14:46:57 +04:00
}
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 " ;
}
}
2021-02-06 23:30:51 +03:00
static inline bool ep_state_running ( struct snd_usb_endpoint * ep )
{
return atomic_read ( & ep - > state ) = = EP_STATE_RUNNING ;
}
static inline bool ep_state_update ( struct snd_usb_endpoint * ep , int old , int new )
{
2022-07-13 18:19:46 +03:00
return atomic_try_cmpxchg ( & ep - > state , & old , new ) ;
2021-02-06 23:30:51 +03:00
}
2012-04-12 15:51:15 +04:00
/**
* snd_usb_endpoint_implicit_feedback_sink : Report endpoint usage type
*
2012-04-24 21:31:24 +04:00
* @ ep : The snd_usb_endpoint
2012-04-12 15:51:15 +04:00
*
* Determine whether an endpoint is driven by an implicit feedback
* data endpoint source .
*/
2013-04-04 01:18:52 +04:00
int snd_usb_endpoint_implicit_feedback_sink ( struct snd_usb_endpoint * ep )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
return ep - > implicit_fb_sync & & usb_pipeout ( ep - > pipe ) ;
2012-04-12 15:51:11 +04:00
}
2012-04-12 15:51:15 +04:00
/*
2020-11-23 11:53:37 +03:00
* Return the number of samples to be sent in the next packet
* for streaming based on information derived from sync endpoints
2012-04-12 15:51:15 +04:00
*
2020-11-23 11:53:37 +03:00
* This won ' t be used for implicit feedback which takes the packet size
* returned from the sync source
2012-04-12 15:51:15 +04:00
*/
2021-09-29 11:08:41 +03:00
static int slave_next_packet_size ( struct snd_usb_endpoint * ep ,
unsigned int avail )
2012-04-12 15:51:11 +04:00
{
unsigned long flags ;
2021-09-29 11:08:41 +03:00
unsigned int phase ;
2012-04-12 15:51:11 +04:00
int ret ;
if ( ep - > fill_max )
return ep - > maxframesize ;
spin_lock_irqsave ( & ep - > lock , flags ) ;
2021-09-29 11:08:41 +03:00
phase = ( ep - > phase & 0xffff ) + ( ep - > freqm < < ep - > datainterval ) ;
ret = min ( phase > > 16 , ep - > maxframesize ) ;
if ( avail & & ret > = avail )
ret = - EAGAIN ;
else
ep - > phase = phase ;
2012-04-12 15:51:11 +04:00
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
return ret ;
}
2020-04-24 05:24:48 +03:00
/*
2020-11-23 11:53:37 +03:00
* Return the number of samples to be sent in the next packet
* for adaptive and synchronous endpoints
2020-04-24 05:24:48 +03:00
*/
2021-09-29 11:08:41 +03:00
static int next_packet_size ( struct snd_usb_endpoint * ep , unsigned int avail )
2020-04-24 05:24:48 +03:00
{
2021-09-29 11:08:41 +03:00
unsigned int sample_accum ;
2020-04-24 05:24:48 +03:00
int ret ;
if ( ep - > fill_max )
return ep - > maxframesize ;
2021-10-01 13:54:25 +03:00
sample_accum = ep - > sample_accum + ep - > sample_rem ;
2021-09-29 11:08:41 +03:00
if ( sample_accum > = ep - > pps ) {
sample_accum - = ep - > pps ;
2020-06-29 05:59:34 +03:00
ret = ep - > packsize [ 1 ] ;
2020-04-24 05:24:48 +03:00
} else {
2020-06-29 05:59:34 +03:00
ret = ep - > packsize [ 0 ] ;
2020-04-24 05:24:48 +03:00
}
2021-09-29 11:08:41 +03:00
if ( avail & & ret > = avail )
ret = - EAGAIN ;
else
ep - > sample_accum = sample_accum ;
2020-04-24 05:24:48 +03:00
return ret ;
}
2020-11-23 11:53:37 +03:00
/*
* snd_usb_endpoint_next_packet_size : Return the number of samples to be sent
* in the next packet
2021-09-29 11:08:41 +03:00
*
* If the size is equal or exceeds @ avail , don ' t proceed but return - EAGAIN
* Exception : @ avail = 0 for skipping the check .
2020-11-23 11:53:37 +03:00
*/
int snd_usb_endpoint_next_packet_size ( struct snd_usb_endpoint * ep ,
2021-09-29 11:08:41 +03:00
struct snd_urb_ctx * ctx , int idx ,
unsigned int avail )
2020-11-23 11:53:37 +03:00
{
2021-09-29 11:08:41 +03:00
unsigned int packet ;
packet = ctx - > packet_size [ idx ] ;
if ( packet ) {
if ( avail & & packet > = avail )
return - EAGAIN ;
return packet ;
}
if ( ep - > sync_source )
return slave_next_packet_size ( ep , avail ) ;
2020-11-23 11:53:37 +03:00
else
2021-09-29 11:08:41 +03:00
return next_packet_size ( ep , avail ) ;
2020-11-23 11:53:37 +03:00
}
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
static void call_retire_callback ( struct snd_usb_endpoint * ep ,
struct urb * urb )
{
struct snd_usb_substream * data_subs ;
data_subs = READ_ONCE ( ep - > data_subs ) ;
if ( data_subs & & ep - > retire_data_urb )
ep - > retire_data_urb ( data_subs , urb ) ;
}
2012-04-12 15:51:11 +04:00
static void retire_outbound_urb ( struct snd_usb_endpoint * ep ,
struct snd_urb_ctx * urb_ctx )
{
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
call_retire_callback ( ep , urb_ctx - > urb ) ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
static void snd_usb_handle_sync_urb ( struct snd_usb_endpoint * ep ,
struct snd_usb_endpoint * sender ,
const struct urb * urb ) ;
2012-04-12 15:51:11 +04:00
static void retire_inbound_urb ( struct snd_usb_endpoint * ep ,
struct snd_urb_ctx * urb_ctx )
{
struct urb * urb = urb_ctx - > urb ;
2020-11-23 11:53:39 +03:00
struct snd_usb_endpoint * sync_sink ;
2012-04-12 15:51:11 +04:00
2012-09-04 12:23:07 +04:00
if ( unlikely ( ep - > skip_packets > 0 ) ) {
ep - > skip_packets - - ;
return ;
}
2020-11-23 11:53:39 +03:00
sync_sink = READ_ONCE ( ep - > sync_sink ) ;
if ( sync_sink )
snd_usb_handle_sync_urb ( sync_sink , ep , urb ) ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
call_retire_callback ( ep , urb ) ;
2012-04-12 15:51:11 +04:00
}
2021-07-29 10:38:50 +03:00
static inline bool has_tx_length_quirk ( struct snd_usb_audio * chip )
{
return chip - > quirk_flags & QUIRK_FLAG_TX_LENGTH ;
}
2015-10-19 09:52:51 +03:00
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 09:52:53 +03:00
unsigned int extra = 0 ;
__le32 packet_length ;
2015-10-19 09:52:51 +03:00
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 09:52:53 +03:00
/* For tx_length_quirk, put packet length at start of packet */
2021-07-29 10:38:50 +03:00
if ( has_tx_length_quirk ( ep - > chip ) )
ALSA: USB-audio: Add quirk for Zoom R16/24 playback
The Zoom R16/24 have a nonstandard playback format where each isochronous
packet contains a length descriptor in the first four bytes. (Curiously,
capture data does not contain this and requires no quirk.)
The quirk involves adding the extra length descriptor whenever outgoing
isochronous packets are generated, both in pcm.c (outgoing audio) and
endpoint.c (silent data).
In order to make the quirk as unintrusive as possible, for
pcm.c:prepare_playback_urb(), the isochronous packet descriptors are
initially set up in the same way no matter if the quirk is enabled or not.
Once it is time to actually copy the data into the outgoing packet buffer
(together with the added length descriptors) the isochronous descriptors
are adjusted in order take the increased payload length into account.
For endpoint.c:prepare_silent_urb() it makes more sense to modify the
actual function, partly because the function is less complex to start with
and partly because it is not as time-critical as prepare_playback_urb()
(whose bulk is run with interrupts disabled), so the (minute) additional
time spent in the non-quirk case is motivated by the simplicity of having
a single function for all cases.
The quirk is controlled by the new tx_length_quirk member in struct
snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c
and endpoint.c from quirks.c in a similar manner to the txfr_quirk member
in the same structs.
In contrast to txfr_quirk however, the quirk is enabled directly in
quirks.c:create_standard_audio_quirk() by checking the USB ID in that
function. Another option would be to introduce a new
QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk
very plain to see in the quirk table, but it was felt that the additional
code needed to implement it this way would just make the implementation
more complex with no real gain.
Tested with a Zoom R16, both by doing capture and playback separately
using arecord and aplay (8 channel capture and 2 channel playback,
respectively), as well as capture and playback together using Ardour, as
well as Audacity and Qtractor together with jackd.
The R24 is reportedly compatible with the R16 when used as an audio
interface. Both devices share the same USB ID and have the same number of
inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the
patch.
Regression tested using an Edirol UA-5 in both class compliant (16-bit)
and "advanced" (24 bit, forces the use of quirks) modes.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Tested-by: Panu Matilainen <pmatilai@laiskiainen.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-10-19 09:52:53 +03:00
extra = sizeof ( packet_length ) ;
2015-10-19 09:52:51 +03:00
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 09:52:53 +03:00
unsigned int offset ;
unsigned int length ;
2015-10-19 09:52:51 +03:00
int counts ;
2021-09-29 11:08:41 +03:00
counts = snd_usb_endpoint_next_packet_size ( ep , ctx , i , 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 09:52:53 +03: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 ) ;
2015-10-19 09:52:51 +03:00
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 09:52:53 +03:00
urb - > transfer_buffer_length = offs * ep - > stride + ctx - > packets * extra ;
ALSA: usb-audio: Refactoring delay account code
The PCM delay accounting in USB-audio driver is a bit complex to
follow, and this is an attempt to improve the readability and provide
some potential fix.
Basically, the PCM position delay is calculated from two factors: the
in-flight data on URBs and the USB frame counter. For the playback
stream, we advance the hwptr already at submitting URBs. Those
"in-flight" data amount is now tracked, and this is used as the base
value for the PCM delay correction. The in-flight data is decreased
again at URB completion in return. For the capture stream, OTOH,
there is no in-flight data, hence the delay base is zero.
The USB frame counter is used in addition for correcting the current
position. The reference frame counter is updated at each submission
and receiving time, and the difference from the current counter value
is taken into account.
In this patch, each in-flight data bytes is recorded in the new
snd_usb_ctx.queued field, and the total in-flight amount is tracked in
snd_usb_substream.inflight_bytes field, as the replacement of
last_delay field.
Note that updating the hwptr after URB completion doesn't work for
PulseAudio who tries to scratch the buffer on the fly; USB-audio is
basically a double-buffer implementation, hence the scratching the
buffer can't work for the already submitted data. So we always update
hwptr beforehand. It's not ideal, but the delay account should give
enough correctness.
Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-06-01 19:24:55 +03:00
ctx - > queued = 0 ;
2015-10-19 09:52:51 +03:00
}
2012-04-12 15:51:11 +04:00
/*
* Prepare a PLAYBACK urb for submission to the bus .
*/
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
static int prepare_outbound_urb ( struct snd_usb_endpoint * ep ,
struct snd_urb_ctx * ctx ,
bool in_stream_lock )
2012-04-12 15:51:11 +04:00
{
struct urb * urb = ctx - > urb ;
unsigned char * cp = urb - > transfer_buffer ;
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
struct snd_usb_substream * data_subs ;
2012-04-12 15:51:11 +04:00
urb - > dev = ep - > chip - > dev ; /* we need to set this at each time */
switch ( ep - > type ) {
case SND_USB_ENDPOINT_TYPE_DATA :
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
data_subs = READ_ONCE ( ep - > data_subs ) ;
if ( data_subs & & ep - > prepare_data_urb )
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
return ep - > prepare_data_urb ( data_subs , urb , in_stream_lock ) ;
/* no data provider, so send silence */
prepare_silent_urb ( ep , ctx ) ;
2012-04-12 15:51:11 +04:00
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 ;
}
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
}
/*
* Prepare a CAPTURE or SYNC urb for submission to the bus .
*/
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
static int prepare_inbound_urb ( struct snd_usb_endpoint * ep ,
struct snd_urb_ctx * urb_ctx )
2012-04-12 15:51:11 +04:00
{
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 ;
}
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
}
2020-11-23 11:53:32 +03:00
/* notify an error as XRUN to the assigned PCM data substream */
static void notify_xrun ( struct snd_usb_endpoint * ep )
{
struct snd_usb_substream * data_subs ;
data_subs = READ_ONCE ( ep - > data_subs ) ;
if ( data_subs & & data_subs - > pcm_substream )
snd_pcm_stop_xrun ( data_subs - > pcm_substream ) ;
}
static struct snd_usb_packet_info *
next_packet_fifo_enqueue ( struct snd_usb_endpoint * ep )
{
struct snd_usb_packet_info * p ;
p = ep - > next_packet + ( ep - > next_packet_head + ep - > next_packet_queued ) %
ARRAY_SIZE ( ep - > next_packet ) ;
ep - > next_packet_queued + + ;
return p ;
}
static struct snd_usb_packet_info *
next_packet_fifo_dequeue ( struct snd_usb_endpoint * ep )
{
struct snd_usb_packet_info * p ;
p = ep - > next_packet + ep - > next_packet_head ;
ep - > next_packet_head + + ;
ep - > next_packet_head % = ARRAY_SIZE ( ep - > next_packet ) ;
ep - > next_packet_queued - - ;
return p ;
}
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
static void push_back_to_ready_list ( struct snd_usb_endpoint * ep ,
struct snd_urb_ctx * ctx )
{
unsigned long flags ;
spin_lock_irqsave ( & ep - > lock , flags ) ;
list_add_tail ( & ctx - > ready_list , & ep - > ready_playback_urbs ) ;
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
}
2012-04-12 15:51:15 +04:00
/*
2012-04-24 21:31:24 +04:00
* Send output urbs that have been prepared previously . URBs are dequeued
2020-10-05 22:12:44 +03:00
* from ep - > ready_playback_urbs and in case there aren ' t any available
2012-04-12 15:51:15 +04:00
* or there are no packets that have been prepared , this function does
* nothing .
*
2012-04-24 21:31:24 +04:00
* 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 .
2012-04-12 15:51:15 +04:00
*
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
* This function is used both for implicit feedback endpoints and in low -
* latency playback mode .
2012-04-12 15:51:15 +04:00
*/
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
int snd_usb_queue_pending_output_urbs ( struct snd_usb_endpoint * ep ,
bool in_stream_lock )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
bool implicit_fb = snd_usb_endpoint_implicit_feedback_sink ( ep ) ;
2021-02-06 23:30:51 +03:00
while ( ep_state_running ( ep ) ) {
2012-04-12 15:51:11 +04:00
unsigned long flags ;
treewide: Remove uninitialized_var() usage
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:
git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.
No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.
[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/
Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-03 23:09:38 +03:00
struct snd_usb_packet_info * packet ;
2012-04-12 15:51:11 +04:00
struct snd_urb_ctx * ctx = NULL ;
int err , i ;
spin_lock_irqsave ( & ep - > lock , flags ) ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
if ( ( ! implicit_fb | | ep - > next_packet_queued > 0 ) & &
2020-11-23 11:53:32 +03:00
! list_empty ( & ep - > ready_playback_urbs ) ) {
2012-04-12 15:51:11 +04:00
/* take URB out of FIFO */
2020-11-23 11:53:32 +03:00
ctx = list_first_entry ( & ep - > ready_playback_urbs ,
2012-04-12 15:51:11 +04:00
struct snd_urb_ctx , ready_list ) ;
2020-11-23 11:53:32 +03:00
list_del_init ( & ctx - > ready_list ) ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
if ( implicit_fb )
packet = next_packet_fifo_dequeue ( ep ) ;
2012-04-12 15:51:11 +04:00
}
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
if ( ctx = = NULL )
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
break ;
2012-04-12 15:51:11 +04:00
/* copy over the length information */
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
if ( implicit_fb ) {
for ( i = 0 ; i < packet - > packets ; i + + )
ctx - > packet_size [ i ] = packet - > packet_size [ i ] ;
}
2012-04-12 15:51:11 +04:00
2012-04-12 15:51:15 +04:00
/* call the data handler to fill in playback data */
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
err = prepare_outbound_urb ( ep , ctx , in_stream_lock ) ;
/* can be stopped during prepare callback */
if ( unlikely ( ! ep_state_running ( ep ) ) )
break ;
if ( err < 0 ) {
/* push back to ready list again for -EAGAIN */
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
if ( err = = - EAGAIN ) {
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
push_back_to_ready_list ( ep , ctx ) ;
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
break ;
}
if ( ! in_stream_lock )
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
notify_xrun ( ep ) ;
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
return - EPIPE ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
}
2012-04-12 15:51:11 +04:00
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) )
err = usb_submit_urb ( ctx - > urb , GFP_ATOMIC ) ;
else
err = - ENODEV ;
2020-11-23 11:53:32 +03:00
if ( err < 0 ) {
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) ) {
usb_audio_err ( ep - > chip ,
" Unable to submit urb #%d: %d at %s \n " ,
ctx - > index , err , __func__ ) ;
if ( ! in_stream_lock )
notify_xrun ( ep ) ;
}
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
return - EPIPE ;
2020-11-23 11:53:32 +03:00
}
set_bit ( ctx - > index , & ep - > active_mask ) ;
2021-09-29 11:08:37 +03:00
atomic_inc ( & ep - > submitted_urbs ) ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Fix recursive locking at XRUN during syncing
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-03-20 17:28:38 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
}
/*
* 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 ;
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 17:09:00 +03:00
urb - > status = = - ESHUTDOWN ) ) /* device disabled */
goto exit_clear ;
/* device disconnected */
if ( unlikely ( atomic_read ( & ep - > chip - > shutdown ) ) )
2012-04-12 15:51:11 +04:00
goto exit_clear ;
2021-02-06 23:30:51 +03:00
if ( unlikely ( ! ep_state_running ( ep ) ) )
2017-01-05 01:37:47 +03:00
goto exit_clear ;
2012-04-12 15:51:11 +04:00
if ( usb_pipeout ( ep - > pipe ) ) {
retire_outbound_urb ( ep , ctx ) ;
/* can be stopped during retire callback */
2021-02-06 23:30:51 +03:00
if ( unlikely ( ! ep_state_running ( ep ) ) )
2012-04-12 15:51:11 +04:00
goto exit_clear ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
/* in low-latency and implicit-feedback modes, push back the
* URB to ready list at first , then process as much as possible
*/
if ( ep - > lowlatency_playback | |
snd_usb_endpoint_implicit_feedback_sink ( ep ) ) {
push_back_to_ready_list ( ep , ctx ) ;
2020-11-23 11:53:32 +03:00
clear_bit ( ctx - > index , & ep - > active_mask ) ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
snd_usb_queue_pending_output_urbs ( ep , false ) ;
2021-09-29 11:08:37 +03:00
atomic_dec ( & ep - > submitted_urbs ) ; /* decrement at last */
2020-11-23 11:53:32 +03:00
return ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
/* in non-lowlatency mode, no error handling for prepare */
prepare_outbound_urb ( ep , ctx , false ) ;
2019-11-13 05:14:19 +03:00
/* can be stopped during prepare callback */
2021-02-06 23:30:51 +03:00
if ( unlikely ( ! ep_state_running ( ep ) ) )
2019-11-13 05:14:19 +03:00
goto exit_clear ;
2012-04-12 15:51:11 +04:00
} else {
retire_inbound_urb ( ep , ctx ) ;
/* can be stopped during retire callback */
2021-02-06 23:30:51 +03:00
if ( unlikely ( ! ep_state_running ( ep ) ) )
2012-04-12 15:51:11 +04:00
goto exit_clear ;
prepare_inbound_urb ( ep , ctx ) ;
}
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) )
err = usb_submit_urb ( urb , GFP_ATOMIC ) ;
else
err = - ENODEV ;
2012-04-12 15:51:11 +04:00
if ( err = = 0 )
return ;
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) ) {
usb_audio_err ( ep - > chip , " cannot submit urb (err = %d) \n " , err ) ;
notify_xrun ( ep ) ;
}
2012-04-12 15:51:11 +04:00
exit_clear :
clear_bit ( ctx - > index , & ep - > active_mask ) ;
2021-09-29 11:08:37 +03:00
atomic_dec ( & ep - > submitted_urbs ) ;
2012-04-12 15:51:11 +04:00
}
2021-01-08 10:52:17 +03:00
/*
* Find or create a refcount object for the given interface
*
* The objects are released altogether in snd_usb_endpoint_free_all ( )
*/
static struct snd_usb_iface_ref *
iface_ref_find ( struct snd_usb_audio * chip , int iface )
{
struct snd_usb_iface_ref * ip ;
list_for_each_entry ( ip , & chip - > iface_ref_list , list )
if ( ip - > iface = = iface )
return ip ;
ip = kzalloc ( sizeof ( * ip ) , GFP_KERNEL ) ;
if ( ! ip )
return NULL ;
ip - > iface = iface ;
list_add_tail ( & ip - > list , & chip - > iface_ref_list ) ;
return ip ;
}
2022-05-16 13:48:07 +03:00
/* Similarly, a refcount object for clock */
static struct snd_usb_clock_ref *
clock_ref_find ( struct snd_usb_audio * chip , int clock )
{
struct snd_usb_clock_ref * ref ;
list_for_each_entry ( ref , & chip - > clock_ref_list , list )
if ( ref - > clock = = clock )
return ref ;
ref = kzalloc ( sizeof ( * ref ) , GFP_KERNEL ) ;
if ( ! ref )
return NULL ;
ref - > clock = clock ;
atomic_set ( & ref - > locked , 0 ) ;
list_add_tail ( & ref - > list , & chip - > clock_ref_list ) ;
return ref ;
}
2020-11-23 11:53:11 +03:00
/*
2020-11-23 11:53:20 +03:00
* Get the existing endpoint object corresponding EP
2020-11-23 11:53:11 +03:00
* Returns NULL if not present .
*/
struct snd_usb_endpoint *
2020-11-23 11:53:20 +03:00
snd_usb_get_endpoint ( struct snd_usb_audio * chip , int ep_num )
2020-11-23 11:53:11 +03:00
{
struct snd_usb_endpoint * ep ;
list_for_each_entry ( ep , & chip - > ep_list , list ) {
2020-11-23 11:53:20 +03:00
if ( ep - > ep_num = = ep_num )
2020-11-23 11:53:11 +03:00
return ep ;
}
2020-11-23 11:53:20 +03:00
2020-11-23 11:53:11 +03:00
return NULL ;
}
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
# define ep_type_name(type) \
( type = = SND_USB_ENDPOINT_TYPE_DATA ? " data " : " sync " )
2012-04-12 15:51:15 +04:00
/**
2012-04-24 21:31:24 +04:00
* snd_usb_add_endpoint : Add an endpoint to an USB audio chip
2012-04-12 15:51:15 +04:00
*
* @ chip : The chip
* @ ep_num : The number of the endpoint to use
* @ 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 ,
2020-11-23 11:53:20 +03:00
* a new instance is created .
*
* Returns zero on success or a negative error code .
2012-04-12 15:51:15 +04:00
*
2021-01-08 10:52:17 +03:00
* New endpoints will be added to chip - > ep_list and freed by
* calling snd_usb_endpoint_free_all ( ) .
2016-03-15 17:20:58 +03:00
*
* For SND_USB_ENDPOINT_TYPE_SYNC , the caller needs to guarantee that
* bNumEndpoints > 1 beforehand .
2012-04-12 15:51:15 +04:00
*/
2020-11-23 11:53:20 +03:00
int snd_usb_add_endpoint ( struct snd_usb_audio * chip , int ep_num , int type )
2012-04-12 15:51:11 +04:00
{
struct snd_usb_endpoint * ep ;
2020-11-23 11:53:20 +03:00
bool is_playback ;
2013-08-03 12:51:15 +04:00
2020-11-23 11:53:20 +03:00
ep = snd_usb_get_endpoint ( chip , ep_num ) ;
if ( ep )
return 0 ;
2012-04-12 15:51:11 +04:00
2020-11-23 11:53:20 +03:00
usb_audio_dbg ( chip , " Creating new %s endpoint #%x \n " ,
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
ep_type_name ( type ) ,
ep_num ) ;
2012-04-12 15:51:11 +04:00
ep = kzalloc ( sizeof ( * ep ) , GFP_KERNEL ) ;
if ( ! ep )
2020-11-23 11:53:20 +03:00
return - ENOMEM ;
2012-04-12 15:51:11 +04:00
ep - > chip = chip ;
spin_lock_init ( & ep - > lock ) ;
ep - > type = type ;
ep - > ep_num = ep_num ;
INIT_LIST_HEAD ( & ep - > ready_playback_urbs ) ;
2021-09-29 11:08:37 +03:00
atomic_set ( & ep - > submitted_urbs , 0 ) ;
2012-04-12 15:51:11 +04:00
2020-11-23 11:53:20 +03:00
is_playback = ( ( ep_num & USB_ENDPOINT_DIR_MASK ) = = USB_DIR_OUT ) ;
ep_num & = USB_ENDPOINT_NUMBER_MASK ;
2012-04-12 15:51:11 +04:00
if ( is_playback )
ep - > pipe = usb_sndisocpipe ( chip - > dev , ep_num ) ;
else
ep - > pipe = usb_rcvisocpipe ( chip - > dev , ep_num ) ;
2020-11-23 11:53:20 +03:00
list_add_tail ( & ep - > list , & chip - > ep_list ) ;
return 0 ;
}
/* Set up syncinterval and maxsyncsize for a sync EP */
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
static void endpoint_set_syncinterval ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
2020-11-23 11:53:20 +03:00
{
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
struct usb_host_interface * alts ;
struct usb_endpoint_descriptor * desc ;
alts = snd_usb_get_host_interface ( chip , ep - > iface , ep - > altsetting ) ;
if ( ! alts )
return ;
desc = get_endpoint ( alts , ep - > ep_idx ) ;
if ( desc - > bLength > = USB_DT_ENDPOINT_AUDIO_SIZE & &
desc - > bRefresh > = 1 & & desc - > bRefresh < = 9 )
ep - > syncinterval = desc - > bRefresh ;
else if ( snd_usb_get_speed ( chip - > dev ) = = USB_SPEED_FULL )
ep - > syncinterval = 1 ;
else if ( desc - > bInterval > = 1 & & desc - > bInterval < = 16 )
ep - > syncinterval = desc - > bInterval - 1 ;
else
ep - > syncinterval = 3 ;
ep - > syncmaxsize = le16_to_cpu ( desc - > wMaxPacketSize ) ;
}
static bool endpoint_compatible ( struct snd_usb_endpoint * ep ,
const struct audioformat * fp ,
const struct snd_pcm_hw_params * params )
{
if ( ! ep - > opened )
return false ;
if ( ep - > cur_audiofmt ! = fp )
return false ;
if ( ep - > cur_rate ! = params_rate ( params ) | |
ep - > cur_format ! = params_format ( params ) | |
ep - > cur_period_frames ! = params_period_size ( params ) | |
ep - > cur_buffer_periods ! = params_periods ( params ) )
return false ;
return true ;
}
/*
2021-07-05 15:00:52 +03:00
* Check whether the given fp and hw params are compatible with the current
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
* setup of the target EP for implicit feedback sync
*/
bool snd_usb_endpoint_compatible ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep ,
const struct audioformat * fp ,
const struct snd_pcm_hw_params * params )
{
bool ret ;
mutex_lock ( & chip - > mutex ) ;
ret = endpoint_compatible ( ep , fp , params ) ;
mutex_unlock ( & chip - > mutex ) ;
return ret ;
}
/*
* snd_usb_endpoint_open : Open the endpoint
*
* Called from hw_params to assign the endpoint to the substream .
* It ' s reference - counted , and only the first opener is allowed to set up
* arbitrary parameters . The later opener must be compatible with the
* former opened parameters .
* The endpoint needs to be closed via snd_usb_endpoint_close ( ) later .
*
* Note that this function doesn ' t configure the endpoint . The substream
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
* needs to set it up later via snd_usb_endpoint_set_params ( ) and
* snd_usb_endpoint_prepare ( ) .
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
*/
struct snd_usb_endpoint *
snd_usb_endpoint_open ( struct snd_usb_audio * chip ,
2020-11-23 11:53:33 +03:00
const struct audioformat * fp ,
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
const struct snd_pcm_hw_params * params ,
2022-12-15 18:30:37 +03:00
bool is_sync_ep ,
bool fixed_rate )
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
{
struct snd_usb_endpoint * ep ;
int ep_num = is_sync_ep ? fp - > sync_ep : fp - > endpoint ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
mutex_lock ( & chip - > mutex ) ;
ep = snd_usb_get_endpoint ( chip , ep_num ) ;
if ( ! ep ) {
usb_audio_err ( chip , " Cannot find EP 0x%x to open \n " , ep_num ) ;
goto unlock ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( ! ep - > opened ) {
if ( is_sync_ep ) {
ep - > iface = fp - > sync_iface ;
ep - > altsetting = fp - > sync_altsetting ;
ep - > ep_idx = fp - > sync_ep_idx ;
} else {
ep - > iface = fp - > iface ;
ep - > altsetting = fp - > altsetting ;
2021-01-08 10:52:18 +03:00
ep - > ep_idx = fp - > ep_idx ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
}
usb_audio_dbg ( chip , " Open EP 0x%x, iface=%d:%d, idx=%d \n " ,
ep_num , ep - > iface , ep - > altsetting , ep - > ep_idx ) ;
2021-01-08 10:52:17 +03:00
ep - > iface_ref = iface_ref_find ( chip , ep - > iface ) ;
if ( ! ep - > iface_ref ) {
ep = NULL ;
goto unlock ;
}
2022-05-16 13:48:07 +03:00
if ( fp - > protocol ! = UAC_VERSION_1 ) {
ep - > clock_ref = clock_ref_find ( chip , fp - > clock ) ;
if ( ! ep - > clock_ref ) {
ep = NULL ;
goto unlock ;
}
2022-09-20 21:11:26 +03:00
ep - > clock_ref - > opened + + ;
2022-05-16 13:48:07 +03:00
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > cur_audiofmt = fp ;
ep - > cur_channels = fp - > channels ;
ep - > cur_rate = params_rate ( params ) ;
ep - > cur_format = params_format ( params ) ;
ep - > cur_frame_bytes = snd_pcm_format_physical_width ( ep - > cur_format ) *
ep - > cur_channels / 8 ;
ep - > cur_period_frames = params_period_size ( params ) ;
ep - > cur_period_bytes = ep - > cur_period_frames * ep - > cur_frame_bytes ;
ep - > cur_buffer_periods = params_periods ( params ) ;
if ( ep - > type = = SND_USB_ENDPOINT_TYPE_SYNC )
endpoint_set_syncinterval ( chip , ep ) ;
ep - > implicit_fb_sync = fp - > implicit_fb ;
ep - > need_setup = true ;
2022-10-09 13:42:12 +03:00
ep - > need_prepare = true ;
2022-12-15 18:30:37 +03:00
ep - > fixed_rate = fixed_rate ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " channels=%d, rate=%d, format=%s, period_bytes=%d, periods=%d, implicit_fb=%d \n " ,
ep - > cur_channels , ep - > cur_rate ,
snd_pcm_format_name ( ep - > cur_format ) ,
ep - > cur_period_bytes , ep - > cur_buffer_periods ,
ep - > implicit_fb_sync ) ;
} else {
2021-01-08 10:52:17 +03:00
if ( WARN_ON ( ! ep - > iface_ref ) ) {
ep = NULL ;
goto unlock ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( ! endpoint_compatible ( ep , fp , params ) ) {
usb_audio_err ( chip , " Incompatible EP setup for 0x%x \n " ,
ep_num ) ;
ep = NULL ;
goto unlock ;
}
usb_audio_dbg ( chip , " Reopened EP 0x%x (count %d) \n " ,
ep_num , ep - > opened ) ;
}
2021-01-08 10:52:17 +03:00
if ( ! ep - > iface_ref - > opened + + )
ep - > iface_ref - > need_setup = true ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > opened + + ;
unlock :
mutex_unlock ( & chip - > mutex ) ;
return ep ;
}
/*
* snd_usb_endpoint_set_sync : Link data and sync endpoints
*
* Pass NULL to sync_ep to unlink again
*/
void snd_usb_endpoint_set_sync ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * data_ep ,
struct snd_usb_endpoint * sync_ep )
{
2020-11-23 11:53:39 +03:00
data_ep - > sync_source = sync_ep ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
/*
* Set data endpoint callbacks and the assigned data stream
*
* Called at PCM trigger and cleanups .
* Pass NULL to deactivate each callback .
*/
void snd_usb_endpoint_set_callback ( struct snd_usb_endpoint * ep ,
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
int ( * prepare ) ( struct snd_usb_substream * subs ,
struct urb * urb ,
bool in_stream_lock ) ,
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
void ( * retire ) ( struct snd_usb_substream * subs ,
struct urb * urb ) ,
struct snd_usb_substream * data_subs )
{
ep - > prepare_data_urb = prepare ;
ep - > retire_data_urb = retire ;
2021-09-29 11:08:38 +03:00
if ( data_subs )
ep - > lowlatency_playback = data_subs - > lowlatency_playback ;
else
ep - > lowlatency_playback = false ;
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
WRITE_ONCE ( ep - > data_subs , data_subs ) ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
static int endpoint_set_interface ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep ,
bool set )
{
int altset = set ? ep - > altsetting : 0 ;
int err ;
2022-10-09 13:42:09 +03:00
if ( ep - > iface_ref - > altset = = altset )
return 0 ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " Setting usb interface %d:%d for EP 0x%x \n " ,
ep - > iface , altset , ep - > ep_num ) ;
err = usb_set_interface ( chip - > dev , ep - > iface , altset ) ;
if ( err < 0 ) {
2023-04-21 17:38:41 +03:00
usb_audio_err_ratelimited (
chip , " %d:%d: usb_set_interface failed (%d) \n " ,
ep - > iface , altset , err ) ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
return err ;
}
2021-07-29 10:38:55 +03:00
if ( chip - > quirk_flags & QUIRK_FLAG_IFACE_DELAY )
msleep ( 50 ) ;
2022-10-09 13:42:09 +03:00
ep - > iface_ref - > altset = altset ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
return 0 ;
}
/*
* snd_usb_endpoint_close : Close the endpoint
*
* Unreference the already opened endpoint via snd_usb_endpoint_open ( ) .
*/
void snd_usb_endpoint_close ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
{
mutex_lock ( & chip - > mutex ) ;
usb_audio_dbg ( chip , " Closing EP 0x%x (count %d) \n " ,
ep - > ep_num , ep - > opened ) ;
2021-01-08 10:52:17 +03:00
2022-11-10 09:34:52 +03:00
if ( ! - - ep - > iface_ref - > opened & &
! ( chip - > quirk_flags & QUIRK_FLAG_IFACE_SKIP_CLOSE ) )
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
endpoint_set_interface ( chip , ep , false ) ;
2021-01-08 10:52:17 +03:00
if ( ! - - ep - > opened ) {
2022-09-20 21:11:26 +03:00
if ( ep - > clock_ref ) {
if ( ! - - ep - > clock_ref - > opened )
ep - > clock_ref - > rate = 0 ;
}
2020-11-23 11:53:40 +03:00
ep - > iface = 0 ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > altsetting = 0 ;
ep - > cur_audiofmt = NULL ;
ep - > cur_rate = 0 ;
2021-01-08 10:52:17 +03:00
ep - > iface_ref = NULL ;
2022-05-16 13:48:07 +03:00
ep - > clock_ref = NULL ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " EP 0x%x closed \n " , ep - > ep_num ) ;
}
mutex_unlock ( & chip - > mutex ) ;
}
/* Prepare for suspening EP, called from the main suspend handler */
void snd_usb_endpoint_suspend ( struct snd_usb_endpoint * ep )
{
2022-10-09 13:42:12 +03:00
ep - > need_prepare = true ;
2021-01-08 10:52:17 +03:00
if ( ep - > iface_ref )
ep - > iface_ref - > need_setup = true ;
2022-05-16 13:48:07 +03:00
if ( ep - > clock_ref )
ep - > clock_ref - > rate = 0 ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
}
2012-04-12 15:51:11 +04:00
/*
* 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 ;
2021-02-06 23:30:51 +03:00
if ( atomic_read ( & ep - > state ) ! = EP_STATE_STOPPING )
2020-11-23 11:53:35 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
do {
2021-09-29 11:08:37 +03:00
alive = atomic_read ( & ep - > submitted_urbs ) ;
2012-04-12 15:51:11 +04:00
if ( ! alive )
break ;
schedule_timeout_uninterruptible ( 1 ) ;
} while ( time_before ( jiffies , end_time ) ) ;
if ( alive )
2014-02-26 16:02:17 +04:00
usb_audio_err ( ep - > chip ,
" timeout: still %d active urbs on EP #%x \n " ,
alive , ep - > ep_num ) ;
2012-04-12 15:51:11 +04:00
2021-02-06 23:30:51 +03:00
if ( ep_state_update ( ep , EP_STATE_STOPPING , EP_STATE_STOPPED ) ) {
ep - > sync_sink = NULL ;
snd_usb_endpoint_set_callback ( ep , NULL , NULL , NULL ) ;
}
2017-01-05 01:37:46 +03:00
2012-04-12 15:51:11 +04:00
return 0 ;
}
2012-11-08 11:52:45 +04:00
/* 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 )
{
2020-11-23 11:53:35 +03:00
if ( ep )
2012-11-08 11:52:45 +04:00
wait_clear_urbs ( ep ) ;
}
2012-04-12 15:51:11 +04:00
/*
2021-02-06 23:30:50 +03:00
* Stop active urbs
2020-11-23 11:53:35 +03:00
*
2021-02-06 23:30:50 +03:00
* This function moves the EP to STOPPING state if it ' s being RUNNING .
2012-04-12 15:51:11 +04:00
*/
2021-09-29 11:08:44 +03:00
static int stop_urbs ( struct snd_usb_endpoint * ep , bool force , bool keep_pending )
2012-04-12 15:51:11 +04:00
{
unsigned int i ;
2021-09-29 11:08:42 +03:00
unsigned long flags ;
2012-04-12 15:51:11 +04:00
2021-02-06 23:30:50 +03:00
if ( ! force & & atomic_read ( & ep - > running ) )
2020-11-23 11:53:35 +03:00
return - EBUSY ;
2021-02-06 23:30:51 +03:00
if ( ! ep_state_update ( ep , EP_STATE_RUNNING , EP_STATE_STOPPING ) )
2021-02-06 23:30:50 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
2021-09-29 11:08:42 +03:00
spin_lock_irqsave ( & ep - > lock , flags ) ;
2012-04-12 15:51:11 +04:00
INIT_LIST_HEAD ( & ep - > ready_playback_urbs ) ;
2020-11-23 11:53:32 +03:00
ep - > next_packet_head = 0 ;
ep - > next_packet_queued = 0 ;
2021-09-29 11:08:42 +03:00
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
2012-04-12 15:51:11 +04:00
2021-09-29 11:08:44 +03:00
if ( keep_pending )
return 0 ;
2012-04-12 15:51:11 +04:00
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 ;
2012-11-21 11:22:52 +04:00
usb_unlink_urb ( u ) ;
2012-04-12 15:51:11 +04:00
}
}
}
return 0 ;
}
/*
* release an endpoint ' s urbs
*/
2021-02-06 23:30:50 +03:00
static int release_urbs ( struct snd_usb_endpoint * ep , bool force )
2012-04-12 15:51:11 +04:00
{
2021-02-06 23:30:50 +03:00
int i , err ;
2012-04-12 15:51:11 +04:00
/* route incoming urbs to nirvana */
ALSA: usb-audio: Set callbacks via snd_usb_endpoint_set_callback()
The prepare_data_urb and retire_data_urb fields of the endpoint object
are set dynamically at PCM trigger start/stop. Those are evaluated in
the endpoint handler, but there can be a race, especially if two
different PCM substreams are handling the same endpoint for the
implicit feedback case. Also, the data_subs field of the endpoint is
set and accessed dynamically, too, which has the same risk.
As a slight improvement for the concurrency, this patch introduces the
function to set the callbacks and the data in a shot with the memory
barrier. In the reader side, it's also fetched with the memory
barrier.
There is still a room of race if prepare and retire callbacks are set
during executing the URB completion. But such an inconsistency may
happen only for the implicit fb source, i.e. it's only about the
capture stream. And luckily, the capture stream never sets the
prepare callback, hence the problem doesn't happen practically.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-23-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:28 +03:00
snd_usb_endpoint_set_callback ( ep , NULL , NULL , NULL ) ;
2012-04-12 15:51:11 +04:00
2021-02-06 23:30:50 +03:00
/* stop and unlink urbs */
2021-09-29 11:08:44 +03:00
err = stop_urbs ( ep , force , false ) ;
2021-02-06 23:30:50 +03:00
if ( err )
return err ;
wait_clear_urbs ( ep ) ;
2012-04-12 15:51:11 +04:00
for ( i = 0 ; i < ep - > nurbs ; i + + )
release_urb_ctx ( & ep - > urb [ i ] ) ;
2020-07-27 05:52:08 +03:00
usb_free_coherent ( ep - > chip - > dev , SYNC_URBS * 4 ,
ep - > syncbuf , ep - > sync_dma ) ;
2012-04-12 15:51:11 +04:00
ep - > syncbuf = NULL ;
ep - > nurbs = 0 ;
2021-02-06 23:30:50 +03:00
return 0 ;
2012-04-12 15:51:11 +04:00
}
2012-04-12 15:51:15 +04:00
/*
* configure a data endpoint
*/
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
static int data_ep_set_params ( struct snd_usb_endpoint * ep )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
struct snd_usb_audio * chip = ep - > chip ;
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
unsigned int 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 ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
const struct audioformat * fmt = ep - > cur_audiofmt ;
int frame_bits = ep - > cur_frame_bytes * 8 ;
2021-07-29 10:38:50 +03:00
int tx_length_quirk = ( has_tx_length_quirk ( chip ) & &
2015-10-19 09:52:54 +03:00
usb_pipeout ( ep - > pipe ) ) ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " Setting params for data EP 0x%x, pipe 0x%x \n " ,
ep - > ep_num , ep - > pipe ) ;
if ( ep - > cur_format = = SNDRV_PCM_FORMAT_DSD_U16_LE & & fmt - > dsd_dop ) {
2013-04-16 20:01:38 +04:00
/*
* 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 .
*/
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
frame_bits + = ep - > cur_channels < < 3 ;
2013-04-16 20:01:38 +04:00
}
2012-04-12 15:51:11 +04:00
ep - > datainterval = fmt - > datainterval ;
ep - > stride = frame_bits > > 3 ;
2016-12-12 20:52:58 +03:00
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
switch ( ep - > cur_format ) {
2016-12-12 20:52:58 +03:00
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 ;
}
2012-04-12 15:51:11 +04:00
2016-12-06 08:46:14 +03:00
/* 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-11 21:54:51 +03: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 ) ;
2015-10-19 09:52:54 +03:00
if ( tx_length_quirk )
maxsize + = sizeof ( __le32 ) ; /* Space for length descriptor */
2013-08-08 13:24:55 +04:00
/* but wMaxPacketSize might reduce this */
if ( ep - > maxpacksize & & ep - > maxpacksize < maxsize ) {
2012-04-12 15:51:11 +04:00
/* whatever fits into a max. size packet */
2015-10-19 09:52:54 +03:00
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 ) )
2012-04-12 15:51:11 +04:00
< < ( 16 - ep - > datainterval ) ;
}
if ( ep - > fill_max )
ep - > curpacksize = ep - > maxpacksize ;
else
ep - > curpacksize = maxsize ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( snd_usb_get_speed ( chip - > dev ) ! = USB_SPEED_FULL ) {
2012-04-12 15:51:11 +04:00
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-24 23:51:58 +04:00
max_packs_per_urb = MAX_PACKS_HS ;
2012-04-12 15:51:11 +04:00
} 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-24 23:51:58 +04:00
packs_per_ms = 1 ;
max_packs_per_urb = MAX_PACKS ;
2012-04-12 15:51:11 +04:00
}
2020-11-23 11:53:39 +03:00
if ( ep - > sync_source & & ! ep - > implicit_fb_sync )
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
max_packs_per_urb = min ( max_packs_per_urb ,
2020-11-23 11:53:39 +03:00
1U < < ep - > sync_source - > syncinterval ) ;
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
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 .
*/
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( usb_pipein ( ep - > pipe ) | | ep - > implicit_fb_sync ) {
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
/* make capture URBs <= 1 ms and smaller than a period */
2023-03-13 01:28:57 +03:00
urb_packs = min ( max_packs_per_urb , packs_per_ms ) ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
while ( urb_packs > 1 & & urb_packs * maxsize > = ep - > cur_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-24 23:51:58 +04:00
urb_packs > > = 1 ;
ep - > nurbs = MAX_URBS ;
2012-04-12 15:51:11 +04:00
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
/*
* 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 {
2012-04-12 15:51:11 +04:00
/* 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-24 23:51:58 +04:00
minsize = ( ep - > freqn > > ( 16 - ep - > datainterval ) ) *
( frame_bits > > 3 ) ;
2012-04-12 15:51:11 +04:00
/* with sync from device, assume it can be 12% lower */
2020-11-23 11:53:39 +03:00
if ( ep - > sync_source )
2012-04-12 15:51:11 +04:00
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-24 23:51:58 +04:00
/* how many packets will contain an entire ALSA period? */
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
max_packs_per_period = DIV_ROUND_UP ( ep - > cur_period_bytes , minsize ) ;
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are
determined for PCM playback in the snd-usb-audio driver. Currently
the driver allocates too few URBs for endpoints that don't use
implicit sync, making underruns more likely to occur. This may be a
holdover from before I/O delays could be measured accurately; in any
case, it is no longer necessary.
The patch allocates as many URBs as possible, subject to four
limitations:
The total number of URBs for the endpoint is not allowed to
exceed MAX_URBS (which the patch increases from 8 to 12).
The total number of packets per URB is not allowed to exceed
MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is
decreased from 20 to 6.
The total duration of queued data is not allowed to exceed
MAX_QUEUE, which is decreased from 24 ms to 18 ms.
The total number of ALSA frames in the output queue is not
allowed to exceed the ALSA buffer size.
The last requirement is the hardest to implement. Currently the
number of URBs needed to fill a buffer cannot be determined in
advance, because a buffer contains a fixed number of frames whereas
the number of frames in an URB varies to match shifts in the device's
clock rate. To solve this problem, the patch changes the logic for
deciding how many packets an URB should contain. Rather than using as
many as possible without exceeding an ALSA period boundary, now the
driver uses only as many packets as needed to transfer a predetermined
number of frames. As a result, unless the device's clock has an
exceedingly variable rate, the number of URBs making up each period
(and hence each buffer) will remain constant.
The overall effect of the patch is that playback works better in
low-latency settings. The user can still specify values for
frames/period and periods/buffer that exceed the capabilities of the
hardware, of course. But for values that are within those
capabilities, the performance will be improved. For example, testing
shows that a high-speed device can handle 32 frames/period and 3
periods/buffer at 48 KHz, whereas the current driver starts to get
glitchy at 64 frames/period and 2 periods/buffer.
A side effect of these changes is that the "nrpacks" module parameter
is no longer used. The patch removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Daniel Mack <zonque@gmail.com>
Tested-by: Eldad Zack <eldad@fogrefinery.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2013-09-24 23:51:58 +04:00
/* 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 */
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > max_urb_frames = DIV_ROUND_UP ( ep - > cur_period_frames ,
urbs_per_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-24 23:51:58 +04:00
/* try to use enough URBs to contain an entire ALSA buffer */
max_urbs = min ( ( unsigned ) MAX_URBS ,
MAX_QUEUE * packs_per_ms / urb_packs ) ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > nurbs = min ( max_urbs , urbs_per_period * ep - > cur_buffer_periods ) ;
2012-04-12 15:51:11 +04:00
}
/* 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-24 23:51:58 +04:00
u - > packets = urb_packs ;
2012-04-12 15:51:11 +04:00
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 =
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_alloc_coherent ( chip - > dev , u - > buffer_size ,
2012-04-12 15:51:11 +04:00
GFP_KERNEL , & u - > urb - > transfer_dma ) ;
if ( ! u - > urb - > transfer_buffer )
goto out_of_memory ;
u - > urb - > pipe = ep - > pipe ;
2013-04-27 14:10:32 +04:00
u - > urb - > transfer_flags = URB_NO_TRANSFER_DMA_MAP ;
2012-04-12 15:51:11 +04:00
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 :
2021-02-06 23:30:50 +03:00
release_urbs ( ep , false ) ;
2012-04-12 15:51:11 +04:00
return - ENOMEM ;
}
2012-04-12 15:51:15 +04:00
/*
* configure a sync endpoint
*/
2013-10-07 00:31:06 +04:00
static int sync_ep_set_params ( struct snd_usb_endpoint * ep )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
struct snd_usb_audio * chip = ep - > chip ;
2012-04-12 15:51:11 +04:00
int i ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " Setting params for sync EP 0x%x, pipe 0x%x \n " ,
ep - > ep_num , ep - > pipe ) ;
ep - > syncbuf = usb_alloc_coherent ( chip - > dev , SYNC_URBS * 4 ,
2012-04-12 15:51:11 +04:00
GFP_KERNEL , & ep - > sync_dma ) ;
if ( ! ep - > syncbuf )
return - ENOMEM ;
2022-09-30 13:01:51 +03:00
ep - > nurbs = SYNC_URBS ;
2012-04-12 15:51:11 +04:00
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 ;
2013-04-27 14:10:32 +04:00
u - > urb - > transfer_flags = URB_NO_TRANSFER_DMA_MAP ;
2012-04-12 15:51:11 +04:00
u - > urb - > number_of_packets = 1 ;
u - > urb - > interval = 1 < < ep - > syncinterval ;
u - > urb - > context = u ;
u - > urb - > complete = snd_complete_urb ;
}
return 0 ;
out_of_memory :
2021-02-06 23:30:50 +03:00
release_urbs ( ep , false ) ;
2012-04-12 15:51:11 +04:00
return - ENOMEM ;
}
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
/* update the rate of the referred clock; return the actual rate */
static int update_clock_ref_rate ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
{
struct snd_usb_clock_ref * clock = ep - > clock_ref ;
int rate = ep - > cur_rate ;
if ( ! clock | | clock - > rate = = rate )
return rate ;
if ( clock - > rate ) {
if ( atomic_read ( & clock - > locked ) )
return clock - > rate ;
if ( clock - > rate ! = rate ) {
usb_audio_err ( chip , " Mismatched sample rate %d vs %d for EP 0x%x \n " ,
clock - > rate , rate , ep - > ep_num ) ;
return clock - > rate ;
}
}
clock - > rate = rate ;
clock - > need_setup = true ;
return rate ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
/*
2012-04-24 21:31:24 +04:00
* snd_usb_endpoint_set_params : configure an snd_usb_endpoint
2012-04-12 15:51:15 +04:00
*
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
* It ' s called either from hw_params callback .
2012-04-24 21:31:24 +04:00
* Determine the number of URBs to be used on this endpoint .
2012-04-12 15:51:15 +04:00
* An endpoint must be configured before it can be started .
* An endpoint that is already running can not be reconfigured .
*/
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
int snd_usb_endpoint_set_params ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
const struct audioformat * fmt = ep - > cur_audiofmt ;
2022-10-09 13:42:12 +03:00
int err = 0 ;
2012-04-12 15:51:11 +04:00
2022-10-09 13:42:10 +03:00
mutex_lock ( & chip - > mutex ) ;
2022-10-09 13:42:12 +03:00
if ( ! ep - > need_setup )
goto unlock ;
2012-04-12 15:51:11 +04:00
/* release old buffers, if any */
2021-02-06 23:30:50 +03:00
err = release_urbs ( ep , false ) ;
if ( err < 0 )
2022-10-09 13:42:10 +03:00
goto unlock ;
2012-04-12 15:51:11 +04:00
ep - > datainterval = fmt - > datainterval ;
ep - > maxpacksize = fmt - > maxpacksize ;
2012-04-13 14:41:54 +04:00
ep - > fill_max = ! ! ( fmt - > attributes & UAC_EP_CS_ATTR_FILL_MAX ) ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( snd_usb_get_speed ( chip - > dev ) = = USB_SPEED_FULL ) {
ep - > freqn = get_usb_full_speed_rate ( ep - > cur_rate ) ;
2020-06-29 05:59:34 +03:00
ep - > pps = 1000 > > ep - > datainterval ;
2020-04-24 05:24:48 +03:00
} else {
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > freqn = get_usb_high_speed_rate ( ep - > cur_rate ) ;
2020-06-29 05:59:34 +03:00
ep - > pps = 8000 > > ep - > datainterval ;
2020-04-24 05:24:48 +03:00
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
ep - > sample_rem = ep - > cur_rate % ep - > pps ;
ep - > packsize [ 0 ] = ep - > cur_rate / ep - > pps ;
ep - > packsize [ 1 ] = ( ep - > cur_rate + ( ep - > pps - 1 ) ) / ep - > pps ;
2012-04-12 15:51:11 +04:00
/* 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 :
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
err = data_ep_set_params ( ep ) ;
2012-04-12 15:51:11 +04:00
break ;
case SND_USB_ENDPOINT_TYPE_SYNC :
2013-10-07 00:31:06 +04:00
err = sync_ep_set_params ( ep ) ;
2012-04-12 15:51:11 +04:00
break ;
default :
err = - EINVAL ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( chip , " Set up %d URBS, ret=%d \n " , ep - > nurbs , err ) ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
if ( err < 0 )
2022-10-09 13:42:10 +03:00
goto unlock ;
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
/* some unit conversions in runtime */
ep - > maxframesize = ep - > maxpacksize / ep - > cur_frame_bytes ;
ep - > curframesize = ep - > curpacksize / ep - > cur_frame_bytes ;
ALSA: usb-audio: Add hw constraint for implicit fb sync
In the current code, there is no check at the stream open time whether
the endpoint is being already used by others. In the normal
operations, this shouldn't happen, but in the case of the implicit
feedback mode, it's a common problem with the full duplex operation,
because the capture stream is always opened by the playback stream as
an implicit sync source.
Although we recently introduced the check of such a conflict of
parameters at the PCM hw_params time, it doesn't give any hint at the
hw_params itself and just gives the error. This isn't quite
comfortable, and it caused problems on many applications.
This patch attempts to make the parameter handling easier by
introducing the strict hw constraint matching with the counterpart
stream that is being used. That said, when an implicit feedback
playback stream is running before a capture stream is opened, the
capture stream carries the PCM hw-constraint to allow only the same
sample rate, format, periods and period frames as the running playback
stream. If not opened or there is no conflict of endpoints, the
behavior remains as same as before.
Note that this kind of "weak link" should work for most cases, but
this is no concrete solution; e.g. if an application changes the hw
params multiple times while another stream is opened, this would lead
to inconsistencies.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:16 +03:00
2022-10-09 13:42:10 +03:00
err = update_clock_ref_rate ( chip , ep ) ;
2022-10-09 13:42:12 +03:00
if ( err > = 0 ) {
ep - > need_setup = false ;
2022-10-09 13:42:11 +03:00
err = 0 ;
2022-10-09 13:42:12 +03:00
}
2022-10-09 13:42:10 +03:00
unlock :
mutex_unlock ( & chip - > mutex ) ;
return err ;
2012-04-12 15:51:11 +04:00
}
2022-05-16 13:48:07 +03:00
static int init_sample_rate ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
{
struct snd_usb_clock_ref * clock = ep - > clock_ref ;
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
int rate , err ;
2022-05-16 13:48:07 +03:00
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
rate = update_clock_ref_rate ( chip , ep ) ;
if ( rate < 0 )
return rate ;
if ( clock & & ! clock - > need_setup )
return 0 ;
2022-05-16 13:48:07 +03:00
2022-12-15 18:30:37 +03:00
if ( ! ep - > fixed_rate ) {
err = snd_usb_init_sample_rate ( chip , ep - > cur_audiofmt , rate ) ;
if ( err < 0 ) {
if ( clock )
clock - > rate = 0 ; /* reset rate */
return err ;
}
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
}
2022-05-16 13:48:07 +03:00
if ( clock )
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
clock - > need_setup = false ;
2022-05-16 13:48:07 +03:00
return 0 ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
/*
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
* snd_usb_endpoint_prepare : Prepare the endpoint
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
*
* This function sets up the EP to be fully usable state .
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
* It ' s called either from prepare callback .
2021-07-05 15:00:52 +03:00
* The function checks need_setup flag , and performs nothing unless needed ,
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
* so it ' s safe to call this multiple times .
*
* This returns zero if unchanged , 1 if the configuration has changed ,
* or a negative error code .
*/
ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)
This is a second attempt to fix the bug appearing on Android with the
recent kernel; the first try was ff878b408a03 and reverted at commit
79764ec772bc.
The details taken from the v1 patch:
One of the former changes for the endpoint management was the more
consistent setup of endpoints at hw_params.
snd_usb_endpoint_configure() is a single function that does the full
setup, and it's called from both PCM hw_params and prepare callbacks.
Although the EP setup at the prepare phase is usually skipped (by
checking need_setup flag), it may be still effective in some cases
like suspend/resume that requires the interface setup again.
As it's a full and single setup, the invocation of
snd_usb_endpoint_configure() includes not only the USB interface setup
but also the buffer release and allocation. OTOH, doing the buffer
release and re-allocation at PCM prepare phase is rather superfluous,
and better to be done only in the hw_params phase.
For those optimizations, this patch splits the endpoint setup to two
phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
to be called from hw_params and from prepare, respectively.
Note that this patch changes the driver operation slightly,
effectively moving the USB interface setup again to PCM prepare stage
instead of hw_params stage, while the buffer allocation and such
initializations are still done at hw_params stage.
And, the change of the USB interface setup timing (moving to prepare)
gave an interesting "fix", too: it was reported that the recent
kernels caused silent output at the beginning on playbacks on some
devices on Android, and this change casually fixed the regression.
It seems that those devices are picky about the sample rate change (or
the interface change?), and don't follow the too immediate rate
changes.
Meanwhile, Android operates the PCM in the following order:
- open, then hw_params with the possibly highest sample rate
- close without prepare
- re-open, hw_params with the normal sample rate
- prepare, and start streaming
This procedure ended up the hw_params twice with different rates, and
because the recent kernel did set up the sample rate twice one and
after, it screwed up the device. OTOH, the earlier kernels didn't set
up the USB interface at hw_params, hence this problem didn't appear.
Now, with this patch, the USB interface setup is again back to the
prepare phase, and it works around the problem automagically.
Although we should address the sample rate problem in a more solid
way in future, let's keep things working as before for now.
***
What's new in the take#2 patch:
- The regression caused by the v1 patch (bko#216500) was due to the
missing check of need_setup flag at hw_params. Now the check is
added, and the snd_usb_endpoint_set_params() call is skipped when
the running EP is re-opened.
- There was another bug in v1 where the clock reference rate wasn't
updated at hw_params phase, which may lead to a lack of the proper
hw constraints when an application doesn't issue the prepare but
only the hw_params call. This patch fixes it as well by tracking
the clock rate change in the prepare callback with a new flag
"need_update" for the clock reference object, just like others.
- The configure_endpoints() are simplified and folded back into
snd_usb_pcm_prepare().
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare")
Reported-by: chihhao chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.de
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216500
Link: https://lore.kernel.org/r/20220920181106.4894-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2022-09-20 21:11:06 +03:00
int snd_usb_endpoint_prepare ( struct snd_usb_audio * chip ,
struct snd_usb_endpoint * ep )
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
{
bool iface_first ;
int err = 0 ;
mutex_lock ( & chip - > mutex ) ;
2021-01-08 10:52:17 +03:00
if ( WARN_ON ( ! ep - > iface_ref ) )
goto unlock ;
2022-10-09 13:42:12 +03:00
if ( ! ep - > need_prepare )
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
goto unlock ;
2021-01-08 10:52:17 +03:00
/* If the interface has been already set up, just set EP parameters */
if ( ! ep - > iface_ref - > need_setup ) {
2021-01-18 10:58:15 +03:00
/* sample rate setup of UAC1 is per endpoint, and we need
* to update at each EP configuration
*/
if ( ep - > cur_audiofmt - > protocol = = UAC_VERSION_1 ) {
2022-05-16 13:48:07 +03:00
err = init_sample_rate ( chip , ep ) ;
2021-01-18 10:58:15 +03:00
if ( err < 0 )
goto unlock ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
goto done ;
}
/* Need to deselect altsetting at first */
endpoint_set_interface ( chip , ep , false ) ;
/* Some UAC1 devices (e.g. Yamaha THR10) need the host interface
* to be set up before parameter setups
*/
iface_first = ep - > cur_audiofmt - > protocol = = UAC_VERSION_1 ;
2021-08-24 08:57:20 +03:00
/* Workaround for devices that require the interface setup at first like UAC1 */
if ( chip - > quirk_flags & QUIRK_FLAG_SET_IFACE_FIRST )
2021-08-24 08:47:00 +03:00
iface_first = true ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( iface_first ) {
err = endpoint_set_interface ( chip , ep , true ) ;
if ( err < 0 )
goto unlock ;
}
err = snd_usb_init_pitch ( chip , ep - > cur_audiofmt ) ;
if ( err < 0 )
goto unlock ;
2022-05-16 13:48:07 +03:00
err = init_sample_rate ( chip , ep ) ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
if ( err < 0 )
goto unlock ;
err = snd_usb_select_mode_quirk ( chip , ep - > cur_audiofmt ) ;
if ( err < 0 )
goto unlock ;
/* for UAC2/3, enable the interface altset here at last */
if ( ! iface_first ) {
err = endpoint_set_interface ( chip , ep , true ) ;
if ( err < 0 )
goto unlock ;
}
2021-01-08 10:52:17 +03:00
ep - > iface_ref - > need_setup = false ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
done :
2022-10-09 13:42:12 +03:00
ep - > need_prepare = false ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
err = 1 ;
unlock :
mutex_unlock ( & chip - > mutex ) ;
return err ;
}
2021-09-29 11:08:36 +03:00
/* get the current rate set to the given clock by any endpoint */
int snd_usb_endpoint_get_clock_rate ( struct snd_usb_audio * chip , int clock )
{
2022-05-16 13:48:07 +03:00
struct snd_usb_clock_ref * ref ;
2021-09-29 11:08:36 +03:00
int rate = 0 ;
if ( ! clock )
return 0 ;
mutex_lock ( & chip - > mutex ) ;
2022-05-16 13:48:07 +03:00
list_for_each_entry ( ref , & chip - > clock_ref_list , list ) {
if ( ref - > clock = = clock ) {
rate = ref - > rate ;
2021-09-29 11:08:36 +03:00
break ;
}
}
mutex_unlock ( & chip - > mutex ) ;
return rate ;
}
2012-04-12 15:51:15 +04:00
/**
* snd_usb_endpoint_start : start an snd_usb_endpoint
*
2017-01-05 01:37:46 +03:00
* @ ep : the endpoint to start
2012-04-12 15:51:15 +04:00
*
2020-11-23 11:53:34 +03:00
* A call to this function will increment the running count of the endpoint .
2012-04-24 21:31:24 +04:00
* In case it is not already running , the URBs for this endpoint will be
2012-04-12 15:51:15 +04:00
* 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 .
*/
2017-01-05 01:37:46 +03:00
int snd_usb_endpoint_start ( struct snd_usb_endpoint * ep )
2012-04-12 15:51:11 +04:00
{
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
bool is_playback = usb_pipeout ( ep - > pipe ) ;
2012-04-12 15:51:11 +04:00
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 17:09:00 +03:00
if ( atomic_read ( & ep - > chip - > shutdown ) )
2012-04-12 15:51:11 +04:00
return - EBADFD ;
2020-11-23 11:53:39 +03:00
if ( ep - > sync_source )
WRITE_ONCE ( ep - > sync_source - > sync_sink , ep ) ;
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
2020-11-23 11:53:34 +03:00
usb_audio_dbg ( ep - > chip , " Starting %s EP 0x%x (running %d) \n " ,
ep_type_name ( ep - > type ) , ep - > ep_num ,
atomic_read ( & ep - > running ) ) ;
2020-11-23 11:53:27 +03:00
2012-04-12 15:51:11 +04:00
/* already running? */
2020-11-23 11:53:34 +03:00
if ( atomic_inc_return ( & ep - > running ) ! = 1 )
2012-04-12 15:51:11 +04:00
return 0 ;
2022-05-16 13:48:07 +03:00
if ( ep - > clock_ref )
atomic_inc ( & ep - > clock_ref - > locked ) ;
2012-04-12 15:51:11 +04:00
ep - > active_mask = 0 ;
ep - > unlink_mask = 0 ;
ep - > phase = 0 ;
2020-04-24 05:24:48 +03:00
ep - > sample_accum = 0 ;
2012-04-12 15:51:11 +04:00
2012-09-04 12:23:07 +04:00
snd_usb_endpoint_start_quirk ( ep ) ;
2012-04-12 15:51:11 +04:00
/*
* If this endpoint has a data endpoint as implicit feedback source ,
* don ' t start the urbs here . Instead , mark them all as available ,
2012-04-24 21:31:24 +04:00
* wait for the record urbs to return and queue the playback urbs
* from that context .
2012-04-12 15:51:11 +04:00
*/
2021-02-06 23:30:51 +03:00
if ( ! ep_state_update ( ep , EP_STATE_STOPPED , EP_STATE_RUNNING ) )
goto __error ;
2012-04-12 15:51:11 +04:00
ALSA: usb-audio: Apply implicit feedback mode for BOSS devices
During the recent rewrite of the implicit feedback support, we've
tested to apply the implicit fb on BOSS devices, but it failed, as the
capture stream didn't start without the playback. As the end result,
it got another type of quirk for tying both streams but starts
playback always (commit 6234fdc1cede "ALSA: usb-audio: Quirk for BOSS
GT-001").
Meanwhile, Mike Oliphant has tested the real implicit feedback mode
for the playback again with the latest code, and found out that it
actually works if the initial feedback sync is skipped; that is, on
those BOSS devices, the playback stream has to be started at first
without waiting for the capture URB completions. Otherwise it gets
stuck. In the rest operations after the capture stream processed, we
can take them as the implicit feedback source.
This patch is an attempt to improve the support for BOSS devices with
the implicit feedback mode in the way described above. It adds a new
flag to snd_usb_audio, playback_first, indicating that the playback
stream starts without sync with the initial capture completion. This
flag is set in the quirk table with the new IMPLICIT_FB_BOTH type.
Reported-and-tested-by: Mike Oliphant <oliphant@nostatic.org>
Link: https://lore.kernel.org/r/20210414083255.9527-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-04-14 11:32:55 +03:00
if ( snd_usb_endpoint_implicit_feedback_sink ( ep ) & &
2021-07-29 10:38:51 +03:00
! ( ep - > chip - > quirk_flags & QUIRK_FLAG_PLAYBACK_FIRST ) ) {
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( ep - > chip , " No URB submission due to implicit fb sync \n " ) ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
i = 0 ;
goto fill_rest ;
2012-04-12 15:51:11 +04:00
}
for ( i = 0 ; i < ep - > nurbs ; i + + ) {
struct urb * urb = ep - > urb [ i ] . urb ;
if ( snd_BUG_ON ( ! urb ) )
goto __error ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
if ( is_playback )
err = prepare_outbound_urb ( ep , urb - > context , true ) ;
else
err = prepare_inbound_urb ( ep , urb - > context ) ;
if ( err < 0 ) {
/* stop filling at applptr */
if ( err = = - EAGAIN )
break ;
usb_audio_dbg ( ep - > chip ,
" EP 0x%x: failed to prepare urb: %d \n " ,
ep - > ep_num , err ) ;
goto __error ;
2012-04-12 15:51:11 +04:00
}
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) )
err = usb_submit_urb ( urb , GFP_ATOMIC ) ;
else
err = - ENODEV ;
2012-04-12 15:51:11 +04:00
if ( err < 0 ) {
2023-08-28 13:19:24 +03:00
if ( ! atomic_read ( & ep - > chip - > shutdown ) )
usb_audio_err ( ep - > chip ,
" cannot submit urb %d, error %d: %s \n " ,
i , err , usb_error_string ( err ) ) ;
2012-04-12 15:51:11 +04:00
goto __error ;
}
set_bit ( i , & ep - > active_mask ) ;
2021-09-29 11:08:37 +03:00
atomic_inc ( & ep - > submitted_urbs ) ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
if ( ! i ) {
usb_audio_dbg ( ep - > chip , " XRUN at starting EP 0x%x \n " ,
ep - > ep_num ) ;
goto __error ;
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
usb_audio_dbg ( ep - > chip , " %d URBs submitted for EP 0x%x \n " ,
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
i , ep - > ep_num ) ;
fill_rest :
/* put the remaining URBs to ready list */
if ( is_playback ) {
for ( ; i < ep - > nurbs ; i + + )
push_back_to_ready_list ( ep , ep - > urb + i ) ;
}
2012-04-12 15:51:11 +04:00
return 0 ;
__error :
2021-09-29 11:08:44 +03:00
snd_usb_endpoint_stop ( ep , false ) ;
2012-04-12 15:51:11 +04:00
return - EPIPE ;
}
2012-04-12 15:51:15 +04:00
/**
* snd_usb_endpoint_stop : stop an snd_usb_endpoint
*
* @ ep : the endpoint to stop ( may be NULL )
2021-09-29 11:08:44 +03:00
* @ keep_pending : keep in - flight URBs
2012-04-12 15:51:15 +04:00
*
2020-11-23 11:53:34 +03:00
* A call to this function will decrement the running count of the endpoint .
2012-04-12 15:51:15 +04:00
* In case the last user has requested the endpoint stop , the URBs will
2012-04-24 21:31:24 +04:00
* actually be deactivated .
2012-04-12 15:51:15 +04:00
*
* Must be balanced to calls of snd_usb_endpoint_start ( ) .
2012-11-21 11:30:48 +04:00
*
* The caller needs to synchronize the pending stop operation via
* snd_usb_endpoint_sync_pending_stop ( ) .
2012-04-12 15:51:15 +04:00
*/
2021-09-29 11:08:44 +03:00
void snd_usb_endpoint_stop ( struct snd_usb_endpoint * ep , bool keep_pending )
2012-04-12 15:51:11 +04:00
{
if ( ! ep )
return ;
2020-11-23 11:53:34 +03:00
usb_audio_dbg ( ep - > chip , " Stopping %s EP 0x%x (running %d) \n " ,
ep_type_name ( ep - > type ) , ep - > ep_num ,
atomic_read ( & ep - > running ) ) ;
2020-11-23 11:53:27 +03:00
2020-11-23 11:53:34 +03:00
if ( snd_BUG_ON ( ! atomic_read ( & ep - > running ) ) )
2012-04-12 15:51:11 +04:00
return ;
2021-04-26 09:33:49 +03:00
if ( ! atomic_dec_return ( & ep - > running ) ) {
if ( ep - > sync_source )
WRITE_ONCE ( ep - > sync_source - > sync_sink , NULL ) ;
2021-09-29 11:08:44 +03:00
stop_urbs ( ep , false , keep_pending ) ;
2022-05-16 13:48:07 +03:00
if ( ep - > clock_ref )
2022-09-20 21:11:26 +03:00
atomic_dec ( & ep - > clock_ref - > locked ) ;
2022-11-29 16:00:59 +03:00
if ( ep - > chip - > quirk_flags & QUIRK_FLAG_FORCE_IFACE_RESET & &
usb_pipeout ( ep - > pipe ) ) {
ep - > need_prepare = true ;
if ( ep - > iface_ref )
ep - > iface_ref - > need_setup = true ;
}
2021-04-26 09:33:49 +03:00
}
2012-04-12 15:51:11 +04:00
}
2014-06-25 16:24:47 +04:00
/**
* snd_usb_endpoint_release : Tear down an snd_usb_endpoint
*
* @ ep : the endpoint to release
*
2020-11-23 11:53:34 +03:00
* This function does not care for the endpoint ' s running count but will tear
2014-06-25 16:24:47 +04:00
* down all the streaming URBs immediately .
*/
void snd_usb_endpoint_release ( struct snd_usb_endpoint * ep )
{
2021-02-06 23:30:50 +03:00
release_urbs ( ep , true ) ;
2014-06-25 16:24:47 +04:00
}
2012-04-24 21:31:24 +04:00
/**
2021-01-08 10:52:17 +03:00
* snd_usb_endpoint_free_all : Free the resources of an snd_usb_endpoint
2021-02-05 11:28:37 +03:00
* @ chip : The chip
2012-04-12 15:51:15 +04:00
*
2021-01-08 10:52:17 +03:00
* This free all endpoints and those resources
2012-04-12 15:51:15 +04:00
*/
2021-01-08 10:52:17 +03:00
void snd_usb_endpoint_free_all ( struct snd_usb_audio * chip )
2012-04-12 15:51:11 +04:00
{
2021-01-08 10:52:17 +03:00
struct snd_usb_endpoint * ep , * en ;
struct snd_usb_iface_ref * ip , * in ;
2022-05-16 13:48:07 +03:00
struct snd_usb_clock_ref * cp , * cn ;
2021-01-08 10:52:17 +03:00
list_for_each_entry_safe ( ep , en , & chip - > ep_list , list )
kfree ( ep ) ;
list_for_each_entry_safe ( ip , in , & chip - > iface_ref_list , list )
kfree ( ip ) ;
2022-05-16 13:48:07 +03:00
list_for_each_entry_safe ( cp , cn , & chip - > clock_ref_list , list )
2022-05-18 05:16:16 +03:00
kfree ( cp ) ;
2012-04-12 15:51:11 +04:00
}
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
/*
2012-04-12 15:51:15 +04:00
* 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 .
2012-04-12 15:51:11 +04:00
*/
ALSA: usb-audio: Refactor endpoint management
This is an intensive surgery for the endpoint and stream management
for achieving more robust and clean code.
The goals of this patch are:
- More clear endpoint resource changes
- The interface altsetting control in a single place
Below are brief description of the whole changes.
First off, most of the endpoint operations are moved into endpoint.c,
so that the snd_usb_endpoint object is only referred in other places.
The endpoint object is acquired and released via the new functions
snd_usb_endpoint_open() and snd_usb_endpoint_close() that are called
at PCM hw_params and hw_free callbacks, respectively. Those are
ref-counted and EPs can manage the multiple opens.
The open callback receives the audioformat and hw_params arguments,
and those are used for initializing the EP parameters; especially the
endpoint, interface and altset numbers are read from there, as well as
the PCM parameters like the format, rate and channels. Those are
stored in snd_usb_endpoint object. If it's the secondary open, the
function checks whether the given parameters are compatible with the
already opened EP setup, too.
The coupling with a sync EP (including an implicit feedback sync) is
done by the sole snd_usb_endpoint_set_sync() call.
The configuration of each endpoint is done in a single shot via
snd_usb_endpoint_configure() call. This is the place where most of
PCM configurations are done. A few flags and special handling in the
snd_usb_substream are dropped along with this change.
A significant difference wrt the configuration from the previous code
is the order of USB host interface setups. Now the interface is
always disabled at beginning and (re-)enabled at the last step of
snd_usb_endpoint_configure(), in order to be compliant with the
standard UAC2/3. For UAC1, the interface is set before the parameter
setups since there seem devices that require it (e.g. Yamaha THR10),
just like how it was done in the previous driver code.
The start/stop are almost same as before, also single-shots. The URB
callbacks need to be set via snd_usb_endpoint_set_callback() like the
previous code at the trigger phase, too.
Finally, the flag for the re-setup is set at the device suspend
through the full EP list, instead of PCM trigger. This catches the
overlooked cases where the PCM hasn't been running yet but the device
needs the full setup after resume.
Tested-by: Keith Milner <kamilner@superlative.org>
Tested-by: Dylan Robinson <dylan_robinson@motu.com>
Link: https://lore.kernel.org/r/20201123085347.19667-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-11-23 11:53:31 +03:00
static void snd_usb_handle_sync_urb ( struct snd_usb_endpoint * ep ,
struct snd_usb_endpoint * sender ,
const struct urb * urb )
2012-04-12 15:51:11 +04:00
{
int shift ;
unsigned int f ;
unsigned long flags ;
snd_BUG_ON ( ep = = sender ) ;
2012-04-12 15:51:15 +04:00
/*
* In case the endpoint is operating in implicit feedback mode , prepare
2012-04-24 21:31:24 +04:00
* 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 .
2012-04-12 15:51:15 +04:00
*/
2013-04-04 01:18:52 +04:00
if ( snd_usb_endpoint_implicit_feedback_sink ( ep ) & &
2020-11-23 11:53:34 +03:00
atomic_read ( & ep - > running ) ) {
2012-04-12 15:51:11 +04:00
/* 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 ) ;
2020-11-23 11:53:32 +03:00
if ( ep - > next_packet_queued > = ARRAY_SIZE ( ep - > next_packet ) ) {
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
usb_audio_err ( ep - > chip ,
" next package FIFO overflow EP 0x%x \n " ,
ep - > ep_num ) ;
notify_xrun ( ep ) ;
return ;
}
out_packet = next_packet_fifo_enqueue ( ep ) ;
2012-04-12 15:51:11 +04:00
/*
* Iterate through the inbound packet and prepare the lengths
* for the output packet . The OUT packet we are about to send
2012-11-29 02:55:34 +04:00
* 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 .
2012-04-12 15:51:11 +04:00
*/
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 ] =
2012-11-29 02:55:34 +04:00
urb - > iso_frame_desc [ i ] . actual_length / sender - > stride ;
2012-04-12 15:51:11 +04:00
else
out_packet - > packet_size [ i ] = 0 ;
}
spin_unlock_irqrestore ( & ep - > lock , flags ) ;
ALSA: usb-audio: Improved lowlatency playback support
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily. In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.
Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode. The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold. The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs. In the complete
callback, we try to fill the data and submit as much as possible
again. When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition. In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.
The following things are changed to achieve the behavior above:
* The endpoint prepare callback is changed to return an error code;
when there is no enough data available, it may return -EAGAIN.
Currently only prepare_playback_urb() returns the error.
The evaluation of the available data is a bit messy here; we can't
check with snd_pcm_avail() at the point of prepare callback (as
runtime->status->hwptr hasn't been updated yet), hence we manually
estimate the appl_ptr and compare with the internal hwptr_done to
calculate the available frames.
* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
callback returns -EAGAIN, and puts the remaining URBs to the ready
list for the later submission.
* snd_complete_urb() treats the URBs in the low-latency mode similarly
like the implicit feedback mode, and submissions are done in
(now exported) snd_usb_queue_pending_output_urbs().
* snd_usb_queue_pending_output_urbs() again checks the error value
from the prepare callback. If it's -EAGAIN for the normal stream
(i.e. not implicit feedback mode), we push it back to the ready list
again.
* PCM ack callback is introduced for the playback stream, and it calls
snd_usb_queue_pending_output_urbs() if there is no in-flight URB
while the stream is running. This corresponds to the case where the
system needs the appl_ptr update for re-submitting a new URB.
* snd_usb_queue_pending_output_urbs() and the prepare EP callback
receive in_stream_lock argument, which is a bool flag indicating the
call path from PCM ack. It's needed for avoiding the deadlock of
snd_pcm_period_elapsed() calls.
* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
low-latency mode is deployed. This assures catching each applptr
update even in the mmap mode.
Fixes: 4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-09-29 11:08:43 +03:00
snd_usb_queue_pending_output_urbs ( ep , false ) ;
2012-04-12 15:51:11 +04:00
return ;
}
2012-04-12 15:51:15 +04:00
/*
* 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 .
*/
2012-04-12 15:51:11 +04:00
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 ;
2016-08-22 09:53:37 +03:00
if ( unlikely ( sender - > tenor_fb_quirk ) ) {
2014-05-01 14:20:22 +04:00
/*
2016-08-22 09:53:37 +03:00
* Devices based on Tenor 8802 chipsets ( TEAC UD - H01
* and others ) sometimes change the feedback value
2014-05-01 14:20:22 +04:00
* by + / - 0x1 .0000 .
*/
if ( f < ep - > freqn - 0x8000 )
2016-08-22 09:53:38 +03:00
f + = 0xf000 ;
2014-05-01 14:20:22 +04:00
else if ( f > ep - > freqn + 0x8000 )
2016-08-22 09:53:38 +03:00
f - = 0xf000 ;
2014-05-01 14:20:22 +04:00
} else if ( unlikely ( ep - > freqshift = = INT_MIN ) ) {
2012-04-12 15:51:11 +04:00
/*
* 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 ;
}
}