SB16 audio playback freezes emulation in Windows 95 guest

[Marko Štamcar]

- QEMU 4.2.93 (v5.0.0-rc3) built from latest git master 20038cd7a8412feeb49c01f6ede89e36c8995472 using MSYS2 on Windows 10 and launched on same Windows 10

- Launched using "qemu-system-i386.exe -drive format=raw,file=hdd-2gb.img -soundhw pcspk,sb16 -m 16 -cpu pentium -vga std -cdrom Windows_95.iso -boot c"

- I have attached video screen capture of the issue

---

I decided to make my first ever QEMU build after encountering the dsound issues using the latest 4.2.0 binary from https://qemu.weilnetz.de/w64/. In my 5.0.0-rc3 build the sound playback is working correctly, however the whole Windows 95 UI freezes while sound is playing.

[Allan Peramaki (aperamak)]

This is with GTK UI? Do you still have the same problem if you use Spice and remote-viewer instead?

(GTK UI and Sound Blaster 16 emulation don't play well together. GTK UI does screen updates only when the main event loop becomes idle, but it never becomes idle when SB16 audio is playing due to the way hw/dma/i8257 works. The combination of GTK UI screen updates + SB16 DMA transfer additionally causes i8257_dma_run() getting called at a very rapid rate.)

[Vladislav K. Valtchev (vvaltchev)]

Hi Allan,
I've hit EXACTLY the same problem, while writing a SB16 driver.

Reproducing the bug
----------------------
I've tried to QEMU 4 in several scenarios (GTK UI, text mode with the -curses option,
just serial console with -nographic and with virt-manager which uses Spice). It works
as expected in all the cases EXCEPT for the GTK UI: in that case, the video freezes
while playing the sound, exactly as in the video posted by Marko; even QEMU's menu
doesn't respond while the audio is playing (the bug affects the whole QEMU UI).

Regression
---------------------
I've also tried the same test with QEMU 2.11, on another machine with Ubuntu 18.04 (LTS)
and there the problem simply does *not* exist. QEMU's UI (does QEMU 2.x uses GTK?),
works GREAT while playing SB16 audio.

Conclusion
----------------
Is there any chance this bug could be fixed easily, or a fix would necessarily require
a (partial) re-design of the way the GTK UI works? In particular, why on QEMU 2.11 the
problem does not exist?

Thanks in advance,
Vlad

[Vladislav K. Valtchev (vvaltchev)]

P.S.: sorry for the terribly broken lines. I didn't expect launchpad to add additional line breaks that way :-(

[Thomas Huth (th-huth)]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

    https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]

[Thomas Huth (th-huth)]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/469