In D47917#1092486, @christos wrote:

Some notes:

• I would like a different name than hw.snd.maxautovchans since the functionality is different now. Maybe hw.snd.vchans? That would break compatibility though. In any case, I will add a RELNOTES entry when it's time to commit.

In D47868#1091708, @christos wrote:

In D47868#1091707, @dev_submerge.ch wrote:

I have to admit the centralization through sound.h goes against my intuition - usually I would only include what is needed, where it's actually used. While this change reduces the number of includes, it makes it even harder to see the dependencies and layers in the sound module. But that's just my opinion, I suppose @markj and @emaste may be the better judges in this case.

While I kind of agree, I notice that some of the includes are simply repeated over and over, so IMHO it's better to just have them in one place. After all, we include pcm/sound.h everywhere anyway. Regarding dependencies and layering, I intentionally excluded pcm/sndstat.c-specific includes since they are not needed anywhere else, as well the foo_if.h ones, which I kept/moved to their respective header files.

I have to admit the centralization through sound.h goes against my intuition - usually I would only include what is needed, where it's actually used. While this change reduces the number of includes, it makes it even harder to see the dependencies and layers in the sound module. But that's just my opinion, I suppose @markj and @emaste may be the better judges in this case.

In D47736#1089562, @christos wrote:

In D47736#1089471, @dev_submerge.ch wrote:

If we do further work on the conversion functions, we may want to unit test them. Is that possible when we integrate them in feeder_format.c? I suppose a separate header would be easier, less extra dependencies?

Perhaps it could be useful, but I think it's better to first decide on the design and then implement the new header. I would like to somehow avoid the macro magic. :)

If we do further work on the conversion functions, we may want to unit test them. Is that possible when we integrate them in feeder_format.c? I suppose a separate header would be easier, less extra dependencies?

I'm fine with the removal. Although it would be interesting to know more about some of the disabled code, it's probably not worth the effort to examine thoroughly.

Switch input level flags according to test findings by @br. Setting "LowGain"
on the input level should now match the signal level of "HighGain" outputs.

Also I suspect the input signal levels to be backwards now, please report your findings. The recorded signal should be loudest for "-10dBV" and quietest with "LowGain".

In D47412#1088444, @br wrote:

I'm now able to set -10dBV and +4dBu, but could not set HighGain. So I guess there is an off-by-one error somewhere...

Fix condition to set the signal level in the settings register on change
requests, it checked the control register by mistake. This was a leftover from
the hdsp.c code that was copied here, sorry about that.

LGTM - seems also easier to reason about the code now, at least to me.

On a related note, shouldn't dummy_chan_io() only reschedule itself when one of the channels is running? Whereas we indiscriminately stop the callout for both channels if one of them is stopped, even if the other would be still running? Or maybe I have a misconception about the callout handling.

In D47412#1086254, @br wrote:

