Hi, this is your Linux kernel regression tracker. On 11.12.22 22:08, Geraldo Nascimento wrote: > On Sun, Dec 11, 2022 at 04:30:11PM +0100, Ruud van Asseldonk wrote: >> Hi all, >> >> This issue is still present in 5.15.82, is there anything I can do to >> diagnose this further? > > Hi Ruud, > > 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? Also CCing Takashi, maybe he has an idea. CCing the regression mailing list, too, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html 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 >> >>> Hi, >>> >>> I have a program that configures a Behringer UMC404HD 192k USB audio >>> interface for playback as follows (pseudocode): >>> >>> snd_pcm_hw_params_set_channels(pcm, hwp, 2); >>> snd_pcm_hw_params_set_format(pcm, hwp, SND_PCM_FORMAT_S24_3LE); >>> snd_pcm_hw_params_set_access(pcm, hwp, SND_PCM_ACCESS_MMAP_INTERLEAVED); >>> snd_pcm_hw_params_set_rate(pcm, hwp, val=96000, dir=0); >>> snd_pcm_hw_params_set_period_size_near(pcm, hwp, val=513, dir=0); >>> // If I confirm at this point with snd_pcm_hw_params_get_period_size, >>> // I get back 513. >>> snd_pcm_hw_params_set_buffer_size_near(pcm, hwp, val=2052); >>> snd_pcm_hw_params(pcm, hwp); >>> // If I confirm with snd_pcm_hw_params_get_buffer_size, >>> // I get back 2052. >>> >>> On Linux 5.10.94 (specifically Arch Linux ARM package >>> linux-rpi-5.10.94-1), this succeeds, and I can play back audio just >>> fine. On 5.15.21 (specifically linux-rpi-5.15.21-3), all the calls >>> succeed apart from the last one, which returns EINVAL. >>> >>> (My actual program is written in Rust and uses a Rust wrapper library >>> for libasound, https://docs.rs/alsa/0.6.0/alsa/, but the calls should be >>> the ones listed.) >>> >>> I confirmed with snd_pcm_hw_params_test_format that the S24_3LE format >>> is supported. On both kernels it is successful. I confirmed with >>> snd_pcm_hw_params_test_rate that 96 kHz is supported. On both kernels it >>> is successful. There are differences though. When I query these: >>> >>> snd_pcm_hw_params_get_period_size_min >>> snd_pcm_hw_params_get_period_size_max >>> snd_pcm_hw_params_get_buffer_size_min >>> snd_pcm_hw_params_get_buffer_size_max >>> >>> Then on 5.10.94 (the good version), I get: >>> >>> period size min/max: 12/32768, buffer size min/max: 24/65536 >>> >>> But on 5.15.21 (the bad version), I get: >>> >>> period size min/max: 13/71332, buffer size min/max: 26/142663 >>> >>> Also, after I set the period size to 513, if I then query the buffer >>> size min/max, on 5.10.94 I get: >>> >>> buffer size min/max: 1026/65536 >>> >>> But on 5.15.21 I get: >>> >>> buffer size min/max: 1027/142663 >>> >>> In lsmod, snd_usb_audio shows up, and from lsusb -v, the UMC404HD >>> appears to be a standard USB audio interface. The lsusb output is >>> identical on both kernels. >>> >>> Please let me know if there is anything I can do to help further >>> diagnose the issue, or if I should report this elsewhere. >>> >>> Kind regards, >>> Ruud van Asseldonk
