Bug 279285
| Summary: | no sound on stable/14 with vchans disabled and bitperfect setup. | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Oleh Vinichenko <moonlapse81> | ||||||||||||||
| Component: | misc | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||||||||||
| Status: | Closed Not A Bug | ||||||||||||||||
| Severity: | Affects Only Me | CC: | christos, emaste | ||||||||||||||
| Priority: | --- | ||||||||||||||||
| Version: | 14.0-STABLE | ||||||||||||||||
| Hardware: | amd64 | ||||||||||||||||
| OS: | Any | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 250940 [details]
sysctl dev.pcm
Created attachment 250941 [details]
sysctl dev.hdac
Created attachment 250942 [details]
relevant part of sysctl.conf
Created attachment 250943 [details]
cat /dev/sndstat
Created attachment 250944 [details]
output of `mixer` command
Hello Oleh, In the description you are mentioning things working fine after reverting back to 8771127d75a1295dd32abd0022ff3750bc56470. It would be more helpful if you could start applying the commits after it one by one and let me know at which commit exactly things start breaking. i will try most recent changes first. and then start reverting back. unfortunately, very latest changes did not change the situation. i will start reverting of /usr/src before commit 8771127d75a1295dd32abd0022ff3750bc56470. is there more robust way of doing it? because i need to recompile every commit to sound system and reboot each time. it is not a problem simply too laborious. also, are the commits related, or independent of each other? in latter case it make sense to go through every commit one by one. (In reply to Oleh Vinichenko from comment #8) So, I have one or two commits after 8771127d75a1295dd32abd0022ff3750bc564706 in mind that could potentially be the culprit, but I want to ask the following first: 1. Do you get sound with VCHANs and without bitperfect? 2. Is there any message related to the problem, popping up on dmesg(8) once the device is attached? Perhaps you can attach the output of dmesg(8) after a verbose boot. 3. Is it a specific application that breaks or do you not have sound in general? 4. Can you provide /dev/sndstat with hw.snd.verbose=2 set? i was too early in my conclusions about sound changes are root cause of a problem. in reality, the problem is suspend. when sound card is taken by an application such as musicpd and notebook is then goes into suspend state, either by `zzz` or lid close, upon returning back from suspend, there is no sound. the symptom is as if sound is completely muted, there is no error from application, nothing in dmesg. it keeps playing as before but with no output. i think this report can be closed as not valid. i will probably file new one based on new observations. |
Created attachment 250939 [details] sysctl hw.snd i follow stable/14 on my thinkpad t480 with vchans disabled and bitperfect mode enabled for intel hda. it worked well until very recent added changes to sound(4). now i hearing no sound at all while the application is working ( musicpd in my case ). either from speakers or headphones. reverting the src tree all the way back until commit 8771127d75a1295dd32abd0022ff3750bc564706, which is the first commit of sound system changes restores the state with working sound.