Created attachment 259393 [details] patch for diff I have several machines spitting out something like mixer: speaker.volume=0.00:0.00: Device not configured on the console during boot. The reason is: On shutdown, /etc/rc.d/mixer writes the state of all mixers to /var/db using "mixer -f ${dev} -o". On reboot, /etc/rc.d/mixer tries to restore the last state using "mixer -f ${dev} `cat ${file}`". "mixer -f ${dev}" (with or w/o -o) walks through all devices, not taking into account if the corresponding device actually exists. The result is that non-existing devices (and their values) are being saved (in this case "speaker.volume") and these can't be restored. This patch fixes this by skipping devices which do not exist.
The devices mixer(8) lists are already devices that exist, mixer(3) takes care of that, so it does not walk through _all_ devices. Also note that this is just a warning and not a fatal error. Can you share the output of mixer -o for the device you're hitting this error on?
(In reply to Christos Margiolis from comment #1) > ... are already devices that exist... This is what I thought as well. But for whatever reasons this speaker device is in the list but isn't there (and this is correctly reflected in the SOUND_MIXER_READ_DEVMASK bits). Here is the output of /dev/mixer1 (the device where it happens on one machine): vo:~>mixer -f /dev/mixer1 -o vol.volume=0.85:0.85 vol.mute=off bass.volume=0.75:0.75 bass.mute=off treble.volume=0.75:0.75 treble.mute=off pcm.volume=1.00:1.00 pcm.mute=off speaker.volume=0.00:0.00 speaker.mute=off rec.volume=0.86:0.86 rec.mute=off igain.volume=0.00:0.00 igain.mute=off ogain.volume=1.00:1.00 ogain.mute=off monitor.volume=0.83:0.83 monitor.mute=off monitor.recsrc=add On another machine: ba:~>mixer -f /dev/mixer1 -o vol.volume=0.84:0.84 vol.mute=off bass.volume=0.50:0.50 bass.mute=off treble.volume=0.50:0.50 treble.mute=off pcm.volume=1.00:1.00 pcm.mute=off speaker.volume=0.00:0.00 speaker.mute=off mic.volume=0.67:0.67 mic.mute=off mic.recsrc=add rec.volume=0.35:0.35 rec.mute=off igain.volume=0.00:0.00 igain.mute=off ogain.volume=1.00:1.00 ogain.mute=off An another one (here it is mixer2): bb2:~>mixer -f /dev/mixer2 -o vol.volume=0.85:0.85 vol.mute=off bass.volume=0.50:0.50 bass.mute=off treble.volume=0.47:0.47 treble.mute=off pcm.volume=1.00:1.00 pcm.mute=off speaker.volume=0.00:0.00 speaker.mute=off rec.volume=0.35:0.35 rec.mute=off igain.volume=0.00:0.00 igain.mute=off ogain.volume=1.00:1.00 ogain.mute=off monitor.volume=0.56:0.56 monitor.mute=off monitor.recsrc=add On the first two machines (the ones with mixer1 being affected), there is also a speaker on mixer0 where it does not complain. On the last box (mixer2 being affected) there is a speaker on mixer1. Assuming all these boxes have only one classic speaker device and this is handled on mixer(X-1) could it be that the speaker is incorrectly added to the mixers being affected? One more note: This started to appear with one of the sound commits a few weeks ago. Unfortunately I can't say which one was it exactly but greping through /var/log/console* on the box which builds the latest 14-STABLE it started on 2025-03-11.
I'm pretty sure this is a result of a recent commit I pushed [1] to address PR 279787 [2]. As the commit message says (see PR for more context), the only functional change of this commit is that we're now not ignoring _recording_ devices with no _software_ volume control, because they might still be able to be used as recording sources, as was the case for the PR submitter. The "speaker" device seems to be a recording device in your case (in my machine too). The problem here seems to be that your "speaker" device actually cannot be used as a recording source either (no "recsrc" control), which to me indicates that this might be a driver issue, and not a mixer one. Which driver is this? You can share mixer(8) without -o. [1] https://cgit.freebsd.org/src/commit/?id=f121de8fbcbc8aa82f9fb59039c502406b7c88b6 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279787
(In reply to Christos Margiolis from comment #3) > ... a result of a recent commit I pushed ... Regarding the date this is quite possible. > Which driver is this? They are all Realtek: vo:~>mixer -f /dev/mixer1 pcm1:mixer: <Realtek ALC235 (Front Analog)> on hdaa0 (play/rec) vol = 0.85:0.85 pbk bass = 0.75:0.75 pbk treble = 0.75:0.75 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec rec = 0.86:0.86 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk monitor = 0.83:0.83 rec src ba:~>mixer -f /dev/mixer1 pcm1:mixer: <Realtek ALC892 (Rear Analog)> on hdaa0 (play/rec) vol = 0.84:0.84 pbk bass = 0.50:0.50 pbk treble = 0.50:0.50 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec mic = 0.67:0.67 rec src rec = 0.35:0.35 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk bb2:~>mixer -f /dev/mixer2 pcm2:mixer: <Realtek ALC671 (Front Analog)> on hdaa1 (play/rec) vol = 0.85:0.85 pbk bass = 0.50:0.50 pbk treble = 0.47:0.47 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec rec = 0.35:0.35 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk monitor = 0.56:0.56 rec src
What happens if you do: mixer -f /dev/mixer1 speaker.recsrc=add
(In reply to Christos Margiolis from comment #5) On which machine? vo:~>mixer -f /dev/mixer1 speaker.recsrc=add speaker.recsrc: remove -> add pcm1:mixer: <Realtek ALC235 (Front Analog)> on hdaa0 (play/rec) vol = 0.85:0.85 pbk bass = 0.75:0.75 pbk treble = 0.75:0.75 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec src rec = 0.86:0.86 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk monitor = 0.83:0.83 rec src ba:~>mixer -f /dev/mixer1 speaker.recsrc=add speaker.recsrc: remove -> add pcm1:mixer: <Realtek ALC892 (Rear Analog)> on hdaa0 (play/rec) vol = 0.84:0.84 pbk bass = 0.50:0.50 pbk treble = 0.50:0.50 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec src mic = 0.67:0.67 rec src rec = 0.35:0.35 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk bb2:~>mixer -f /dev/mixer1 speaker.recsrc=add speaker.recsrc: remove -> add pcm1:mixer: <Realtek ALC671 (Analog)> on hdaa1 (play/rec) (default) vol = 0.85:0.85 pbk bass = 0.50:0.50 pbk treble = 0.47:0.47 pbk pcm = 1.00:1.00 pbk speaker = 0.00:0.00 rec src line = 0.01:0.01 rec src mic = 0.56:0.56 rec src mix = 0.74:0.74 rec rec = 0.35:0.35 pbk igain = 0.00:0.00 pbk ogain = 1.00:1.00 pbk A following "mixer -f X `mixer -f X -o`" (with X being the problematic mixer) still complains about "Device not configured"... If it is OK four you, we should stick to one box for the tests -- best would be bb2 on my side (with mixer2 being affected).
We can stick to one machine, yes. I see that you can actually set "speaker" as a recording source, so we shouldn't skip the device, but perhaps only its volume control.
(In reply to Christos Margiolis from comment #7) To be honest, I actually don't know what this speaker setting is for :-). Does it has anything to do with /dev/speaker? I don't think so. Playing with its settings doesn't change anything during playback or recording...
(In reply to Andre Albsmeier from comment #8) I'm slightly confused with the use of this control in the snd_hda(4) driver. Can you do a verbose boot and share the output of dmesg? I think it might contain information on what its function is.
Created attachment 259574 [details] dmesg Here is the sound related stuff of a verbose boot on bb2 (the box where mixer2 is the problematic one). What might be interesting are the "DISA" notes: hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
I think this is just another example of how overly complex, arbitrary and really, terrible HDA sound cards tend to be... There is also this (seemingly related) article that tries to reverse-engineer this beeper register: https://www.kernel.org/doc/html/latest/sound/hd-audio/realtek-pc-beep.html So according to your dmesg (it shows up in a few other places as well): pcm2: nid=9 [audio input] pcm2: + <- nid=34 [audio selector] [src: speaker, monitor] pcm2: + <- nid=25 [pin: Mic (Black Jack)] [src: monitor] pcm2: + <- nid=29 [beep widget] [src: speaker] pcm2: The "speaker" control is mapped to the beep widget (last line). Here is where it's defined in snd_hda(4): case HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_BEEP_WIDGET: use = SOUND_MIXER_SPEAKER; Looking a bit more into snd_hda(4)'s code, there is this comment in hdaa_widget_patch(): /* On some codecs beeper is an input pin, but it is not recordable alone. Also most of BIOSes does not declare beeper pin. Change beeper pin node type to beeper to help parser. */ In your dmesg I also see the following message from hdaa_widget_patch(), which essentially marks nid=29 as a beeper pin: hdaa1: Patching widget caps nid=29 0x00400000 -> 0x00700000 So, even after reading the article, I can say I do not really understand the use for this, but there doesn't seem to be something wrong with mixer(8) or snd_hda(4) necessarily. Also, unrelated to our discussion, but looking at your pin configuration: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 50030040 4 0 Line-out None ATAPI Internal Unknown 0 DISA hdaa1: 20 02211020 2 0 Headphones Jack 1/8 Front Black 0 hdaa1: 23 99130110 1 0 Speaker Fixed ATAPI Onboard Unknown 1 hdaa1: 24 01a19040 4 0 Mic Jack 1/8 Rear Pink 0 hdaa1: 25 02a11050 5 0 Mic Jack 1/8 Front Black 0 hdaa1: 26 0181304f 4 15 Line-in Jack 1/8 Rear Blue 0 hdaa1: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: 33 01014030 3 0 Line-out Jack 1/8 Rear Green 0 Does your sound work correctly at all? That is, do headphones, speakers, microphone work properly? Can you switch between speakers and headphones for example?
(In reply to Christos Margiolis from comment #11) > Does your sound work correctly at all? I don't know :-). On this machine (bb2) I don't use sound. It is just one of those where the warning message occured.
(In reply to Christos Margiolis from comment #11) > So, even after reading the article, I can say I do not really understand the use for this, but there doesn't seem to be something wrong with mixer(8) or snd_hda(4) necessarily. Well, I just noted that the error message started to appear a few weeks ago. I know that it definitely wasn't there before. By analysing mixmos I found that it filters available devices depending on SOUND_MIXER_READ_DEVMASK. I don't know what this speaker device actually is for, but if its bit isn't set in SOUND_MIXER_READ_DEVMASK, I assume that most sound related software won't use it. If one should be able to use its recording source feature, I think your idea of skipping volume setting of these devices is the best solution.
(In reply to Andre Albsmeier from comment #13) The warning started appearing a few weeks ago because of the commit I pushed, true. However, the problem is not related to that commit, it's a driver issue. So I think complicating mixer(8) to catch this is not the correct solution. I think we can just ignore it. Also if you have the time, please test the sound on that device. I'm pretty sure some things will not work out of the box. If there are problems, open a new PR, as I'm going to be closing this one.
(In reply to Christos Margiolis from comment #14) > ... it's a driver issue. ... So should I open a new PR to address the driver issue?
(In reply to Andre Albsmeier from comment #15) Not sure, because as I said in a previous comment, I'm not if that's an issue we really should care about or not. That's why I'd suggest first seeing if audio works, and then we can go from there.
(In reply to Christos Margiolis from comment #16) What I had tested on this very machine (bb2) is audio output on external speakers when connected through the 3,5 mm rear jack. This works. But we can also switch to another machine (vo) where the issue appears as well and where I use audio daily...
(In reply to Andre Albsmeier from comment #17) Feel free to open a PR if something doesn't work. You should test: - Audio on speakers. - Audio on headphones. - Whether audio switches automatically from speakers to headphones when headphones are plugged, and vice-versa. - Microphone. - Headset microphone if you have one. - Whether the microphone input switches from internal to headset if you plug the headset mic (again, if you have one).