Can somebody clarify audio options?

Hoping to get Intel Skylake / Intel HD 530 audio working
A patch was written for FreeBSD 13.1-Release sys/dev/sound/pci/hda/hdac.c which reportedly works though perhaps with an occasional glitch if the system goes into sleep mode.
But is there any way of conveying the info that's in the patch to other FreeBSD version via a configuration file like device.hints or the like? i.e. can BSD be told how to use the audio without creating a custom system for it?
 
I have a page on pipewire, that mentions how I dealt with it. https://srobb.net/pipewire.html. It's mostly about Linux so to save you going through the whole page:
FreeBSD does have pipewire, but doesn't have the wpctl command. To switch between laptop and HDMI speakers, one can cat /dev/sndstat to see what you have. For example, my T495 Thinkpad's /dev/sndstat is
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <ATI R6xx (HDMI)> (play)
pcm2: <ATI R6xx (HDMI)> (play)
pcm3: <Realtek ALC257 (Analog 2.0+HP/2.0)> (play/rec) default
pcm4: <Realtek ALC257 (Right Analog Mic)> (rec)
No devices installed from userspace.
Note that the default is pcm3, which refers to the laptop speakers. To get it to use HDMI, I can edit it on the fly with

sysctl hw.snd.default_unit=1


This switches the default to HDMI. Once disconnected from the TV, I can go back to the laptop speakers with

sysctl hw.snd.default_unit=3


If you use this frequently, it might be worth making a shell script.
TL;DR
cat /dev/sndstat
See which pcm entry is for hdmi
Code:
sysctl hh.snd.default_unit=<whatever pcm points to hdmi>
 
Have you tried 13.2-RELEASE? There have been a number of patches applied to the hda(4) driver since 13.1-RELEASE. And most of them have been done after this post was made.


https://cgit.freebsd.org/src/log/sys/dev/sound/pci/hda?h=releng/13.2
https://cgit.freebsd.org/src/log/sys/dev/sound/pci/hda?h=releng/13.1
Yeh, thanx. 13.2 is the version that can not send audio to the HDMI / pcm2. Disappointing 13.2 didn't include the patch made last year but what can one do about past failures.
 
Disappointing 13.2 didn't include the patch made last year
The patch was posted on the DRM code repository, not the FreeBSD repository. The patch is for FreeBSD itself, not the DRM driver. I haven't dug through the PRs of FreeBSD to see if it was submitted there.
 
I have a page on pipewire, that mentions how I dealt with it. https://srobb.net/pipewire.html. It's mostly about Linux so to save you going through the whole page:

TL;DR
cat /dev/sndstat
See which pcm entry is for hdmi
Code:
sysctl hh.snd.default_unit=<whatever pcm points to hdmi>
Thanks much, unfortunately I don't think that's the problem. Release 13.2 recognizes the Intel HD 530 as vga and creates a pmc2 for its audio, selecting pcm2 is when the problem arose, the problem is that the pcm2 doesn't work; pointing hw.snd to the correct pcm (#2 in this case) results in silence, as I understand it that's what the patch last year was fixing.
Code:
# cat /dev/sndstat
Installed devices:
pcm0: <Realtek ALC233 (Analog 2.0+HP/2.0)> (play/rec)
pcm1: <Realtek ALC233 (Analog)> (play/rec)
pcm2: <Intel Skylake (HDMI/DP 8ch)> (play) default
No devices installed from userspace.

N.B. increasing verbosity gives this detail about pcm2:
Code:
pcm2: <Intel Skylake (HDMI/DP 8ch)> on hdaa1  (1p:1v/0r:0v) default
    snddev flags=0x2e7<SIMPLEX,AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC>
    [pcm2:play:dsp2.p0]: spd 48000, fmt 0x00200010, flags 0x00006100, 0x00000004
    interrupts 0, underruns 0, feed 0, ready 0 [b:2048/1024/2|bs:2048/1024/2]
    channel flags=0x6100<BUSY,HAS_VCHAN,VCHAN_PASSTHROUGH>
    {userland} -> feeder_mixer(0x00200010) -> {hardware}
    pcm2:play:dsp2.p0[pcm2:virtual:dsp2.vp0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000
    interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0]
    channel flags=0x10000000<VIRTUAL>
    {userland} -> feeder_root(0x00000000) -> {hardware}
 
Intel Skylake
Well, OP does mention Intel Skylake chipset, which is from 2015 (A quick Google search told me that). Usually, machines from that time (esp. desktop towers) have multiple audio outputs, some in front, some in the back, some on top of the case. They'd correspond to /dev/pcm0, /dev/pcm1, /dev/pcm2, and so on.

But hardware that old can get rusty. So if one output is not working, try the next. I did have that happen to me a few times in the past, and simply selecting the next /dev/pcmN usually solved the issue for me.

But yeah, I usually have my system plugged in, so I don't let it sleep - even on Windows, system sleep is kinda messed up.
 
Back
Top