On the "-10dbV" problem I could suggest to rename this to "minus10dbv" (and "plus4dbu as well).

Fix the signal level flags which were backwards, with the loudest setting (high
gain) resulting in a quiet signal and vice versa.

In D47639#1086742, @christos wrote:

In D47639#1086741, @emaste wrote:

The reason this program exists is to provide a console beep (^G) in the absence of a PC speaker (with a bit more plumbing). At the end of the day even for that use performance isn't really going to matter -- but also the docs recommend against using AFMT_FLOAT.

I can see that this is useful for testing the kernel support, though.

I am aware that they do advise against using AFMT_FLOAT, however the whole program does everything in AFMT_FLOAT, so it seems quite counter-intuitive to me that we convert to AFMT_S32_LE just before the write(2), when we now have support for AFMT_FLOAT.

Very welcome, thanks for tackling this @christos. Please note that there are sound cards supporting float format, and I intend to experiment with that some time in the future (probably needs bitperfect for now).

In D47462#1086107, @christos wrote:

In D47462#1085187, @dev_submerge.ch wrote:

The refactored implementation of pcm_killchans() relies on the SD_F_REGISTERED flag (unset) to prevent addition of new channels, right? Should we make this explicit via assert or a comment?

While it wouldn't do any harm to assert that !PCM_REGISTERED, I do not really think it's necessary, since pcm_killchans() is only called from pcm_unregister() once we clear the flag.

The refactored implementation of pcm_killchans() relies on the SD_F_REGISTERED flag (unset) to prevent addition of new channels, right? Should we make this explicit via assert or a comment?

Yeah, sorry, I forgot about the out-of-tree modules too. The most important ones are probably HDMI audio devices from graphics modules (intel, radeon, amd, nvidia). What are the CURRENT pkg builds based on?

In D47462#1082422, @christos wrote:

@dev_submerge.ch Can you also test whether this patch along with all the other patches applied (D47459, D47460, D47461, D47463) fix the hot-unload (or any other) panics?

In D47412#1081377, @br wrote:

Great work, thanks!

I managed to switch phone level to +4dBU and then to HighGain, but could not switch back to -10dBV which was default

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dbU
dev.hdspe.0.phones_level: -10dBV -> +4dBu

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=HighGain
dev.hdspe.0.phones_level: +4dBu -> HighGain

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dBU
dev.hdspe.0.phones_level: HighGain -> +4dBu

Fail:
0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=-10dBV
dev.hdspe.0.phones_level: +4dBu -> +4dBu

Fixed a typo in the man page.

@br: This is the equivalent of D47330 for HDSPe AIO, as promised. Could you test it on real hardware (see test plan)? Please check that the default levels are safe, they should always be the most quiet.

Not in scope for this patch, but pcm_addchan() may return an error and I wonder whether / how the drivers should handle this error case?

In D47325#1079347, @christos wrote:

Update arm drivers as well.

What about the sound drivers under sys/arm? They seem to still reference pcm_setstatus(), did I miss something?

@br: If this patch is ok, I'll also adapt it to the HDSPe AIO in snd_hdspe(4) for you to test. Looks like it uses a different register though.

In D47199#1077635, @christos wrote:

So is the patch good to go?

@emaste: Thanks for the clarification on style(9)'s FALLTHROUGH part.

This simplifies the code quite a bit, nice! Some nitpicks in the inline comments.

Could this be turned into an enum, to facilitate compiler checks in switch() statements? Or is there a policy on using enums in src? I see them far less often than I would expect.

In D46836#1075170, @christos wrote:

In D46836#1075056, @dev_submerge.ch wrote:

The "name" field was meant as a descriptive label before, now it's a copy of an internal identifier that looks like a device path but isn't. It's not obvious to me whether you want to unify it with dsp_unit2name() everywhere or not. And without knowing all uses it's hard to tell whether that's a good idea.

I think we are missing the point a bit. The only change this patch brings is that it omits redundant information; the label is still equally descriptive. I do not get what the point of contention is exactly...

In D46836#1074859, @christos wrote:

In D46836#1073676, @dev_submerge.ch wrote:

1. What is the intended meaning of the "name" field? It was sort of descriptive before, but now you're tying it to the device path.

As mentioned before, the meaning remains exactly the same.

In D46836#1073435, @christos wrote:

In D46836#1069907, @dev_submerge.ch wrote:

In D46836#1069394, @christos wrote:

In D46836#1069273, @dev_submerge.ch wrote:

I don't care too much about the device names, but I think we should conceptually separate them from what we display to the end user. As a future goal we may want to have something more elaborate in the OSS audio info name field, e.g. dsp.virtual_play.1 <Dummy Audio Device>.

I agree with printing something more elaborate, although I'd prefer a different naming scheme than this one. But we can discuss it in the future. :-)

You are changing the content of the name field here. We have to assess where and what it is used for. As I try to explain, the different use cases may demand different formatting and content, thus I want to know what we cater to here.

From a quick GitHub search on SNDCTL_ENGINEINFO (which is what will populate oss_audioinfo with the channel name), what I see is that this field is not used much, and where it is used, it's not only for printing it later on, so there shouldn't be any problem. Note that up until e07f9178502b, SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO were the same thing, so I think that if there was a breakage to happen by changing the name field, we'd have run into trouble already. Also, the change I'm proposing includes the same information in the channel's name, just with less redundancy.

In D46847#1073438, @christos wrote:

In D46847#1069896, @dev_submerge.ch wrote:

I just put your reproduce code into a shell script. Setup is a bhyve VM, 4 cores, pcm0 is a passthrough USB audio interface, script operates on pcm1 which is snd_dummy as in your example.

I tried this exact scenario, but still cannot reproduce the panic after multiple times of running the script. Is there some non-default configuration you're using?

I suppose I'll never get used to 8-width indents ;-)
Anyway, for me this is good to go, thanks!

@br: I'll leave it up to you whether you want to squash this together with D46409 or make them separate commits.

In D46409#1069049, @br wrote:

In D46409#1067830, @dev_submerge.ch wrote:

{F97460426}

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

@br, could you have a look and integrate this patch with yours if you agree with it? It's a git patch, apply with git am and then squash. Since I cannot test it without the hardware, could you please also try to enable the unified pcm mode?

we could just commit the patches for different cards separately so preserve authors of patches. I can test unified PCB but not very soon

In D46836#1069394, @christos wrote:

In D46836#1069273, @dev_submerge.ch wrote:

I don't care too much about the device names, but I think we should conceptually separate them from what we display to the end user. As a future goal we may want to have something more elaborate in the OSS audio info name field, e.g. dsp.virtual_play.1 <Dummy Audio Device>.

I agree with printing something more elaborate, although I'd prefer a different naming scheme than this one. But we can discuss it in the future. :-)

In D46857#1069572, @christos wrote:

In D46857#1069256, @dev_submerge.ch wrote:

I'd prefer a smaller indent, maybe 2 spaces instead of the 8 space standard tabs, also for the first indent level. As is, the lines regularly exceed 80 character screen width and break the visual indent with the overflow.
But this is already an improvement, thanks!

The 80 characters will be easily exceeded by the feeder lines even with 2 spaces for all indent levels. I do not really have a big objection to using 2-space indentation, but I do think the 1-tab one looks cleaner.

In D46847#1069421, @christos wrote:

Interesting. What do you do exactly to reproduce those? Also what is the configuration you're using?

I don't care too much about the device names, but I think we should conceptually separate them from what we display to the end user. As a future goal we may want to have something more elaborate in the OSS audio info name field, e.g. dsp.virtual_play.1 <Dummy Audio Device>. And for /dev/sndstat we could also add the "play", "record" and "virtual" in the buffer printing there, without changing the device names.

I'd prefer a smaller indent, maybe 2 spaces instead of the 8 space standard tabs, also for the first indent level. As is, the lines regularly exceed 80 character screen width and break the visual indent with the overflow.
But this is already an improvement, thanks!

Unfortunately, I get a slightly different panic with this patch installed:

For the records, I consistently get a different panic when reproducing this (without the patch):

If I'm not mistaken, this name field corresponds to the name entry in the SNDCTL_AUDIOINFO ioctl. OSSv4 defines it as follows:

LGTM, I suppose this is save when called through SYSINIT?

This makes sysctl hw.snd.verbose=2; cat /dev/sndstat harder to read, and we lose the ability to grep for play, record and virtual there. Also I think this is shown verbatim in GUIs like VLC, do we expect normal users to understand the subtle notion of [v]p|r?

This would be my proposed fix for the unified pcm device mode, plus some man page amendments.

In D46409#1063484, @br wrote:

In D46409#1063483, @dev_submerge.ch wrote:

I will write the HDSP equivalent and add the missing unified pcm device part there, for comparison. Hopefully this weekend.

I don't have recording equipment to check but I assume yes.
sounds good

This implements extension board support for snd_hdsp(4), similar to D46409 for snd_hdspe(4).

In D46680#1067378, @christos wrote:

In D46680#1066259, @dev_submerge.ch wrote:

@dev_submerge.ch Any comments? As I mention in the commit message, wanting to sort in descending order (and as a result, breaking the mechanism proposed in D46550) is highly unlikely, but I think it's good to be on the safe side.

Using existing KPI is a plus, but the *_unr() is quite complex. It introduces another mutex and additional allocations in our case. Regarding the issue discussed in D46520, this makes the runtime implications non-obvious. We'll have to test that. Also this change trades the list order requirement in for the complexity of an additional unr allocation that we must not leak.

I am aware of this. The main rationale is to make the code more fail-proof. That being said, I am not totally against simply adding a warning comment in pcm_chn_add() and just going with the initial approach, as well as the assumption that the list will always be sorted in ascending order.

@dev_submerge.ch Any comments? As I mention in the commit message, wanting to sort in descending order (and as a result, breaking the mechanism proposed in D46550) is highly unlikely, but I think it's good to be on the safe side.

In D46520#1064256, @dev_submerge.ch wrote:

I suspect the traversal of the channel list to have an impact. If we traverse it for every allocation, and the list getting longer, we get O(N^2) for N allocations. That should be easy to prove by doing a benchmark of allocations with few vchans and compare that to situations with 1'000, 10'000 and 100'000 preallocated vchans.