summaryrefslogtreecommitdiffstats
path: root/sound/usb/pcm.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: usb-audio: Fix broken resume due to UAC3 power stateTakashi Iwai2023-06-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | As reported in the bugzilla below, the PM resume of a UAC3 device may fail due to the incomplete power state change, stuck at D1. The reason is that the driver expects the full D0 power state change only at hw_params, while the normal PCM resume procedure doesn't call hw_params. For fixing the bug, we add the same power state update to D0 at the prepare callback, which is certainly called by the resume procedure. Note that, with this change, the power state change in the hw_params becomes almost redundant, since snd_usb_hw_params() doesn't touch the parameters (at least it tires so). But dropping it is still a bit risky (e.g. we have the media-driver binding), so I leave the D0 power state change in snd_usb_hw_params() as is for now. Fixes: a0a4959eb4e9 ("ALSA: usb-audio: Operate UAC3 Power Domains in PCM callbacks") Cc: <stable@vger.kernel.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217539 Link: https://lore.kernel.org/r/20230612132818.29486-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Fix recursive locking at XRUN during syncingTakashi Iwai2023-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ALSA: usb-audio: Fix possible NULL pointer dereference in ↵Jaroslav Kysela2023-01-131-1/+2
| | | | | | | | | | | | | snd_usb_pcm_has_fixed_rate() The subs function argument may be NULL, so do not use it before the NULL check. Fixes: 291e9da91403 ("ALSA: usb-audio: Always initialize fixed_rate in snd_usb_find_implicit_fb_sync_format()") Reported-by: coverity-bot <keescook@chromium.org> Link: https://lore.kernel.org/alsa-devel/202301121424.4A79A485@keescook/ Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230113085311.623325-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Always initialize fixed_rate in ↵Jaroslav Kysela2023-01-091-0/+2
| | | | | | | | | | | | | | snd_usb_find_implicit_fb_sync_format() Handle the fallback code path, too. Fixes: fd28941cff1c ("ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 Wireless") BugLink: https://lore.kernel.org/alsa-devel/Y7frf3N%2FxzvESEsN@kili/ Reported-by: Dan Carpenter <error27@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230109141133.335543-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: More refactoring of hw constraint rulesTakashi Iwai2023-01-041-87/+131
| | | | | | | | | | | | | | | | | | | Although we applied a workaround for the hw constraints code with the implicit feedback sync, it still has a potential problem. Namely, as the code treats only the first matching (sync) endpoint, it might be too restrictive when multiple endpoints are listed in the substream's format list. This patch is another attempt to improve the hw constraint handling for the implicit feedback sync. The code is rewritten and the sync EP handling for the rate and the format is put inside the fmt_list loop in each hw_rule_*() function instead of the additional rules. The rules for the period size and periods are extended to loop over the fmt_list like others, and they apply the constraints only if needed. Link: https://lore.kernel.org/r/4e509aea-e563-e592-e652-ba44af6733fe@veniogames.com Link: https://lore.kernel.org/r/20230102170759.29610-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Relax hw constraints for implicit fb syncTakashi Iwai2023-01-041-2/+7
| | | | | | | | | | | | | | | | | | | | | The fix commit the commit e4ea77f8e53f ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync") tried to address the bug where an incorrect PCM parameter is chosen when two (implicit fb) streams are set up at the same time. This change had, however, some side effect: once when the sync endpoint is chosen and set up, this restriction is applied at the next hw params unless it's freed via hw free explicitly. This patch is a workaround for the problem by relaxing the hw constraints a bit for the implicit fb sync. We still keep applying the hw constraints for implicit fb sync, but only when the matching sync EP is being used by other streams. Fixes: e4ea77f8e53f ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync") Reported-by: Ruud van Asseldonk <ruud@veniogames.com> Link: https://lore.kernel.org/r/4e509aea-e563-e592-e652-ba44af6733fe@veniogames.com Link: https://lore.kernel.org/r/20230102170759.29610-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Make sure to stop endpoints before closing EPsTakashi Iwai2023-01-041-0/+2
| | | | | | | | | | | | | | | | | | At the PCM hw params, we may re-configure the endpoints and it's done by a temporary EP close followed by re-open. A potential problem there is that the EP might be already running internally at the PCM prepare stage; it's seen typically in the playback stream with the implicit feedback sync. As this stream start isn't tracked by the core PCM layer, we'd need to stop it explicitly, and that's the missing piece. This patch adds the stop_endpoints() call at snd_usb_hw_params() to assure the stream stop before closing the EPs. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Link: https://lore.kernel.org/r/4e509aea-e563-e592-e652-ba44af6733fe@veniogames.com Link: https://lore.kernel.org/r/20230102170759.29610-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Add new quirk FIXED_RATE for JBL Quantum810 WirelessJaroslav Kysela2022-12-221-3/+33
| | | | | | | | | | | | | | It seems that the firmware is broken and does not accept the UAC_EP_CS_ATTR_SAMPLE_RATE URB. There is only one rate (48000Hz) available in the descriptors for the output endpoint. Create a new quirk QUIRK_FLAG_FIXED_RATE to skip the rate setup when only one rate is available (fixed). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216798 Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20221215153037.1163786-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Workaround for XRUN at prepareTakashi Iwai2022-12-051-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Under certain situations (typically in the implicit feedback mode), USB-audio driver starts a playback stream already at PCM prepare call even before the actual PCM trigger-START call. For implicit feedback mode, this effectively starts two streams for data and sync endpoints, and if a coupled sync stream gets XRUN at this point, it results in an error -EPIPE. The problem is that currently we return -EPIPE error as is from the prepare. Then application tries to recover again via the prepare call, but it'll fail again because the sync-stop is missing. The sync-stop is missing because it's an internal trigger call (hence the PCM core isn't involved). Since we'll need to re-issue the prepare in anyway when trapped into this pitfall, this patch attempts to address it in a bit different way; namely, the driver tries to prepare once again after syncing the stop manually by itself -- so applications don't see the internal error. At the second failure, we report the error as is, but this shouldn't happen in normal situations. Reported-and-tested-by: Carl Hetherington <lists@carlh.net> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net Link: https://lore.kernel.org/r/20221205132124.11585-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Replace runtime->status->state reference to runtime->stateTakashi Iwai2022-09-271-2/+2
| | | | | | | | | The recent change in ALSA core allows drivers to get the current PCM state directly from runtime object. Replace the calls accordingly. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220926135558.26580-8-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Split endpoint setups for hw_params and prepare (take#2)Takashi Iwai2022-09-201-31/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert "ALSA: usb-audio: Split endpoint setups for hw_params and prepare"Takashi Iwai2022-09-201-10/+4
| | | | | | | | | | | | | | | | This reverts commit ff878b408a03bef5d610b7e2302702e16a53636e. Unfortunately the recent fix seems bringing another regressions with PulseAudio / pipewire, at least for Steinberg and MOTU devices. As a temporary solution, do a straight revert. The issue for Android will be revisited again later by another different fix (if any). Fixes: ff878b408a03 ("ALSA: usb-audio: Split endpoint setups for hw_params and prepare") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216500 Link: https://lore.kernel.org/r/20220920113929.25162-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Split endpoint setups for hw_params and prepareTakashi Iwai2022-09-011-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") Cc: <stable@vger.kernel.org> 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 Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: make read-only array marker static constColin Ian King2022-08-101-1/+1
| | | | | | | | | Don't populate the read-only array marker on the stack but instead make it static const. Also makes the object code a little smaller. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220809181544.3046429-1-colin.i.king@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Set up (implicit) sync for Saffire 6Takashi Iwai2022-06-061-0/+3
| | | | | | | | | | | | | | | | | | | | | Focusrite Saffire 6 has fixed audioformat quirks with multiple endpoints assigned to a single altsetting. Unfortunately the generic parser couldn't detect the sync endpoint correctly as the implicit sync due to the missing EP attribute bits. In the former kernels, it used to work somehow casually, but it's been broken for a while after the large code change in 5.11. This patch cures the regression by the following: - Allow the static quirk table to provide the sync EP information; we just need to fill the fields and let the generic parser skipping parsing if sync_ep is already set. - Add the sync endpoint information to the entry for Saffire 6. Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks") Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220606160910.6926-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Skip generic sync EP parse for secondary EPTakashi Iwai2022-06-061-1/+1
| | | | | | | | | | | | | | | | When ep_idx is already non-zero, it means usually a capture stream that is set up explicity by a fixed-format quirk, and applying the check for generic (non-implicit-fb) sync EPs might hit incorrectly, resulting in a bogus sync endpoint for the capture stream. This patch adds a check for the ep_idx and skip if it's a secondary endpoint. It's a part of the fixes for regressions on Saffire 6. Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks") Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220606160910.6926-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Configure sync endpoints before dataCraig McLure2022-05-241-6/+11
| | | | | | | | | | | | | | | | | Devices such as the TC-Helicon GoXLR require the sync endpoint to be configured in advance of the data endpoint in order for sound output to work. This patch simply changes the ordering of EP configuration to resolve this. Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215079 Signed-off-by: Craig McLure <craig@mclure.net> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220524062115.25968-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Limit max buffer and period sizes per timeTakashi Iwai2022-04-131-87/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the previous fix, we increased the max buffer bytes from 1MB to 4MB so that we can use bigger buffers for the modern HiFi devices with higher rates, more channels and wider formats. OTOH, extending this has a concern that too big buffer is allowed for the lower rates, less channels and narrower formats; when an application tries to allocate as big buffer as possible, it'll lead to unexpectedly too huge size. Also, we had a problem about the inconsistent max buffer and period bytes for the implicit feedback mode when both streams have different channels. This was fixed by the (relatively complex) patch to reduce the max buffer and period bytes accordingly. This is an alternative fix for those, a patch to kill two birds with one stone (*): instead of increasing the max buffer bytes blindly and applying the reduction per channels, we simply use the hw constraints for the buffer and period "time". Meanwhile the max buffer and period bytes are set unlimited instead. Since the inconsistency of buffer (and period) bytes comes from the difference of the channels in the tied streams, as long as we care only about the buffer (and period) time, it doesn't matter; the buffer time is same for different channels, although we still allow higher buffer size. Similarly, this will allow more buffer bytes for HiFi devices while it also keeps the reasonable size for the legacy devices, too. As of this patch, the max period and buffer time are set to 1 and 2 seconds, which should be large enough for all possible use cases. (*) No animals were harmed in the making of this patch. Fixes: 98c27add5d96 ("ALSA: usb-audio: Cap upper limits of buffer/period bytes for implicit fb") Fixes: fee2ec8cceb3 ("ALSA: usb-audio: Increase max buffer size") Link: https://lore.kernel.org/r/20220412130740.18933-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Increase max buffer sizeTakashi Iwai2022-04-081-1/+1
| | | | | | | | | | The current limit of max buffer size 1MB seems too small for modern devices with lots of channels and high sample rates. Let's make bigger, 4MB. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220407212740.17920-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Cap upper limits of buffer/period bytes for implicit fbTakashi Iwai2022-04-081-2/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the implicit feedback mode, some parameters are tied between both playback and capture streams. One of the tied parameters is the period size, and this can be a problem if the device has different number of channels to both streams. Assume that an application opens a playback stream that has an implicit feedback from a capture stream, and it allocates up to the max period and buffer size as much as possible. When the capture device supports only more channels than the playback, the minimum period and buffer sizes become larger than the sizes the playback stream took. That is, the minimum size will be over the max size the driver limits, and PCM core sees as if no available configuration is found, returning -EINVAL mercilessly. For avoiding this problem, we have to look through the counter part of audioformat list for each sync ep, and checks the channels. If more channels are found there, we reduce the max period and buffer sizes accordingly. You may wonder that the patch adds only the evaluation of channels between streams, and what about other parameters? Both the format and the rate are tied in the implicit fb mode, hence they are always identical. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215792 Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220407211657.15087-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Don't start stream for capture at prepareTakashi Iwai2021-11-191-1/+2
| | | | | | | | | The recent change made mistakenly the stream for capture started at prepare stage. Add the stream direction check to avoid it. Fixes: 9c9a3b9da891 ("ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback") Link: https://lore.kernel.org/r/20211119102629.7476-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Switch back to non-latency mode at a later pointTakashi Iwai2021-11-191-2/+9
| | | | | | | | | | | | | | | | | | | The recent regression report revealed that the judgment of the low-latency playback mode based on the runtime->stop_threshold cannot work reliably at the prepare stage, as sw_params call may happen at any time, and PCM dmix actually sets it up after the prepare call. This ended up with the stall of the stream as PCM ack won't be issued at all. For addressing this, check the free-wheeling mode again at the PCM trigger right before starting the stream again, and allow switching to the non-LL mode at a late stage. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/r/20211117161855.m45mxcqszkfcetai@box.shutemov.name Link: https://lore.kernel.org/r/20211119102459.7055-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Less restriction for low-latency playback modeTakashi Iwai2021-10-121-1/+1
| | | | | | | | | | | | | | | | The recent support for the improved low-latency playback mode applied the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this was a slight overkill. The use of the flag above disables effectively both PCM status and control mmaps, while basically what we want to track is only about the appl_ptr update. For less restriction, use a more proper flag, SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control mmap. Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support") Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Pass JOINT_DUPLEX info flag for implicit fb streamsTakashi Iwai2021-10-071-0/+7
| | | | | | | | | When a stream is in the implicit feedback mode, it's more or less tied with a capture stream. Passing SNDRV_PCM_INFO_JOINT_DUPLEX may help for user-space to understand the situation. Link: https://lore.kernel.org/r/20211007083528.4184-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Avoid killing in-flight URBs during drainingTakashi Iwai2021-09-301-8/+8
| | | | | | | | | | | | | | | | | | | While draining a stream, ALSA PCM core stops the stream by issuing snd_pcm_stop() after all data has been sent out. And, at PCM trigger stop, currently USB-audio driver kills the in-flight URBs explicitly, then at sync-stop ops, sync with the finish of all remaining URBs. This might result in a drop of the drained samples as most of USB-audio devices / hosts allow relatively long in-flight samples (as a sort of FIFO). For avoiding the trimming, this patch changes the stream-stop behavior during PCM draining state. Under that condition, the pending URBs won't be killed. The leftover in-flight URBs are caught by the sync-stop operation that shall be performed after the trigger-stop operation. Link: https://lore.kernel.org/r/20210929080844.11583-10-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Improved lowlatency playback supportTakashi Iwai2021-09-301-21/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ALSA: usb-audio: Check available frames for the next packet sizeTakashi Iwai2021-09-301-1/+1
| | | | | | | | | | | | | | | This is yet more preparation for the upcoming changes. Extend snd_usb_endpoint_next_packet_size() to check the available frames and return -EAGAIN if the next packet size is equal or exceeds the given size. This will be needed for avoiding XRUN during the low latency operation. As of this patch, avail=0 is passed, i.e. the check is skipped and no behavior change. Link: https://lore.kernel.org/r/20210929080844.11583-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Disable low-latency mode for implicit feedback syncTakashi Iwai2021-09-301-0/+3
| | | | | | | | | | | | | | When a playback stream runs in the implicit feedback mode, its operation is passive and won't start unless the capture packet is received. This behavior contradicts with the low-latency playback mode, and we should turn off lowlatency_playback flag accordingly. In theory, we may take the low-latency mode when the playback-first quirk is set, but it still conflicts with the later operation with the fixed packet numbers, so it's disabled all together for now. Link: https://lore.kernel.org/r/20210929080844.11583-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Disable low-latency playback for free-wheel modeTakashi Iwai2021-09-301-2/+6
| | | | | | | | | | The free-wheel stream operation like dmix may not update the appl_ptr appropriately, and it doesn't fit with the low-latency playback mode. Disable the low-latency playback operation when the stream is set up in such a mode. Link: https://lore.kernel.org/r/20210929080844.11583-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playbackTakashi Iwai2021-09-301-9/+20
| | | | | | | | | | | | | | | | | | This is a preparation patch for the upcoming low-latency improvement changes. Rename early_playback_start flag with lowlatency_playback as it's more intuitive. The new flag is basically a reverse meaning. Along with the rename, factor out the code to set the flag to a function. This makes the complex condition checks simpler. Also, the same flag is introduced to snd_usb_endpoint, too, that is carried from the snd_usb_substream flag. Currently the endpoint flag isn't still referred, but will be used in later patches. Link: https://lore.kernel.org/r/20210929080844.11583-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Restrict rates for the shared clocksTakashi Iwai2021-09-301-0/+9
| | | | | | | | | | | | | When a single clock source is shared among several endpoints, we have to keep the same rate on all active endpoints as long as the clock is being used. For dealing with such a case, this patch adds one more check in the hw params constraint for the rate to take the shared clocks into account. The current rate is evaluated from the endpoint list that applies the same clock source. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190418 Link: https://lore.kernel.org/r/20210929080844.11583-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Add lowlatency module optionTakashi Iwai2021-08-291-1/+2
| | | | | | | | | | | | For making user to switch back to the old playback mode, this patch adds a new module option 'lowlatency' to snd-usb-audio driver. When user face a regression due to the recent low-latency playback support, they can test easily by passing lowlatency=0 option without rebuilding the kernel. Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2") Link: https://lore.kernel.org/r/20210829073830.22686-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Work around for XRUN with low latency playbackTakashi Iwai2021-08-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | The recent change for low latency playback works in most of test cases but it turned out still to hit errors on some use cases, most notably with JACK with small buffer sizes. This is because USB-audio driver fills up and submits full URBs at the beginning, while the URBs would return immediately and try to fill more -- that can easily trigger XRUN. It was more or less expected, but in the small buffer size, the problem became pretty obvious. Fixing this behavior properly would require the change of the fundamental driver design, so it's no trivial task, unfortunately. Instead, here we work around the problem just by switching back to the old method when the given configuration is too fragile with the low latency stream handling. As a threshold, we calculate the total buffer bytes in all plus one URBs, and check whether it's beyond the PCM buffer bytes. The one extra URB is needed because XRUN happens at the next submission after the first round. Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Reduce latency at playback start, take#2Takashi Iwai2021-07-071-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another attempt for the reduction of the latency at the start of a USB audio playback stream. The first attempt in the commit 9ce650a75a3b caused an unexpected regression (a deadlock with pipewire usage) and was later reverted by the commit 4b820e167bf6. The devils are always living in details, of course; the cause of the deadlock was the call of snd_pcm_period_elapsed() inside prepare_playback_urb() callback. In the original code, this callback is never called from the stream lock context as it's driven solely from the URB complete callback. Along with the movement of the URB submission into the trigger START, this prepare call may be also executed in the stream lock context, hence it deadlocked with the another lock in snd_pcm_period_elapsed(). (Note that this happens only conditionally with a small period size that matches with the URB buffer length, which was a reason I overlooked during my tests. Also, the problem wasn't seen in the capture stream because the capture stream handles the period-elapsed only at retire callback that isn't executed at the trigger.) If it were only about avoiding the deadlock, it'd be possible to use snd_pcm_period_elapsed_under_stream_lock() as a solution. However, in general, the period elapsed notification must be sent after the actual stream start, and replacing the call wouldn't satisfy the pattern. A better option is to delay the notification after the stream start procedure finished, instead. In the case of USB framework, one of the fitting place would be the complete callback of the first URB. So, as a workaround of the deadlock and the order fixes above, in addition to the re-applying the changes in the commit 9ce650a75a3, this patch introduces a new flag indicating the delayed period-elapsed handling and sets it under the possible deadlock condition (i.e. prepare callback being called before subs->running is set). Once when the flag is set, the period-elapsed call is handled at a later URB complete call instead. As a reference for the original motivation for the low-latency change, I cite here again: | USB-audio driver behaves a bit strangely for the playback stream -- | namely, it starts sending silent packets at PCM prepare state while | the actual data is submitted at first when the trigger START is | kicked off. This is a workaround for the behavior where URBs are | processed too quickly at the beginning. That is, if we start | submitting URBs at trigger START, the first few URBs will be | immediately completed, and this would result in the immediate | period-elapsed calls right after the start, which may confuse | applications. | | OTOH, submitting the data after silent URBs would, of course, result | in a certain delay of the actual data processing, and this is rather | more serious problem on modern systems, in practice. | | This patch tries to revert the workaround and lets the URB | submission starting at PCM trigger for the playback again. As far | as I've tested with various backends (native ALSA, PA, JACK, PW), I | haven't seen any problems (famous last words :) | | Note that the capture stream handling needs no such workaround, | since the capture is driven per received URB. Link: https://lore.kernel.org/r/4e71531f-4535-fd46-040e-506a3c256bbd@marcan.st Link: https://lore.kernel.org/r/s5hbl7li0fe.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20210707112447.27485-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Revert "ALSA: usb-audio: Reduce latency at playback start"Linus Torvalds2021-07-031-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9ce650a75a3b262c90789b42aedee8fc2ee04d53. This commit causes watchdog lockups on my machine, and while I have no idea what the cause is, it bisected right to this commit, and reverting the change promptly fixes it. At least occasionally one of the watchdog call traces was Call Trace: _raw_spin_lock_irqsave+0x35/0x40 snd_pcm_period_elapsed+0x1b/0xa0 [snd_pcm] snd_usb_endpoint_start+0x1a0/0x3c0 [snd_usb_audio] start_endpoints+0x23/0x90 [snd_usb_audio] snd_usb_substream_playback_trigger+0x7b/0x1a0 [snd_usb_audio] snd_pcm_common_ioctl+0x1c44/0x2360 [snd_pcm] snd_pcm_ioctl+0x2e/0x40 [snd_pcm] __se_sys_ioctl+0x72/0xc0 do_syscall_64+0x4c/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae so presumably it's a locking error on that substream spinlock that snd_pcm_period_elapsed() takes. But at this point I just want to have a working system so that I can continue the merge window work tomorrow. Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ALSA: usb-audio: Reduce latency at playback startTakashi Iwai2021-06-021-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | USB-audio driver behaves a bit strangely for the playback stream -- namely, it starts sending silent packets at PCM prepare state while the actual data is submitted at first when the trigger START is kicked off. This is a workaround for the behavior where URBs are processed too quickly at the beginning. That is, if we start submitting URBs at trigger START, the first few URBs will be immediately completed, and this would result in the immediate period-elapsed calls right after the start, which may confuse applications. OTOH, submitting the data after silent URBs would, of course, result in a certain delay of the actual data processing, and this is rather more serious problem on modern systems, in practice. This patch tries to revert the workaround and lets the URB submission starting at PCM trigger for the playback again. As far as I've tested with various backends (native ALSA, PA, JACK, PW), I haven't seen any problems (famous last words :) Note that the capture stream handling needs no such workaround, since the capture is driven per received URB. Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Factor out DSD bitrev copy functionTakashi Iwai2021-06-021-9/+19
| | | | | | | | Just minor code refactoring. Like DOP DSD code, it can be better in a separate function for code readability. Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Refactoring delay account codeTakashi Iwai2021-06-021-77/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ALSA: usb-audio: Pre-calculate buffer byte sizeTakashi Iwai2021-06-021-24/+24
| | | | | | | | | There are a bunch of lines calculating the buffer size in bytes at each time. Keep the value in subs->buffer_bytes and use it consistently for the code simplicity. Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Make snd_usb_pcm_delay() staticTakashi Iwai2021-06-021-2/+2
| | | | | | | It's a local function, let's make it static. Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Allow modifying parameters with succeeding hw_params callsTakashi Iwai2021-02-281-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent fix for the hw constraints for implicit feedback streams via commit e4ea77f8e53f ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync") added the check of the matching endpoints and whether those EPs are already opened. This is needed and correct, per se, even for the normal streams without the implicit feedback, as the endpoint setup is exclusive. However, it's reported that there seem applications that behave in unexpected ways to update the hw_params without clearing the previous setup via hw_free, and those hit a problem now: then hw_params is called with still the previous EP setup kept, hence it's restricted with the previous own setup. Although the obvious fix is to call snd_pcm_hw_free() API in the application side, it's a kind of unwelcome change. This patch tries to ease the situation: in the endpoint check, we add a couple of more conditions and now skip the endpoint that is being used only by the stream in question itself. That is, in addition to the presence check of ep (ep->cur_audiofmt is non-NULL), when the following conditions are met, we skip such an ep: - ep->opened == 1, and - ep->cur_audiofmt == subs->cur_audiofmt. subs->cur_audiofmt is non-NULL only if it's a re-setup of hw_params, and ep->cur_audiofmt points to the currently set up parameters. So if those match, it must be this stream itself. Fixes: e4ea77f8e53f ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211941 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210228080138.9936-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Don't avoid stopping the stream at disconnectionTakashi Iwai2021-02-081-4/+1
| | | | | | | | | | | | | In the later patch, we're going to issue the PCM sync_stop calls at disconnection. But currently the USB-audio driver can't handle it because it has a check of shutdown flag for stopping the URBs. This is basically superfluous (the stopping URBs are safe at disconnection state), so let's drop the check. Fixes: dc5eafe7787c ("ALSA: usb-audio: Support PCM sync_stop") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210206203052.15606-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Fix PCM buffer allocation in non-vmalloc modeTakashi Iwai2021-02-051-1/+1
| | | | | | | | | | | | | | | | | | | The commit f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers") introduced the mode to allocate coherent pages for PCM buffers, and it used bus->controller device as its DMA device. It turned out, however, that bus->sysdev is a more appropriate device to be used for DMA mapping in HCD code. This patch corrects the device reference accordingly. Note that, on most platforms, both point to the very same device, hence this patch doesn't change anything practically. But on platforms like xhcd-plat hcd, the change becomes effective. Fixes: f274baa49be6 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210205144559.29555-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Fix hw constraints dependenciesTakashi Iwai2021-01-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the recent refactoring, it's been reported that some USB-audio devices (typically webcams) are no longer detected properly by PulseAudio. The debug session revealed that it's failing at probing by PA to try the sample rate 44.1kHz while the device has discrete sample rates other than 44.1kHz. But the puzzle was that arecord works as is, and some other devices with the discrete rates work, either. After all, this turned out to be the lack of the dependencies in a few hw constraint rules: snd_pcm_hw_rule_add() has the (variable) arguments specifying the dependent parameters, and some functions didn't set the target parameter itself as the dependencies. This resulted in an invalid parameter that could be generated only in a certain call pattern. This bug itself has been present in the code, but it didn't trigger errors just because the rules were casually avoiding such a corner case. After the recent refactoring and cleanup, however, the hw constraints work "as expected", and the problem surfaced now. For fixing the problem above, this patch adds the missing dependent parameters to each snd_pcm_hw_rule() call. Fixes: bc4e94aa8e72 ("ALSA: usb-audio: Handle discrete rates properly in hw constraints") BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181014 Link: https://lore.kernel.org/r/20210120204554.30177-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Always apply the hw constraints for implicit fb syncTakashi Iwai2021-01-131-63/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync"), we apply the hw constraints for the implicit feedback sync to make the secondary open aligned with the already opened stream setup. This change assumed that the secondary open is performed after the first stream has been already set up, and adds the hw constraints to sync with the first stream's parameters only when the EP setup for the first stream was confirmed at the open time. However, most of applications handling the full-duplex operations do open both playback and capture streams at first, then set up both streams. This results in skipping the additional hw constraints since the counter-part stream hasn't been set up yet at the open of the second stream, and it eventually leads to "incompatible EP" error in the end. This patch corrects the behavior by always applying the hw constraints for the implicit fb sync. The hw constraint rules are defined so that they check the sync EP dynamically at each invocation, instead. This covers the concurrent stream setups better and lets the hw refine calls resolving to the right configuration. Also this patch corrects a minor error that has existed in the debug print that isn't built as default. Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Factor out the implicit feedback quirk codeTakashi Iwai2020-11-231-306/+14
| | | | | | | | | | | | | | | | | | | The code dealing with the implicit feedback mode grew recently, and it's becoming messy. As we receive more and more devices that need the similar handling, it's better to be processed through a table instead of the open code. This patch moves the code that is relevant with parsing the implicit feedback mode and some helpers into another file, implicit.c. The detection and the setup of the implicit feedback sync EPs are rewritten to use the ID/class matching table instead. There should be no functional changes. Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> Link: https://lore.kernel.org/r/20201123085347.19667-38-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Quirk for BOSS GT-001Takashi Iwai2020-11-231-0/+31
| | | | | | | | | | | | | | | | | | The capture stream of BOSS GT-001 seems always requiring to be tied with the playback stream. OTOH, the playback stream of this device doesn't seem working in the implicit fb mode, per se, since the playback must be running before the capture stream. This patch tries to address the points above: - Avoid the implicit fb mode for the playback - Set up a fake sync EP for the capture stream with the hard-coded playback stream using the implicit fb mode Reported-by: Keith Milner <kamilner@superlative.org> Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> Link: https://lore.kernel.org/r/20201123085347.19667-37-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Unify the code for the next packet size calculationTakashi Iwai2020-11-231-7/+1
| | | | | | | | | | | There are two places calculating the next packet size for the playback stream in the exactly same way. Provide the single helper for this purpose and use it from both places gracefully. Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> Link: https://lore.kernel.org/r/20201123085347.19667-32-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Drop unneeded snd_usb_substream fieldsTakashi Iwai2020-11-231-18/+6
| | | | | | | | | | | | Some fields like interface and alt_idx in snd_usb_substream are mostly useless now as they can be referred via either cur_audiofmt or data_endpoint assigned to the substream. Drop those, and also assure the concurrency about the access of cur_audiofmt field. Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> Link: https://lore.kernel.org/r/20201123085347.19667-31-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: usb-audio: Constify audioformat pointer referencesTakashi Iwai2020-11-231-16/+16
| | | | | | | | | | The audioformat is referred in many places but most of usages are read-only. Let's add const prefix in the possible places. Tested-by: Keith Milner <kamilner@superlative.org> Tested-by: Dylan Robinson <dylan_robinson@motu.com> Link: https://lore.kernel.org/r/20201123085347.19667-28-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>