Page MenuHomeFreeBSD

sound(4): implement playback/recording mode sysctl
ClosedPublic

Authored by christos on Jul 27 2021, 11:52 AM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 11 2024, 1:11 AM
Unknown Object (File)
Oct 11 2024, 1:10 AM
Unknown Object (File)
Oct 11 2024, 1:10 AM
Unknown Object (File)
Oct 11 2024, 1:08 AM
Unknown Object (File)
Oct 10 2024, 10:12 PM
Unknown Object (File)
Oct 1 2024, 3:59 AM
Unknown Object (File)
Sep 30 2024, 9:41 PM
Unknown Object (File)
Sep 30 2024, 9:31 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

christos created this revision.
christos edited the summary of this revision. (Show Details)

I think s/status/feature/ is a better word?

What do you think?

--HPS

I think s/status/feature/ is a better word?

What do you think?

--HPS

"feature" is not clear enough in my opinion.

Are there other options for naming.

Status is usually something that can change. But this is more like a property.

Are there other options for naming.

Status is usually something that can change. But this is more like a property.

True. "status" does match with "playback/recording status" but it does also imply variability. I cannot come up with a better name for it at the moment though.

Could you check an english dictionary with synonyms?

Could you check an english dictionary with synonyms?

function, action or operation could also be options.

Does the word "mode" make sense to you?

Does the word "mode" make sense to you?

"mode" is the best proposal so far indeed! :-)

OK! Can you update the patch to use "mode"?

christos retitled this revision from sound(4): implement playback/recording status sysctl to sound(4): implement playback/recording mode sysctl.
christos edited the summary of this revision. (Show Details)

OK! Can you update the patch to use "mode"?

Done!

This revision is now accepted and ready to land.Jul 28 2021, 11:15 AM
This revision now requires review to proceed.Jul 28 2021, 2:04 PM

What is the motivation for changing this?

What is the motivation for changing this?

It's more consistent _both_ with the rest of the flag values in the file
(e.g SD_F_*) and with how flags are handled in userland; now we
can AND the value of mode with any of the flags. If PCM_MODE_NONE's
value is 0x00, we have to specifically check if mode == 0 too see if
PCM_MODE_NONE is set, which makes things a bit more messy --
at least in my opinion.

PCM_MODE_NONE usually means MIDI. Could you investigate that a bit?

PCM_MODE_NONE usually means MIDI. Could you investigate that a bit?

Should we even have that flag in this case? If it's MIDI, is there a chance it would show up under PCM in the first place?

Yes, MIDI devices are also PCM devices, but there is no /dev/dspX device.

Let me have a look. Do you have a USB MIDI device at hand?

--HPS

Yes, MIDI devices are also PCM devices, but there is no /dev/dspX device.

Let me have a look. Do you have a USB MIDI device at hand?

--HPS

Sadly no, I'm still on vacation.

sys/dev/sound/pcm/sound.c
1024

Change this into:

if (d->mixer_dev != NULL)
mode |= PCM_MODE_MIXER;

And remove PCM_MODE_NONE. It doesn't make sense to me.

sys/dev/sound/pcm/sound.h
414

Change PCM_MODE_NONE into PCM_MODE_MIXER

Replaced PCM_MODE_NONE with PCM_MODE_MIXER.

This revision is now accepted and ready to land.Aug 6 2021, 9:30 AM