Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Ruud van Asseldonk]

Hi all,

This issue is still present in 5.15.82, is there anything I can do to 
diagnose this further?

Best,

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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Geraldo Nascimento]

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.

Thanks,
Geraldo Nascimento

> 
> Best,
> 
> 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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Thorsten Leemhuis]

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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Jaroslav Kysela]

On 12. 12. 22 10:48, Thorsten Leemhuis wrote:
> 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.

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.

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:

# aplay -Dhw:U192k --period-size=513 --buffer-size=2052 -c 4 -r 96000 -f S16_LE --dump-hw-params /dev/zero
Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 96000 Hz, Channels 4
HW Params of device "hw:U192k":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [64 128]
CHANNELS: 4
RATE: [44100 192000]
PERIOD_TIME: [125 1000000]
PERIOD_SIZE: [6 192000]
PERIOD_BYTES: [64 3072000]
PERIODS: [2 1024]
BUFFER_TIME: (62 2000000]
BUFFER_SIZE: [12 384000]
BUFFER_BYTES: [96 6144000]
TICK_TIME: ALL
--------------------
# cat /proc/asound/card2/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 4
rate: 96000 (96000/1)
period_size: 513
buffer_size: 2052

# aplay -Dplughw:U192k --period-size=513 --buffer-size=2052 -c 2 -r 96000 -f S24_3LE --dump-hw-params /dev/zero
ACCESS:  MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
FORMAT:  S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S20_LE S20_BE U20_LE U20_BE S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT:  STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295]
PERIOD_TIME: [125 1000000]
PERIOD_SIZE: (0 4294967295]
PERIOD_BYTES: (0 4294967295]
PERIODS: (0 4294967295]
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [1 4294967295]
BUFFER_BYTES: [1 4294967295]
TICK_TIME: ALL
# cat /proc/asound/card2/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 4
rate: 96000 (96000/1)
period_size: 513
buffer_size: 2052

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.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Ruud van Asseldonk]

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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Ruud van Asseldonk]

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.

Kind regards,
Ruud

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

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Thorsten Leemhuis]

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@suse.de/

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
> 

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Jaroslav Kysela]

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.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Takashi Iwai]

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.


Takashi

-- 8< --
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -525,6 +525,8 @@ static int snd_usb_hw_params(struct snd_pcm_substream *substream,
 		if (snd_usb_endpoint_compatible(chip, subs->data_endpoint,
 						fmt, hw_params))
 			goto unlock;
+		if (stop_endpoints(subs, false))
+			sync_pending_stops(subs);
 		close_endpoints(chip, subs);
 	}
 

Re: Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21

[Takashi Iwai]

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