sound: Implement dummy driver

[christos]

Summary

Sponsored by: The FreeBSD Foundation
MFC after: 2 days

[christos]

Consider this a WIP.

1. This driver can be attached only once, since it's attached on kldload. Is there a point where we'd want to lock the softc?
2. Reading/writing doesn't really "work", the channel will timeout after hw.snd.timeout.

[christos]

Add SPDX identifier.

[dev_submerge.ch]

I know it's WIP, but it would be nice to have a brief comment or description somewhere, to document what is and what is not implemented / working.

sys/dev/sound/dummy.c

89–90

Do we have to free() buf and caps in the error case here?

124

Maybe check that speed is inside the [8000, 96000] range we advertise in the caps?

[christos]

• Add man page
• Free buf and caps in chan_init() failure
• Clamp speed between caps->minspeed and caps->maxspeed

[christos]

sys/dev/sound/dummy.c

89–90

In case of failure, chn_init() (the consumer of this function) calls CHANNEL_FREE() only if haven't returned NULL from here, so yes. This leak exists in other hdsp* drivers as well I think.

124

I initially had this check but removed it because callers of CHANNEL_SETSPEED() either clamp speed between caps->minspeed and caps->maxspeed, or use valid speeds (i.e taken directly from the channels) before passing it to CHANNEL_SETSPEED. That being said, I don't think it'd hurt to have the check here as well for robustness.

[christos]

Implement IO using callout(9). Playback discards input, recording returns
silence (zeros).

For some reason on my machine having KASAN enabled panics when bzero() is
called from callout_init().

I do not guarantee the stability of this driver, so consider it a WIP until
more testing is done.

[markj]

sys/dev/sound/dummy.c

289

This should be sizeof(struct dummy_softc).

[christos]

Add "rec" mixer device to recording devices.

[christos]

sys/dev/sound/dummy.c

289

If it attaches to the PCM driver, shouldn't the softc size be PCM_SOFTC_SIZE as well? In dummy_attach() (and all sound drivers' attach routines), we call pcm_register(), which expects the softc to be a struct snddev_info.

[markj]

sys/dev/sound/dummy.c

289

Hmm, strange. You can always put a struct snddev_info at the beginning of your softc, and then pcm_register() will work.

You're fetching the dummy softc as a driver ivar, but I don't see how that works - nothing is calling device_set_ivars(). Who is responsible for allocating the softc, and why is the softc pointer stored in ivars? ivars are usually used by bus drivers.

[christos]

Fix "random" panic caused by using PCM_SOFTC_SIZE instead of sizeof(struct dummy_softc): embed an snddev_info to dummy_softc and call
device_get_softc() instead of device_get_ivars() in dummy_attach().

[christos]

• Improve IO.
• Implement CHANNEL_TRIGGER() and CHANNEL_GETPTR().
• Reorganize channels and caps better.
• Add locking.

[dev_submerge.ch]

share/man/man4/snd_dummy.4

50 ↗

(On Diff #141042)

I would omit the "physical" here, IMHO it confuses more than it helps.

53–56 ↗

(On Diff #141042)

Stating that audio data is processed at regular intervals is fine, but the callout(9) is more of an implementation detail, and not relevant to the user / tester?

sys/dev/sound/dummy.c

148–150

Shouldn't this be

for (i = 0; ch->caps->fmtlist[i]; i++)

[christos]

Address comments.