OSDev.org

Hi everyone,
recently, I wrote a simple driver for the more than ancient Sound Blaster 16:
https://github.com/vvaltchev/tilck/tree ... eneric_x86

I knew QEMU supported only the original SB16 (ISA) and that my driver will ever work only on virtual machines,
but that was fine because it's simplest sound card I could think of, and we have some simple and clear documentation
for it: https://wiki.osdev.org/Sound_Blaster_16

But, I hit a nasty QEMU bug:
https://bugs.launchpad.net/qemu/+bug/1873769

QEMU's bug description
Briefly, QEMU's window freezes while audio is playing because GTK's window event loop
and the ISA DMA emulation share the same thread. The good thing is that, I'm not the only
one that hit the issue, as the guy who created the bug shows a video with Windows 95 having
the exact same problem.

Why I'm posting here
I saw posts by people trying to write a driver for this simple sound card, and I believe
it makes sense to warn anyone interested in doing so, before starting. Also, people
affected by this bug can comment and/or click "this bug affects also me" in the bug's page on
launchpad.net.

Workarounds
1. Use an older version of QEMU. With QEMU 2.11 the problem simply does not exist.
2. Use virt-manager which connects to QEMU using Spice. The problem does not
exist in this case because QEMU's GTK UI is not used. BUT, configuring QEMU to emulate
Sound Blaster 16 through virt-manager requires some tricky settings:

• - Add any sound card to the VM
  - In virt-manager's Edit -> Preferences menu check the "Enable XML editing" box.
  - Open VM's hardware and after selecting the sound card, click on the XML tab and replace its contents with:

  Code: Select all

  <sound model="sb16"/>

3. Run the OS using qemu's -curses option or use qemu's -kernel and -nographic (serial console): in this case,
there will be no "freeze", but there still be some flickering in the audio.

Conclusion
QEMU's support for Sound Blaster 16 is broken, but despite that it's still possible to write a driver
for that ancient sound card and it's overall good for educational purposes. At the end, with the virt-manager
workaround I managed to get my driver working and now its possible to play WAV files on Tilck. Just, If I had
to write a new sound driver now, I'd choose:

https://wiki.osdev.org/Ensoniq_AudioPCI

Instead. Also, its worth noting that the Linux kernel has no support for the ISA sb16, maybe that's why
QEMU's sb16 emulation is not tested often.

What do you think about? I hope my experience will be useful to someone.
Vlad

Thank you for report. This is good to know. I think you can write it on wiki.

Anyway, if you want to write another sound driver, I suggest AC97. It is easy to program(I personally think it is easy as Sound Blaster 16) and is supported on old computers too. Unfortunately, actual wiki page is stub. But I am going to write wiki page in next few weeks.

Klakap wrote:Thank you for report. This is good to know. I think you can write it on wiki.

Thanks for the feedback, I will update the wiki

Klakap wrote: Anyway, if you want to write another sound driver, I suggest AC97. It is easy to program(I personally think it is easy as Sound Blaster 16) and is supported on old computers too. Unfortunately, actual wiki page is stub. But I am going to write wiki page in next few weeks.

I was thinking about AC97 but, as you said, we currently have just a stub page and I don't have enough time to start directly from the spec.
Also, being the predecessor of Intel HDA, I expected it to be fairly complex even if simpler than Intel HDA.

I'm so happy to hear that it might be as simple as the Sound Blaster 16 and that you might write a wiki page for it. Thanks a lot for that!!
AC97, even if still outdated, has some real applications on older machines and all the hypervisors support it. It's a huge step forward compared to SB16.

Vlad

Done: https://wiki.osdev.org/Sound_Blaster_16#QEMU_support

Still, HDA works on most new computers, and so it's definitely the best alternative for a driver. At least if it should be usable on real hardware. HDA isn't that complex.

rdos wrote:Still, HDA works on most new computers, and so it's definitely the best alternative for a driver. At least if it should be usable on real hardware. HDA isn't that complex.

Well, yeah. I totally agree: HDA is the best alternative, obviously. I always wanted to write drivers for real hardware that I personally own and that's what I've been doing until now. Also, testing on a real HW is totally a different story that just on a VM. Only in this case, I broke my own rules, because the lack of time. I wanted to have some experience with sound drivers, quickly. SB16 seemed like a joke to me, while HDA seemed a big deal instead. Maybe I'm totally wrong, no idea.

