Can't get audio output except for a simple beep

[ruapotato]

I can't figure out how to play audio from within a Linux env. I have testing building a Debian install with sox installed (Build scripts:https://git.sr.ht/~hamner/copyleftmage.school)
Running example: http://copyleftmage.school/v86/live/shell_full_boot.html
Relevant setup data:

window.onload = function() {
    var emulator = new V86Starter({
        wasm_path: "../build/v86.wasm",
        memory_size: 512 * 1024 * 1024,
        vga_memory_size: 8 * 1024 * 1024,
        screen_container: document.getElementById("screen_container"),
        cmdline: "rw init=/bin/systemd root=host9p console=ttyS0 spectre_v2=off pti=off",
        bios: {
            url: "../bios/seabios.bin",
        },
        vga_bios: {
            url: "../bios/vgabios.bin",
        },
        filesystem: {
            baseurl: "/v86/output/images/debian-rootfs-flat/",
            basefs: "/v86/output/images/debian-fs.json",
        },
        autostart: true,
        bzimage_initrd_from_filesystem: true,
        cmdline: [
            "rw",
            "root=host9p rootfstype=9p rootflags=trans=virtio,cache=loose",
            "init=/usr/bin/init-openrc",
        ].join(" "),
    });

Running arecord -l shows no sounds cards found.
Running beep plays a beep sound but also outputs no devices found. Options to change to tone don't work.
My goal is the build this site out to be a teaching tool, and audio would be a big help.

[copy]

Does it work in qemu (with -device sb16)?

[ruapotato]

I'm not 100% sure how to run this in qemu as it's just a chroot built by Debootstrap for the most part. If I chroot into the build_root, aplay is able to see sound devices just fine:

for i in dev sys proc
do
  mount --rbind /$i /build_root/$i
done
chroot /build_root/

(copyleftmage):/ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC700 Analog [ALC700 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
...

Build script: https://git.sr.ht/~hamner/copyleftmage.school/tree/master/item/build_image.sh

[copy]

@ruapotato That's a nice way to create v86 images. Could you try getting audio to work in qemu with one of the live images? Most likely it will be the same steps as in v86 (and if not, I can work out the difference).

[ruapotato]

What command do you use to stat qemu. I can't get my image to boot fully with qemu-system-x86_64 --drive media=cdrom,file=./bootable_ship\(1\).iso but it does boot just fine in gnome-boxes (which uses qemu as a back-end). Sadly it does not have sound in gnome-boxes:

Here is the ISO: http://copyleftmage.school/bootable_ship.iso
And the iso build script: https://git.sr.ht/~hamner/copyleftmage.school/tree/master/item/chroot_to_iso.sh

[ruapotato]

Testing qemu-system-x86_64 -soundhw all --drive media=cdrom,file=./debian-live-11.2.0-i386-mate.iso does the same thing as my .iso and kernel panics.

[grapeli]

Sound Blaster 16 works. Unfortunately, it is not detected automatically by PnP. There are messages related to this in the linux kernel log under debian.

PnPBIOS: dev_node_info: function not supported on this system
PnPBIOS: Unable to get node info. Aborting

Solution. Initialize sb16 to run - manually.
After starting, type in the console:
sudo modprobe snd-sb16 isapnp=0 port=0x220 irq=7 dma8=1 dma16=5
or add the appropriate parameters to boot the kernel, you will modify them by pressing "tab" and typing
snd-sb16.isapnp=0 snd-sb16.port=0x220 snd-sb16.irq=7 snd-sb16.dma8=1 snd-sb16.dma16=5.

[ruapotato]

@grapeli Thank you for the feedback! I was able to get it to make some kind of sound, but I still get an error running: modprobe snd-sb16 isapnp=0 port=0x220 irq=7 dma8=1 dma16=5
Error: no OPL device at 0x220-222

odd_sound.mp4

[grapeli]

I don't see any error here.
The information from the sb16 driver is shown that the system responsible for FM OPL synthesis has not been found.

[copy]

@grapeli Excellent, thanks for your help. Will update the online Arch Linux image soon.

@ruapotato The following works for me:

modprobe snd-sb16 isapnp=0 port=0x220 irq=7 dma8=1 dma16=5
amixer -q set Master 80%
amixer -q set Treble 80%
amixer -q set Bass 80%
amixer -q set PCM 80%
aplay /usr/share/sounds/alsa/Front_Center.wav

[grapeli]

@copy
It works for me. I confirm.

copy.sh.sb16.linux.mp4

[ruapotato]

This seems like it might need it's own topic as it's at least making sound now. Any idea why I'm getting this strange clicking sound?

Still_odd_sounds.mp4

[grapeli]

I checked under Debian live-11.2.0-i386. In fact, at the exit of the sound card sb16 we will only hear an unpleasant squeak.

This debian uses kernel 5.10.x. I checked on a vanilla kernel from this series and it's identical. Everything is fine under qemu with -device sb16. This regression only affects copy.sh. Probably it does not concern the snd-sb16 driver itself, and maybe even the sound subsystem. I have no inspiration at the moment to make a full git bisect.

In general, it looks like this (vanilla kernel).
linux-5.16.9 good
linux-5.15.23 bad
...
...
...
linux-5.10.100 bad
linux-5.9.16 good
linux-4.19.229 good

[grapeli]

@ruapotato
One more general note. Using a ready-made Linux distribution under copy.sh doesn't make much sense. He is tailored to meet other needs. Not adapted to this modestly powered virtual machine running in the browser. Maybe this debian will run satisfactorily on Coreduo2 2GHz or on Pentium IV 2.4GHz. Unfortunately not here.

To get satisfactory results with copy.sh you have to adjust the linux system very well. Starting with a good kernel configuration to proper optimization of the entire userland.

In order not to be groundless, make a very simple benchamrk.
I will compile this fibonacci program under Debian.
gcc -O3 -march=i686 -mtune=pentium3 -o fibonacci fibonacci.c
Run it in debian under copy.sh.
time ./fibonacci 42
Then run this one fibonacci.zip compiled with a completely different gcc-4.7.4 compiler.
time ./fibonacci 42
As it turns out, the same c code copied with a completely different compiler works 2x faster under copy.sh. Such situations absolutely do not happen when you will run this code directly on the host. Yes, the differences can be in the range of 1-30% but not more with the penetration there will not be a colossal 200% difference.

[copy]

I added audio to the Arch Linux profile using the commands mentioned in #616 (comment). @ruapotato Could you try and see if the sound works for you? (the issue could be specific to certain browsers, or guests, or both).

@grapeli Interesting performance issue. There's likely some instruction that v86 doesn't optimise, or some tricky control flow. Unfortunately many profiler are broken in the presence of wasm modules (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1754258), so it's tricky to analyse. I'll have a look at a later point.

[ruapotato]

@copy and @grapeli Thank you both for the help. I was able to test the Arch Image and confirm it is working. I may end up picking a more v86 friendly OS as the base for my project. I think we are good to close this issue.

[markostamcar]

Sorry to post in this closed issue but I'm having the same problems as @ruapotato (sound glitches) when running Linux on latest v86. I'm trying to use the sb16 driver with an old version of Android-x86 (ICS).

I have just discovered something: the sound works much better at https://copy.sh/v86/debug.html and doing another alsa_ctl init command after boot seems to improve it even more. On non-debug version the sound is not recognizable, it's just glitched.

Edit: It does seem to depend on luck. On some cold boots the audio is corrupt, on most it works...