Solved No sound bhyve with HDA - win10 client

Hi,
after building bhyve with hda-support, no sound is produced. (https://wiki.freebsd.org/SummerOfCode2016/HDAudioEmulationForBhyve)
bhyve was invoked with bhyve -c 2 -m 4G -H -w -s 0,hostbridge -s 3,ahci-cd,null_dvd.iso -s 4,ahci-hd,w10_disk.img -s 5,virtio-net,tap0 -s 6,hda,play=/dev/dsp,rec=/dev/dsp -s 29,fbuf,tcp=0.0.0.0:5900,wait -s 30,xhci,tablet -s 31,lpc -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd win10
Client (Win 10) detects sound-device and all drivers has been installed. Client-device was ready.
But no sound .is generated.
Host device /dev/dsp is working properly;
cat some.txt > /dev/dsp produces sound, mixer works...
The hda-logfile shows:
Code:
hda_init-376: opts: play=/dev/dsp,rec=/dev/dsp
hda_reset_regs-593: Reset the HDA controller registers ...
hda_parse_config-336: opts: play=/dev/dsp,rec=/dev/dsp
hda_parse_config-336: opts: play=/dev/dsp,rec=/dev/dsp
hda_init-392: play: /dev/dsp rec: /dev/dsp
hda_codec_init-335: cad: 0x0 opts: (null)
hda_codec_init-355: HDA Codec nodes: 6
hda_audio_ctxt_thr-784: Start Thread: hda-audio-output
hda_audio_ctxt_thr-784: Start Thread: hda-audio-input
pci_hda_read-1332: offset: 0x8 value: 0x0
pci_hda_read-1332: offset: 0x8 value: 0x0
pci_hda_write-1311: offset: 0x8 value: 0x0
hda_reset_regs-593: Reset the HDA controller registers ...
hda_codec_reset-421: cad: 0x0
hda_signal_state_change-1105: cad: 0x0
pci_hda_read-1332: offset: 0x8 value: 0x0
pci_hda_read-1332: offset: 0x8 value: 0x0
pci_hda_write-1311: offset: 0x8 value: 0x1
pci_hda_read-1332: offset: 0x8 value: 0x1
pci_hda_read-1332: offset: 0x0 value: 0x4401
pci_hda_read-1332: offset: 0x3 value: 0x1

changed...
Code:
hw.snd.latency: 0
but has no effect
Do you have any hints for debugging?
 
This not an advice to the OP, but another approach.
I had hard time configuring sound too, then I found it's much easier to do via an RDP client.
I installed net/freerdp and made a script with:
Code:
xfreerdp -grab-keyboard /bpp:24 /w:1916 /h:1060 /v:$HOST /u:$USER /p:$PWD /clipboard /drive:home,/home/$USER /fonts /sound:sys:oss,dev:3 /microphone:sys:oss,format:1
Works like a charm.
 
I think you'll have to disable the capsicum sandbox (the hda work hasn't been capsicum'ized yet).

Apply this hack^h^h^hdiff to your bhyve checkout and rebuild, and see if that helps:

Code:
@@ -988,8 +988,8 @@
     if (caph_limit_stdout() == -1 || caph_limit_stderr() == -1)
         errx(EX_OSERR, "Unable to apply rights for sandbox");
-   if (cap_enter() == -1 && errno != ENOSYS)
-       errx(EX_OSERR, "cap_enter() failed");
+   //if (cap_enter() == -1 && errno != ENOSYS)
+   //   errx(EX_OSERR, "cap_enter() failed");
 #endif
 
it works!

but unfortunately

Code:
if (caph_limit_stdout() == -1 || caph_limit_stderr() == -1)
        errx(EX_OSERR, "Unable to apply rights for sandbox");
has to be commented out, because
Code:
caph_limit_stdout()
and
Code:
 caph_limit_stderr()
where undefined.

the way with rdp client is still untested.
 
The RDP client is always going to be much better for Windows guests than bhyve/vnc/hda - the server side is owned by Microsoft so has deep hooks into the relevant graphics/audio/input subsystems to dish out the best quality and performance.
 
Yes, an RDP Client seems to the best way to connect; even keymapping for non-us works perfect
 
it works!

but unfortunately

Code:
if (caph_limit_stdout() == -1 || caph_limit_stderr() == -1)
        errx(EX_OSERR, "Unable to apply rights for sandbox");
has to be commented out, because
Code:
caph_limit_stdout()
and
Code:
 caph_limit_stderr()
where undefined.

the way with rdp client is still untested.

Hmm, I just tried the HD Audio patch with https://reviews.freebsd.org/D12419 but I still can't get no sound. Any hints on how to proceed? Trying out with debian as guest. Sound on the host is working fine. I'm running FreeBSD current revision 336272.

Debug output from /tmp/bhyve_hda.log
Code:
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x0
pci_hda_write-1307: offset: 0x103 value: 0x1c
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x1
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x1
hda_stream_reset-621: Reset the HDA stream: 0x4
pci_hda_read-1326: offset: 0x100 value: 0x1
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x1 value: 0x0
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x118 value: 0x0
pci_hda_write-1307: offset: 0x11c value: 0x0
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x0
pci_hda_write-1307: offset: 0x103 value: 0x1c
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x500000
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x500000
pci_hda_write-1307: offset: 0x108 value: 0x56220
pci_hda_write-1307: offset: 0x112 value: 0x4011
pci_hda_write-1307: offset: 0x10c value: 0x2
pci_hda_write-1307: offset: 0x118 value: 0x3a80e000
pci_hda_write-1307: offset: 0x11c value: 0x0
pci_hda_read-1326: offset: 0x70 value: 0x3bc22001
pci_hda_read-1326: offset: 0x100 value: 0x500000
pci_hda_write-1307: offset: 0x100 value: 0x50001c
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x500000 value: 0x50001c
pci_hda_read-1326: offset: 0x110 value: 0x100
pci_hda_read-1326: offset: 0x100 value: 0x50001c
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x50001c value: 0x500000
pci_hda_write-1307: offset: 0x103 value: 0x1c
pci_hda_read-1326: offset: 0x100 value: 0x500000
pci_hda_write-1307: offset: 0x100 value: 0x1
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x500000 value: 0x500001
hda_stream_reset-621: Reset the HDA stream: 0x4
pci_hda_read-1326: offset: 0x100 value: 0x1
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x1 value: 0x0
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x0
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x0
pci_hda_write-1307: offset: 0x103 value: 0x1c
pci_hda_read-1326: offset: 0x100 value: 0x0
pci_hda_write-1307: offset: 0x100 value: 0x500000
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x0 value: 0x500000
pci_hda_write-1307: offset: 0x108 value: 0x56220
pci_hda_write-1307: offset: 0x112 value: 0x4011
pci_hda_write-1307: offset: 0x10c value: 0x2
pci_hda_write-1307: offset: 0x118 value: 0x3a80e000
pci_hda_write-1307: offset: 0x11c value: 0x0
pci_hda_read-1326: offset: 0x70 value: 0x3bc22001
pci_hda_read-1326: offset: 0x100 value: 0x500000
pci_hda_write-1307: offset: 0x100 value: 0x50001c
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x500000 value: 0x50001c
pci_hda_read-1326: offset: 0x110 value: 0x100
pci_hda_read-1326: offset: 0x34 value: 0x0
pci_hda_write-1307: offset: 0x34 value: 0x10
pci_hda_read-1326: offset: 0x30 value: 0xf59fc843
pci_hda_read-1326: offset: 0x20 value: 0xc0000000
pci_hda_write-1307: offset: 0x20 value: 0xc0000010
pci_hda_read-1326: offset: 0x100 value: 0x50001c
pci_hda_write-1307: offset: 0x100 value: 0x1e
hda_set_sdctl-1048: stream_ind: 0x4 old: 0x50001c value: 0x50001e
hda_stream_start-676: stream: 0x4 bdl_cnt: 0x3 bdl_paddr: 0x3a80e000
hda_stream_start-691: Fail to get the guest virtual address
pci_hda_read-1326: offset: 0x103 value: 0x20
pci_hda_read-1326: offset: 0x34 value: 0x10
pci_hda_write-1307: offset: 0x34 value: 0x0
pci_hda_read-1326: offset: 0x30 value: 0xf59ff302
 
This not an advice to the OP, but another approach.
I had hard time configuring sound too, then I found it's much easier to do via an RDP client.
I installed net/freerdp and made a script with:
Code:
xfreerdp -grab-keyboard /bpp:24 /w:1916 /h:1060 /v:$HOST /u:$USER /p:$PWD /clipboard /drive:home,/home/$USER /fonts /sound:sys:oss,dev:3 /microphone:sys:oss,format:1
Works like a charm.
Hello :) Could you, please, clarify a couple of things for me? Does not the guest have to be Win10 Pro to connect to it via RDP (a limitation that seems to exist in MS Win OS regarding RDP)? And secondly, how do you invoke bhyve itself so that you can then connect to it the way you describe in your post?

I once gave up on this stuff because I didn't have enough time to dig into it while having a solution that worked already. But I was and still am interested in a FreeBSD-based solution. So I'd be very thankful for any assistance here.
 
I use Windows 7 and up with that script.
It doesn't matter how you start bhyve, as long as the guest has a working network, there shouldn't be a problem.
A FreeBSD solution can be based on PCI passthrough, but in such case the sound card won't be available in the host.
 
...
A FreeBSD solution can be based on PCI passthrough, but in such case the sound card won't be available in the host.
That would mean upgrading my hardware, because my present CPU doesn't support that. But it seems they have done some work with the patch mentioned above. I"ll give it a try one of these days, when time permits.
 
This not an advice to the OP, but another approach.
I had hard time configuring sound too, then I found it's much easier to do via an RDP client.
I installed net/freerdp and made a script with:
Code:
xfreerdp -grab-keyboard /bpp:24 /w:1916 /h:1060 /v:$HOST /u:$USER /p:$PWD /clipboard /drive:home,/home/$USER /fonts /sound:sys:oss,dev:3 /microphone:sys:oss,format:1
Works like a charm.
Hey, aragats , I want to thank you once again for your very helpful advice on accessing bhyve Win 10 guest via net/xfreerdp. I'm completely satisfied with the results: full audio + shared folders with no need to bring in NFS or other network stuff. Just wonderful!!
If you don't mind, I'm gonna ask you some further questions (off-topic here) about bhyve hardware setup via PM.
 
Back
Top