Would you volunteer to explain to me in a few lines something about it, maybe comparing it to sb16? For example, apart from supporting multiple channels, using memory mapped I/O and being discovered as a PCI device, where does reside its main source of complexity? If it's not so much more complex than sb16, than why it does look that way? Maybe it's the amount of configuration parameters? I honestly have no idea.

Thanks,
Vlad

vvaltchev wrote:

rdos wrote:Still, HDA works on most new computers, and so it's definitely the best alternative for a driver. At least if it should be usable on real hardware. HDA isn't that complex.

Well, yeah. I totally agree: HDA is the best alternative, obviously. I always wanted to write drivers for real hardware that I personally own and that's what I've been doing until now. Also, testing on a real HW is totally a different story that just on a VM. Only in this case, I broke my own rules, because the lack of time. I wanted to have some experience with sound drivers, quickly. SB16 seemed like a joke to me, while HDA seemed a big deal instead. Maybe I'm totally wrong, no idea.

Would you volunteer to explain to me in a few lines something about it, maybe comparing it to sb16? For example, apart from supporting multiple channels, using memory mapped I/O and being discovered as a PCI device, where does reside its main source of complexity? If it's not so much more complex than sb16, than why it does look that way? Maybe it's the amount of configuration parameters? I honestly have no idea.

Thanks,
Vlad

The biggest problem is with the Codec, discovering routes and enabling them. Feeding audio data is relatively simple. In fact, the Codec stuff was so complicated that I decided to do it in C (most of my code is in x86 assembly). The problem also is that unless you enable the right routes, you won't get any sound.

rdos wrote:The biggest problem is with the Codec, discovering routes and enabling them. Feeding audio data is relatively simple. In fact, the Codec stuff was so complicated that I decided to do it in C (most of my code is in x86 assembly). The problem also is that unless you enable the right routes, you won't get any sound.

Thanks for sharing this

Yes, HDA is widely supported by sound cards, but it is a lot more complicated than AC97. I am still developing driver for it.I think that AC97 is good middlepoint between SB16 and HDA. Anyway I wrote some info on wiki page AC97

Klakap wrote:Yes, HDA is widely supported by sound cards, but it is a lot more complicated than AC97. I am still developing driver for it.I think that AC97 is good middlepoint between SB16 and HDA. Anyway I wrote some info on wiki page AC97

True. I also have an AC97 driver, but it is only part of relatively old hardware. SB16, though, is just too ancient to bother with, so I have no driver for that. It's a bit like NE2000 network drivers that I suspect emulators still support but that cannot be found in real hardware either.

Klakap wrote:I think that AC97 is good middlepoint between SB16 and HDA.

That's exactly what was my "gut" telling me. SB16 is a joke, with no real applications, but doable in a few days,
as a "demo" emulator-only sound driver to start with. AC97 has a fair amount of real-world complexity.
HDA is the latest and greatest, with all the complexity that comes from that.

Klakap wrote:Anyway I wrote some info on wiki page AC97

Thanks again, Klakap. You did update the wiki page way sooner than expected!

There may be another workaround: use the VNC display instead of the Gtk one. Maybe it wouldn't have the Gtk event loop. It has pros and cons besides this: you'd lose menus, but you wouldn't have to scale the display every single time you lauched it. Or there are other displays, including SDL. I'm pretty sure Gtk+ is the only one with menus, so make a note of the keybindings for serial & other output.

Partial copy of -help output (might be a little out of date):

eekee wrote:There may be another workaround: use the VNC display instead of the Gtk one. Maybe it wouldn't have the Gtk event loop. It has pros and cons besides this: you'd lose menus, but you wouldn't have to scale the display every single time you lauched it. Or there are other displays, including SDL. I'm pretty sure Gtk+ is the only one with menus, so make a note of the keybindings for serial & other output.

Thanks man! I tried the VNC display: it works without any freezing, however the sound still has minor flicker, like in the -curses case. The SDL display instead is not built-in in the QEMU package distributed with Ubuntu, unfortunately; I suppose it's not very widespread. The only display that seems to work flawlessly is Spice (e.g. via virt-manager).

Vlad

vvaltchev wrote:Thanks man! I tried the VNC display: it works without any freezing, however the sound still has minor flicker, like in the -curses case. The SDL display instead is not built-in in the QEMU package distributed with Ubuntu, unfortunately; I suppose it's not very widespread. The only display that seems to work flawlessly is Spice (e.g. via virt-manager).

You're welcome! Glad there's a way. I can understand Ubuntu leaving out the SDL option where others are available; dependencies are annoying.