From: Takashi Iwai <tiwai@suse.de>
To: Jaroslav Kysela <perex@perex.cz>
Cc: alsa-devel@alsa-project.org,
Thorsten Leemhuis <regressions@leemhuis.info>,
Takashi Iwai <tiwai@suse.com>,
Ruud van Asseldonk <ruud@veniogames.com>,
Geraldo Nascimento <geraldogabriel@gmail.com>
Subject: Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21
Date: Mon, 02 Jan 2023 17:57:56 +0100 [thread overview]
Message-ID: <87lemkswkr.wl-tiwai@suse.de> (raw)
In-Reply-To: <87wn67wvyf.wl-tiwai@suse.de>
On Sat, 31 Dec 2022 14:20:56 +0100,
Takashi Iwai wrote:
>
> On Sat, 31 Dec 2022 13:10:18 +0100,
> Jaroslav Kysela wrote:
> >
> > On 31. 12. 22 12:38, Ruud van Asseldonk wrote:
> > > Hi all,
> > >
> > > I bisected this and identified e4ea77f8e53f9accb9371fba34c189d0447ecce0
> > > (ALSA: usb-audio: Always apply the hw constraints for implicit fb sync)
> > > as the first commit where it is no longer possible to change the sample
> > > rate. On the parent commit, my sample program successfully changes the
> > > sample rate from 44100 Hz to 96000 Hz, but on e4ea77f8e53f9, the second
> > > call to snd_pcm_hw_params fails.
> >
> > There is an easy workaround - call snd_pcm_hw_free() between the
> > params setup. This call ensure that the sync ep is freed. I can just
> > confirm that this
> > problem is only for USB hw with the implicit feedback (tested with 6.0.11 kernel).
> >
> > I will try to debug this when I find a little free time. Perhaps,
> > Takashi may have a straight idea, what's wrong. When only one stream
> > is used, this hw_params call should succeed, too.
>
> The patch like below might help (note: totally untested).
>
> My wild guess is that it's an internal stream start for the implicit
> fb case at prepare without actually starting a PCM stream, and it
> wasn't stopped properly before the second hw_params call.
Looking at the problem again, I think this is a different problem from
the patch I've sent. This is rather the hw_params that becomes too
restrictive once after the implicit sync is set up. A workaround
patch is below.
The previous patch is still valid, though. I'm going to submit a
series of fixes.
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: usb-audio: Relax hw constraints for implicit fb sync
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")
Link: https://lore.kernel.org/r/4e509aea-e563-e592-e652-ba44af6733fe@veniogames.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/usb/pcm.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
index 7fc95ae9b2f0..2fd4ecc1b25a 100644
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -937,8 +937,13 @@ get_sync_ep_from_substream(struct snd_usb_substream *subs)
continue;
/* for the implicit fb, check the sync ep as well */
ep = snd_usb_get_endpoint(chip, fp->sync_ep);
- if (ep && ep->cur_audiofmt)
- return ep;
+ if (ep && ep->cur_audiofmt) {
+ /* ditto, if the sync (data) ep is used by others,
+ * this stream is restricted by the sync ep
+ */
+ if (ep != subs->sync_endpoint || ep->opened > 1)
+ return ep;
+ }
}
return NULL;
}
--
2.35.3
prev parent reply other threads:[~2023-01-02 16:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 22:18 Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21 Ruud van Asseldonk
2022-12-11 15:30 ` Ruud van Asseldonk
2022-12-11 21:08 ` Geraldo Nascimento
2022-12-12 9:48 ` Thorsten Leemhuis
2022-12-12 12:41 ` Jaroslav Kysela
2022-12-30 18:42 ` Ruud van Asseldonk
2022-12-31 11:38 ` Ruud van Asseldonk
2022-12-31 12:03 ` Thorsten Leemhuis
2022-12-31 12:10 ` Jaroslav Kysela
2022-12-31 13:20 ` Takashi Iwai
2023-01-02 16:57 ` Takashi Iwai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lemkswkr.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=geraldogabriel@gmail.com \
--cc=perex@perex.cz \
--cc=regressions@leemhuis.info \
--cc=ruud@veniogames.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox