Could it perhaps be coil noise, also known as "coil whine"? http://en.wikipedia.org/wiki/Coil_noise
http://www.youtube.com/watch?v=HP73edpQwgc

ElectricMonk wrote:

Um, Putty IS an SSH client, as is SecureCRT, but they still access VTY lines, and are called Terminal Emulators. SCRT is like the leather LaZboy of terminal emulators. It's paid software, but it's worth every cent. Once you use it, you'll never want to go back.

Ah, my bad, I didn't knew.

collector wrote:

Given this, the PortableApp build of DOSBox has a little advantage and is even a bit silly.

Just to make sure I haven't been misunderstood, I'm not using PortableApp version of DosBox.

Jorpho wrote:

I mean, at the time I think there might have been a change committed to the DOSBox source that might conceivably have resulted in DOSBox producing a constant hissing noise. But I'm not sure the change mentioned in that thread was ever actually committed, or even if it would have resulted in any change in the DOSBox audio output.

Hm could be. Anyway, I'll try out an older version and see if it changes anything tomorrow when I'll have some free time.

Qbix wrote:

how about nosound=true ?

Yes:

marooned_on_mars wrote:

• Disabled all sound sources

Dominus wrote:

Regardless whether fullscreen or windowed mode? My old flat screen is making high pitched noises through its speakers when the screen is really bright. But not nearly as loud as you make it sound. Turning down brightness helped in these cases.

Yes, happens on both. And I'm quite sure that this doesn't have anything to do with my monitor, it has no speakers. Also the noise comes from the PC/motherboard, not any peripheral.

mr_bigmouth_502 wrote:

Could it perhaps be coil noise, also known as "coil whine"? http://en.wikipedia.org/wiki/Coil_noise
http://www.youtube.com/watch?v=HP73edpQwgc

Precisely like that, except that the pitch doesn't change no matter what I do, except when I fiddle with the cycles.

Usually I've noticed that coil noise fluctuates depending on the amount of CPU or GPU load. My dad's computer has really bad coil whine when you scroll up or down a web page, for instance. He doesn't notice though since he's not as sensitive to high-pitched sounds as I am. I also had this junk Pentium 4 motherboard I was messing around with once that produced severe coil whine whenever it was under load, and that thing ran like an absolute dog. As soon as it started whining, it started slowing down. 😜

But anyway, since inputting a larger number of cycles would place a larger load on your CPU, it's very much possible that your problem is in fact coil noise.

I don't understand the goose chase after my post either 😖

Okay, I tried version 0.60 on Windows, after failing to compile it on Linux, and it's the same thing as 0.74.
I went even lower to 0.50, and still the same, except for that one I couldn't check the cycles as I couldn't control them.

mr_bigmouth_502 wrote:

But anyway, since inputting a larger number of cycles would place a larger load on your CPU, it's very much possible that your problem is in fact coil noise.

When changing the cycles to over 18000 the sound dampens or lowers in pitch (becoming less bothersome), how do you explain that?
Also this doesn't account for the fact that this noise doesn't occur on any other piece of software other than DosBox?

leileilol wrote:

I don't understand the goose chase after my post either 😖

How exactly is this a goose chase?

The only other thing I can think of is to try to find something else that causes the noise. Have you tried PCem?

Either that, or you could try dismantling the DOSBox source piece by piece, but that sounds arduous.

Record Dosbox output digitally (e.g. "Wave Out" in Windows XP). If the buzz is not present in the recording, the buzz comes from your sound chip.

Jorpho wrote:

The only other thing I can think of is to try to find something else that causes the noise. Have you tried PCem?

Either that, or you could try dismantling the DOSBox source piece by piece, but that sounds arduous.

I can't try PCem at the moment as it refuses to work, I posted on their forums and hopefully I'll get some help. I'll keep this thread updated with the results.

Not just arduous, but futile, as I don't know enough C/C++ to be able to figure out anything in the code 😜

ripa wrote:

Record Dosbox output digitally (e.g. "Wave Out" in Windows XP). If the buzz is not present in the recording, the buzz comes from your sound chip.

Did that both under Linux and Windows, and both don't produce that "buzz" in the recording as it does in DosBox, but the recording does have some "garbage" that sits at around -48dB, but that doesn't output any sound when played back. I'll attach the recording when I'll get to my PC.
By sound chip you mean DAC? Regardless, would there be any solution to that? (I'd expect only a hardware modification could fix it)

I'd say it's pretty obvious that it's a hardware problem that dosbox somehow triggers, since it happens on both linux and Windows, and no one else reported it yet..,

It happens in both Linux and Windows, but not in the exact same way (ie. the screech isn't that loud/bothersome under Windows) which is weird.

You don't happen to have a microphone attached snd always on? 😉

Seriously at that point I'd gut my machine, detach any cable that is not necessary for bare bone running and then throw out any pci card as well to see whether anything helps...

marooned_on_mars wrote:

By sound chip you mean DAC? Regardless, would there be any solution to that? (I'd expect only a hardware modification could fix it)

I meant whatever sound hardware you have, e.g., integrated, discrete or external.

Here's what I think might be happening. Dosbox emulation happens in 1 millisecond chunks. The real, wall-clock time it takes to emulate 1 ms depends mostly on the cycles setting and the emulated program. When Dosbox is ahead of wall-clock time, Dosbox sleeps for 1 ms using SDL_Delay (unless the "unlock" button is pressed) to keep the emulation real-time.

Unless there is anything else for the operating system to schedule for execution, SDL_Delay puts the processor into a low-power idle state for a while. Depending on the CPU load, Dosbox is causing the power draw to fluctuate at up to ~1 kHz, which could be audible as a buzz depending on the quality of the sound hardware and the power supply.

You could try:
- disabling the CPU power saving functions (OS power settings or BIOS)
- a different power supply
- a discrete or external sound card
- replacing SDL_Delay with some busy-wait

Dominus wrote:

You don't happen to have a microphone attached snd always on? 😉

Seriously at that point I'd gut my machine, detach any cable that is not necessary for bare bone running and then throw out any pci card as well to see whether anything helps...

I'm already running bare-bones 😜
And no, I have muted Line-In, Mic (I use an USB one anyway) and CD, even Headphones and PCM (Linux) and I still hear the screeches.

ripa wrote:

- disabling the CPU power saving functions (OS power settings or BIOS)

No such function under BIOS, so I'll assume there isn't a software-based one either. Also keep in mind I'm not using an laptop.

ripa wrote:

- a discrete or external sound card

By "discrete" you mean "dedicated"?

ripa wrote:

- replacing SDL_Delay with some busy-wait

Do modifications to the source code? In that case could you specify what I need to modify exactly?

marooned_on_mars wrote:

No such function under BIOS, so I'll assume there isn't a software-based one either. Also keep in mind I'm not using an laptop.

Control Panel --> Power Options or equivalent. Most PC CPU since the 90s has different power states controlled by the operating system.

marooned_on_mars wrote:

By "discrete" you mean "dedicated"?

Same thing.

marooned_on_mars wrote:

Do modifications to the source code? In that case could you specify what I need to modify exactly?

include/busywait.h:

1#ifndef BUSY_WAIT_H_
2#define BUSY_WAIT_H_
3
4#include <SDL.h>
5
6static void busyWait(const Uint32 delayMilliSec)
7{
8    const Uint32 startMilliSec = SDL_GetTicks();
9    while ( (SDL_GetTicks() - startMilliSec) < delayMilliSec );
10}
11
12#endif

Then replace all calls to SDL_Delay(x) with busyWait(x) and #include "busywait.h" in every file in which you use it.

ripa wrote:

Control Panel --> Power Options or equivalent. Most PC CPU since the 90s has different power states controlled by the operating system.

I'll try that next time I boot under Windows, any suggestions on what to check under Linux?

ripa wrote:

include/busywait.h: […]
Show full quote

include/busywait.h:

Copy code to clipboard

1#ifndef BUSY_WAIT_H_
2#define BUSY_WAIT_H_
3
4#include <SDL.h>
5
6void busyWait(const Uint32 delayMilliSec)
7{
8    const Uint32 startMilliSec = SDL_GetTicks();
9    while ( (SDL_GetTicks() - startMilliSec) < delayMilliSec );
10}
11
12#endif

Then replace all calls to SDL_Delay(x) with busyWait(x) and #include "busywait.h" in every file in which you use it.

Okay, so I did that, but when I compile next time I get this:

1make[3]: Entering directory '/home/andoru/sources/dosbox/src'
2g++ -DHAVE_CONFIG_H -I. -I..  -I../include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  -g -O2 -mno-ms-bitfields  -MT dosbox.o -MD -MP -MF .deps/dosbox.Tpo -c -o dosbox.o dosbox.cpp
3mv -f .deps/dosbox.Tpo .deps/dosbox.Po
4g++  -g -O2 -mno-ms-bitfields    -o dosbox dosbox.o  cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a  hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -lSDL_sound -lasound -lm -ldl -lpthread -L/usr/lib/i386-linux-gnu -lSDL -lpng -lz -lSDL_net -lX11 -lGL -lmt32emu
5gui/libgui.a(sdlmain.o): In function `busyWait(unsigned int)':
6/home/andoru/sources/dosbox/src/gui/../../include/busywait.h:7: multiple definition of `busyWait(unsigned int)'
7dosbox.o:/home/andoru/sources/dosbox/src/../include/busywait.h:7: first defined here
8gui/libgui.a(sdl_mapper.o): In function `busyWait(unsigned int)':
9/home/andoru/sources/dosbox/src/gui/../../include/busywait.h:7: multiple definition of `busyWait(unsigned int)'
10dosbox.o:/home/andoru/sources/dosbox/src/../include/busywait.h:7: first defined here
11gui/libgui.a(midi.o): In function `busyWait(unsigned int)':
12/home/andoru/sources/dosbox/src/gui/../../include/busywait.h:7: multiple definition of `busyWait(unsigned int)'
13dosbox.o:/home/andoru/sources/dosbox/src/../include/busywait.h:7: first defined here
14collect2: error: ld returned 1 exit status
15Makefile:394: recipe for target 'dosbox' failed
16make[3]: *** [dosbox] Error 1
17make[3]: Leaving directory '/home/andoru/sources/dosbox/src'
18Makefile:426: recipe for target 'all-recursive' failed
19make[2]: *** [all-recursive] Error 1
20make[2]: Leaving directory '/home/andoru/sources/dosbox/src'
21Makefile:367: recipe for target 'all-recursive' failed
22make[1]: *** [all-recursive] Error 1
23make[1]: Leaving directory '/home/andoru/sources/dosbox'
24Makefile:307: recipe for target 'all' failed
25make: *** [all] Error 2

I made sure that the modifications I made were correct and that I haven't forgotten to place the include strings in their appropriate place.

I forgot "static" from the definition. See the updated code.

As for CPU power management under Linux ... I don't know what else to recommend except Google (maybe site:superuser.com).

Thanks a bunch! Luckly that fixed the problem, no more screechings! However the CPU is on 100% all the time 😒

Holy crap I didn't expect it to actually work :B

Any fix for the problem? 😜
Perhaps in some way cap the unused CPU cycles.

It's a hardware problem. If Dosbox doesn't waste the CPU cycles, OS puts CPU into power saving mode which makes sound card screech. Either you replace the sound card, motherboard, or power supply.