On 31.12.22 12:38, Ruud van Asseldonk wrote: > > 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. Not my area of expertise, thus consider this a lucky guess that might be misleading -- but is this maybe similar to the issue discussed here? https://lore.kernel.org/all/s5him6gnkdu.wl-tiwai@xxxxxxx/ To quote: ``` It's no regression but the right behavior. This indicates that you're trying a stream in 44.1kHz in one side of the full duplex stream while 48kHz in another rate, and this cannot work properly with the implicit feedback devices. It might have worked casually by some reason on your device, but it was just a coincidence, as it didn't follow exactly what the implicit feedback mode requires (i.e. the playback packet must follow exactly the incoming recording packet). That said, for the device like this, the sample rate has to be fixed for both streams. Hope that clarifies the situation. Takashi ``` Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. > Ruud van Asseldonk wrote: >> After diving into this some more, I managed to create a minimal >> reproducing C program. I discovered: >> >> * The bit depth is not relevant. >> * It is not a problem with 96 kHz, but a problem with switching >> sample rates. >> >> If I call snd_pcm_hw_params, the first call always succeeds. But when >> I first call it with hw_params with rate 44100 and then again with >> 48000 or 96000, the second call fails. If I call it with 96000 first >> and then with 44100, the first call for 96000 succeeds and changing to >> 44100 fails. I'll add the full program at the end of this mail. >> Changing the bit depth does succeed by the way, to it’s not that the >> hw_params can’t be changed at all. >> >> >> Thorsten Leemhuis wrote: >> >>>> Sorry for your troubles. You could use "git bisect" to try to pinpoint >>>> the exact commit that introduces failure for you. >>> >>> Yeah, that would be helpful. But 5.15 is quite old by now. Before going >>> down that route you might want to try the latest kernel (e.g. Linux >>> 6.1), as the problem might have been fixed in between, without the fix >>> being backported. >>> You also talk about a "rpi-" kernel. Is that a vanilla kernel, or at >>> least close to it? >> >> It is not vanilla, it is from >> https://github.com/raspberrypi/linux/tree/rpi-5.15.y. However, in >> addition to the Raspberry Pi I also have an x86_64 laptop that runs a >> vanilla 6.1.1 kernel, and the minimal reproducing program below does >> fail here as well with an UMC204HD. When I downgrade to 5.10.16 (also >> vanilla), the program does succeed. So it’s unrelated to the Raspberry >> Pi. This should also make it a lot easier for me to bisect this as I >> don’t have to do it on the Raspberry. I will try to bisect next then. >> >> >> Jaroslav Kysela wrote: >> >> > It seems like a problem in the hw_params constraints / refining. There >> > are lot of changes in the USB audio driver between 5.10/5.15. There is >> > also HW_CONST_DEBUG define in sound/usb/pcm.c which enables the debug >> > output for the refining. >> > >> > Just curious: What's behind the value 513 (period size)? It does not >> > match the time (5.34ms for 96kHz) nor a binary value. I would use 480 >> > (5ms) or so. >> >> I think I put this in at some point trying to see if it made a >> difference, in my main application I was using different values. After >> some more trying, it looks like the period size and buffer size are >> not relevant for reproducing, see also the program below. >> >> > And the final note: I gave a quick test with UMC204HD with the 6.0.9 >> > kernel and it appears that this problem is not present in the recent >> > kernel: >> >> After writing the reproducer, it looks like the failure only happens >> when changing the sample rate, so it makes sense that aplay would not >> reproduce it. >> >> > I would also use S32_LE native format in your app, the S24_3LE is not >> > supported with your hw directly. The alsa-lib does conversion. >> >> Thanks for the heads-up! Yeah I am being lazy, I am also relying on >> alsa-lib to expand the channels from 2 to 4 (since the UCM404 only >> supports 4 channels). >> >> >> Minimal reproducing program: >> >> #include <assert.h> >> #include <alsa/asoundlib.h> >> >> void set_format(snd_pcm_t* pcm, unsigned int rate) { >> int err; >> snd_pcm_hw_params_t* hwp; >> err = snd_pcm_hw_params_malloc(&hwp); >> assert(err == 0); >> err = snd_pcm_hw_params_any(pcm, hwp); >> assert(err == 0); >> err = snd_pcm_hw_params_set_rate(pcm, hwp, rate, 0); >> assert(err == 0); >> err = snd_pcm_hw_params(pcm, hwp); >> assert(err == 0); >> } >> >> int main(void) { >> int err; >> snd_pcm_t* pcm; >> >> int mode = 0; >> err = snd_pcm_open(&pcm, "hw:U192k", SND_PCM_STREAM_PLAYBACK, mode); >> assert(err == 0); >> >> set_format(pcm, 44100); >> printf("44.1k ok\n"); >> set_format(pcm, 96000); >> printf("96k ok\n"); >> } >> >> Kind regards, >> Ruud >
