Any updates on this? I realized that if we will be working towards implementing Beep, this MR won't even be necessary lol(after implementing Beep, it would be one line change in conhost to implement the \a code for write_console) On Fri, Jul 24, 2026 at 4:38 PM Barath Rk <barathrk11@gmail.com> wrote:
https://gitlab.winehq.org/wine/wine/-/merge_requests/11469
I have created an MR for this issue. This produces a simple double beep as the bell.
I haven't added any tests as I was unsure about them.
On Fri, Jul 24, 2026 at 1:08 PM Barath Rk <barathrk11@gmail.com> wrote:
from an architecture point of view, kernel(base|32) is at a "layer" below winmm (and any other sound related DLLs)
Hm right
yes to decide if we reuse and existing service or add a new one yeah fair enough. I think I'll just generate my own beep effect using winmm for this fix though. simplest option currently
On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <eric.pouech@orange.fr> wrote:
Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit :
Could you explain what you mean by it being a layering issue? the waveOut* functions of winmm essentially call the respective audio drivers. By "service" do you mean pulse/ALSA?
from an architecture point of view, kernel(base|32) is at a "layer" below winmm (and any other sound related DLLs)
so winmm is allowed to call into kernel(base[32), but not the other way around
Zeb suggests we have a service responding to a beep ctl command (and that service could call into winmm)
yes to decide if we reuse and existing service or add a new one