In D45135#1029509, @dev_submerge.ch wrote:

Maybe unrelated to this particular piece of code, but I did some tests with two USB sound cards. When I remove the first one (pcm0), the mixer application reveals some flaws:

<flo@current:~> mixer -a
mixer: /dev/mixer0: no such mixer

<flo@current:~> mixer
pcm1:mixer: (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

Note that while the mixer default pcm is correct (pcm1), there's no sound card identifier like when I have both plugged in:

<flo@current:~> mixer -a
pcm0:mixer: <Roland EDIROL UA-25EX> on uaudio0 (play/rec)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk
pcm1:mixer: <RME Babyface (23607206)> on uaudio1 (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

<flo@current:~> mixer
pcm1:mixer: <RME Babyface (23607206)> on uaudio1 (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

Possibly related bug report.

I do not really have the hardware to test the driver, but the code looks good to me at a first glance.

In D45135#1029486, @emaste wrote:

Regarding the race, it maybe be very hard to hit it

I just mean that I think the race doesn't even matter because the issue is identical if you remove the device any time prior to the mixer_oss_mixerinfo call?

In D45135#1029480, @emaste wrote:

This seems sensible; I'd expect mixer 1 to refer to /dev/mixer1 not whatever the second mixer happens to be. I don't think a race condition like you describe is even required, right? Removing the device providing /dev/mixer0 means the system will always be in this state?

s/real_device/legacy_device/

Update commit message and filler size according to most recent soundcard.h
version.

In D45100#1028617, @christos wrote:

In D45100#1028614, @emaste wrote:

I couldn't find a useful reference for a name elsewhere so I think it's fine, although I might go with LENOVO_IDEAPAD3_SUBVENDOR

I chose I3 instead of IDEAPAD3 so as to follow the convention used for LENOVO_I330_SUBVENDOR, which is used for Ideapad 330.

I propose to make a follow-up patch to change both to IDEAPAD*.

In D45100#1028614, @emaste wrote:

I couldn't find a useful reference for a name elsewhere so I think it's fine, although I might go with LENOVO_IDEAPAD3_SUBVENDOR

Since the user told me his exact laptop model is:
Lenovo Ideapad 3 17IAU7
CPU: 12th Gen Intel(R) Core(TM) i3-1215U

The user who reported it verified that the following hints worked:

hint.hdac.0.cad0.nid20.config="as=1 seq=0"
hint.hdac.0.cad0.nid33.config="as=1 seq=15"

Remove unused SND_DEV_* defines from pcm/sound.h. Convert the list to an enum.

Remove /dev/dspW, /dev/audio and /dev/dspcd.

In D45013#1027043, @dev_submerge.ch wrote:

In D45013#1026752, @christos wrote:

In D45013#1026750, @emaste wrote:

I don't think there's a lot of value in keeping the aliases, if we don't also keep the behaviour -- i.e., if some application does expect to open /dev/dspW and send 16-bit samples without doing any other configuration it's not going to work as expected.

True, but if we delete them the program will just exit, which I don't know if it's any better. I am not very keen on keeping those aliases either however, so I am open to suggestions.

You're right, unless we can preset format and speed defaults for these clones they are not very useful. We have alternatives for people who want to just cat some wave files, e.g. the vchan sysctls or virtual_oss. I think we can remove them, it's not worth the effort.

In D45013#1026750, @emaste wrote:

I don't think there's a lot of value in keeping the aliases, if we don't also keep the behaviour -- i.e., if some application does expect to open /dev/dspW and send 16-bit samples without doing any other configuration it's not going to work as expected.

@dev_submerge.ch If there's nothing else that needs fixing I think we can go ahead with it.

In D45013#1026741, @emaste wrote:

how does e.g. /dev/dspW map to 16-bit now?

In D45015#1026743, @dev_submerge.ch wrote:

What is this diff based on? I can't apply it on any branch I have.

Ignore the RELNOTES entry below the new one. I just didn't diff against main.

• Remove MACHINE_ARCH from sndstat header.
• Add RELNOTES entry.

Address Florian's comments.

Remove "%ubit" line from sbuf_printf() in sndstat.c, MACHINE_ARCH includes the
bits already.

Remove it.