PC speaker passthrough uses frequency tone from previous call

[DoubleHP]

Background: https://www.virtualbox.org/ticket/627 https://www.virtualbox.org/wiki/Changelog

5.0.16 : PC speaker passthrough: new experimental feature, available on Linux host only 5.0.18 : PC speaker passthrough: fixes (Linux hosts only; bug #627)

Activation of feature: https://www.virtualbox.org/changeset/59504/vbox (did not find a real doc; internal search engine gave me this changelog)

Host: Debian Stretch, 4.6.0-1-amd64 VirtualBox 5.0.22 r108108 guest: Debian sarge, 2.6.21-2-486 , progressively upgraded to squeeze (I have Potatoe floppies in my backyard).

Command used: beep.

Beep works perfectly in the host.

In guest, things are more complicated: while true ; do beep -f 220 -l 500 ; sleep 1 ; beep -f 440 -l 1000 ; sleep 1 ; beep -f 880 -l 2000 ; sleep 1 ; done

* THE BUG: Duration of beep is always correct; but frequency tone is used from the previous call.

This is improtant to me, because I perform real time reports of live events via beeps (lag, lost frames) to monitor network, and machine state. Each tone I use has a specific meaning. The configuration is now 11 years old; I can not migrate it, and put it in VB because it can avoid me to migrate it (my old kernel refused to boot on my new motherboard). Still putting prio MINOR, cause it should not cause any arm to other people.

Please add a tick box in the AUDIO tab of the conf pannel.

I am glad we can at last have (read only for obvious reasons) access to the guest conf pannel even when it's running. I have been waiting for this for years.

[Klaus Espenlaub]

First I was very confused, because the usual kernel for Debian squeeze would be 2.6.32 which should be unaffected by an old Linux kernel bug, making it sound like a resurrection of the old linux kernel bug where it first enabled then speaker and then programmed the frequency. This issue was fixed in Linux 2.6.29, and I would really hope no one would ever bring it back. It was bad enough that such a silly bug existed from 1992 (Linux 0.12, the comment hints that the corresponding code was from bsd-net-2) to June 2009.

But then I saw that you're running 2.6.21... would it be an option to upgrade to at least 2.6.29? It really should cure this misbehavior.

The VirtualBox code latches the frequency at the time of enabling the speaker (not allowing changes of the frequency later while the speaker is enabled). Of course it could be done differently, but it would spread the code for handling the speaker over more of the PIT code which I would rather avoid.

[DoubleHP]

Sorry for the late. I have not received notification email about your comment. Not sure if BTS forgot to send it, or if it was filtered as spam.

Upgrading kernel of my guest is not possible. But I could proof check your words by installing a new system in a new virtual machine. Give me 2 weeks.

[DoubleHP]

Same host, guest with 4.6.0-1-amd64, bug does not occur.

I did a quick and dirty fix: /usr/bin/beep: ssh host beep $@