OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 5:46 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: QEMU's (broken) support for Sound Blaster 16
PostPosted: Mon Jan 11, 2021 4:55 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
Hi everyone,
recently, I wrote a simple driver for the more than ancient Sound Blaster 16:
https://github.com/vvaltchev/tilck/tree/master/modules/sb16/generic_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:
    <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

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Tue Jan 12, 2021 10:21 am 
Offline
Member
Member

Joined: Sat Mar 10, 2018 10:16 am
Posts: 296
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.

_________________
https://github.com/VendelinSlezak/BleskOS


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Tue Jan 12, 2021 12:14 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Tue Jan 12, 2021 2:06 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
Done: https://wiki.osdev.org/Sound_Blaster_16#QEMU_support

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Tue Jan 12, 2021 3:20 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Tue Jan 12, 2021 4:56 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Wed Jan 13, 2021 7:09 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Thu Jan 14, 2021 8:27 am 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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 :-)

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Thu Jan 14, 2021 9:24 am 
Offline
Member
Member

Joined: Sat Mar 10, 2018 10:16 am
Posts: 296
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

_________________
https://github.com/VendelinSlezak/BleskOS


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Thu Jan 14, 2021 10:01 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Thu Jan 14, 2021 3:41 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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!

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Sun Jan 17, 2021 4:39 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
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):

Code:
Display options:
-display spice-app[,gl=on|off]
-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
            [,window_close=on|off][,gl=on|core|es|off]
-display gtk[,grab_on_hover=on|off][,gl=on|off]|
-display vnc=<display>[,<optargs>]
-display curses[,charset=<encoding>]
-display none
-display egl-headless[,rendernode=<file>]                select display type
The default display is equivalent to
   "-display gtk"

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Sun Jan 17, 2021 5:01 pm 
Offline
Member
Member

Joined: Fri May 11, 2018 6:51 am
Posts: 274
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

_________________
Tilck, a Tiny Linux-Compatible Kernel: https://github.com/vvaltchev/tilck


Top
 Profile  
 
 Post subject: Re: QEMU's (broken) support for Sound Blaster 16
PostPosted: Sun Jan 17, 2021 7:35 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
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.

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 158 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group