What are the noise characteristics in terms of harmonics?

Simply by ear it's generating a lot of noise, making the audio playing unhearable (like white noise sounding through the playing sound all the time, when there's sound being rendered(like a random signal generated using c/c++ and being sent to the speakers mixed together with the sound to play by simple addition)).

What harmonics the white noise actually is I don't know. I would need to use some analyzer software to check that (though I don't know any). It sounds like a 100% random signal (like an old television's 'white noise' channel). It can be heard by starting the last version (not the current version, as it has the filter turned off) of x86EMU, entering the BIOS menu, make sure a soundfont is loaded(make sure to save the settings and reboot the application to apply the setting(using the first menu in the BIOS, then simply enter the BIOS settings menu again and start the player)!), go to the Advanced menu, choose the Sound menu(which also contains the soundfont setting), choose the MIDI player(make sure that there's actually a MIDI file present to load in the application folder(as long as it's supported by the emulator, as it somehow won't load all MIDI files(like the Touhou songs from Touhou 6 and up), despite it reading the MIDI file using the standard file layout), Choose your song to play and press X(PSP)/Numpad 2(PC. Make sure you're not in Direct Input mode (mouse is visible), as this won't map to the PSP buttons used by the BIOS menu) to play the song.

I tested with some songs from various games, all songs have this strange behaviour (as well as any other emulated sound hardware) with the high-pass filter enabled. White noise just simply gets 'inserted' by the high-pass filter, instead of just filtering low frequencies out and leaving the sound unchanged(to the ear).

Anyway, it sounds like hard high-pitched white noise (making the sound being played unhearable).

superfury wrote:

I want to prevent the emulator from sending direct current (of any voltage) to the output(SDL). If it does, it might be harmful to the speakers(DC kills the coil), depending on it's duration.

I bet you won't find an audio device that would allow DC on playback waveform to appear at speaker. Sound cards have AC coupled outputs. Amplifiers have AC coupled inputs. Not an issue that breaks loudspeakers, but it does sound like an ugly snap when there is a step waveform (say, emulated soundcard was playing a sample that ended at the positive or negative extreme, and next sample is started at zero voltage).

superfury wrote:

The low pass fiter works. What's going wrong with the high pass filter? (based on http://stackoverflow.com/questions/13882038/i … ss-filters-in-c )

My initial thought are the rounding errors because you convert between integer and float many times per sample, but I could be wrong. It's just that with hi pass filters you need to subtract the accumulated integral (or kind of pass on the original audio signal minus accumulated DC that is gathered by lowpass filtering).

If you can dump the audio output from your emulator to a PCM file, you can use a common sound editor to extract harmonics info.

My suspicion is that this filter technique is creating high frequency ringing as an artifact. This is a known problem for digital filters with abrupt cut-offs. It would be interesting to know if similar artifacts appear when the filter is applied at a higher f0. Does this filter apply to PCM and FM data? If so, perhaps you can drive your output with some sweep patterns to try to isolate the behavior as well.

Last, as Japael said, I'm not convinced of the necessity to perform this step. Amplifiers are almost always capacitively coupled at some point on the signal path. You may wish to perform equalization according to the response model of real hardware, and certainly high and low pass filters are useful to have as library functions, but DC component output is not a big concern in my opinion.

I've changed the filters to use floating point all the way (except for samples to process from the emulated devices and output to SDL(which are signed 16-bit integer numbers)):

1OPTINLINE static float calcSoundHighpassFilter(float cutoff_freq, float samplerate, float currentsample, float previoussample, float previousresult)
2{
3	float RC = 1.0 / (cutoff_freq * 2 * 3.14);
4	float dt = 1.0 / samplerate;
5	float alpha = RC / (RC + dt);
6	return alpha * (previousresult + currentsample - previoussample);
7}
8
9OPTINLINE static float calcSoundLowpassFilter(float cutoff_freq, float samplerate, float currentsample, float previousresult)
10{
11	float RC = (float)1.0f / (cutoff_freq * (float)2 * (float)3.14);
12	float dt = (float)1.0f / samplerate;
13	float alpha = dt / (RC + dt);
14	return previousresult + (alpha*(currentsample - previousresult));
15}
16
17OPTINLINE static void applySoundHighpassFilter(float *currentsample, float *sound_last_result, float *sound_last_sample)
18{
19	#ifdef SOUND_HIGHPASS
20	//We're using a high pass filter!
21	*sound_last_result = calcSoundHighpassFilter(SOUND_HIGHPASS, SW_SAMPLERATE, *currentsample, *sound_last_sample, *sound_last_result); //High pass filter!
22	*sound_last_sample = *currentsample; //The last sample that was processed!
23	*currentsample = *sound_last_result; //Give the new result!
24	return;
25	#endif
26}
27
28OPTINLINE static void applySoundLowpassFilter(float *currentsample, float *sound_last_result, float *sound_last_sample)
29{
30	#ifdef SOUND_LOWPASS
31	//We're using a high pass filter!
32	*sound_last_result = (sword)calcSoundLowpassFilter(SOUND_LOWPASS, SW_SAMPLERATE, *currentsample, *sound_last_result); //Low pass filter!
33	*sound_last_sample = *currentsample; //The last sample that was processed!
34	*currentsample = *sound_last_result; //Give the new result!
35	return;
36	#endif
37}
38
39OPTINLINE static void applySoundFilters(sword *leftsample, sword *rightsample)
40{
41	float sample_l, sample_r;
42
43	//Our information for filtering!
44	static float soundhigh_last_result_l = 0, soundhigh_last_sample_l = 0, soundhigh_last_result_r = 0, soundhigh_last_sample_r = 0; //High pass
45	static float soundlow_last_result_l = 0, soundlow_last_sample_l = 0, soundlow_last_result_r = 0, soundlow_last_sample_r = 0;
46
47	//Load the samples to process!
48	sample_l = (float)*leftsample; //Load the left sample to process!
49	sample_r = (float)*rightsample; //Load the right sample to process!
50
51	//First, as high pass to filter anything too low!
52	applySoundHighpassFilter(&sample_l,&soundhigh_last_result_l,&soundhigh_last_sample_l);
53	applySoundHighpassFilter(&sample_r,&soundhigh_last_result_r,&soundhigh_last_sample_r);
54
55	//Finally, a low pass to filter anything too high (or createn during the high pass filtering)
56	applySoundLowpassFilter(&sample_l,&soundlow_last_result_l,&soundlow_last_sample_l);
57	applySoundLowpassFilter(&sample_r,&soundlow_last_result_r,&soundlow_last_sample_r);
58
59	//Write back the samples we've processed!
60	*leftsample = (sword)sample_l;

61	*rightsample = (sword)sample_r;
62}

The sword being the equivalent of a signed int (16-bits), a int16_t type to be exact.

The noise changed from white noise distorting the sound to a high pitched whistle/tone like sound on the foreground together with the music being played(only when there's high notes in the music being played(lower notes have less or no 'whistle' at all. I think it's starting from the E note about one or two octaves higher than 440Hz)).

Currently recording a .WAV file using the emulator's dumping functionality (the option in the Sound menu to record sound).

I don't have any software to analyze it installed. This is the dump generated by the emulator: http://www.filedropper.com/recording3_2

Again, if you were to run some sweep functions using a pure sine wave, the filter response would be quite a bit more apparent. One issue I did notice was the extreme clipping in this example. That's what causing many of the high order harmonics. Does the clipping appear only after the filter is applied, or with the filter disabled as well?

I don't know that. I do know that the MIDI clips it's samples after applying the volume to prevent overflow(so does the adlib, but it mixes it's own channels and then clips to 16-bit itself, before sending it's output to the sound module. The MIDI handles it's channels seperately, because they have a varying sample rate). Those resulting samples are sent to the rendering buffer in the sound module. The sound module then mixes that channel together with all other hardware and MIDI channels(24 MIDI channels total, 9 Adlib channels, 2 'DAC' channels(Sound Source and Covox Speech Thing) and PC speaker). When all these channels are mixed(by adding the values of each point in time together), the result is clipped to 16-bits if needed, then high pass filtered and low pass filtered. Finally the end result is written to the .wav file if enabled and added to the output buffer provided by SDL.

Thinking about it, the samples of the MIDI can overflow(16-bit samples with volume factor >1.0 overflow with values like 32767 when multiplied and stored in it's 16-bit container.

Edit: Fixed that bug by increasing the container to 32-bits and allowing the clipping to actually clip to 16-bits correctly before sending it into the rendered buffer. I still need to check the results, but you're free to compile it yourself and verify the new outcome. It should compile with MinGW, SDL and SDL_gfx. (Not SDL2!)

Let's be clear on terminology here. You're quantizing and limiting your samples to 16 bit integer, but clipping only occurs when your PCM amplitudes are greater than the representation of the audio. In digital terms, it's when you hit the upper or lower limit of your sample representation. In analog terms, it's when you hit the rail voltage of your amplifier. Clipping is an activity of your waveform. You can generate it as a result of mastering of your audio, but it's not an actual operation you perform. Because of the process of converting to 16 bit, some clipping has been generated on the output.

Having said that, if you could drop your input levels by about 6 to 9 dB, it should cut out a lot of the clipping and allow us to see what's really going on. Ideally, it'd be great to cut the complexity of this playback overall (single notes, pure sine wave samples) to make sure the digital audio processing is generating the results you want. Once that's done, you can layer on additional complexity to make sure it holds together.

I could write a simple TP6/C program that instructs the PIT to generate a frequency and wait infinitely. Although the output will have gaps that way(the PC Speaker buffer is not filling fast enough for maintaining the tone) unless I decrease the CPU speed far below 8086 speed to give it more time to render(getting CPU percentage to 100%).

Or it could simply instruct the MPU-401 to start a note and infinitely delay.

superfury wrote:

Or it could simply instruct the MPU-401 to start a note and infinitely delay.

Yup, with a flute tone. Something monochromatic. Perhaps a midi file consisting of slow scales?

This is a Flute (instrument #74) playing a high tone (tone 0x60) at default volume (0x40):

I must admit it sounds worse within the emulator itself, as it suffers from lag in the rendering function waiting for the main thread (semaphores waiting for access).

I must admit that the song presented earlier does have an incredibly high volume (all those Touhou songs have that for some reason?)

The song earlier was "Angel's legend" from the first Touhou game (http://touhoumidi.altervista.org/highly-respo … to-prayers.html). Don't know if it's allowed to post it here though (are game rips allowed for reference?).

Comparing Windows 10's media player against my emulator, I do notice that Windows 10's media player plays the songs much more softly than my emulator. Is there perhaps an error in my MIDI emulation applying volume?

My current MIDI emulation: https://bitbucket.org/superfury/x86emu/src/43 … ice.c?at=master
My current MIDI ADSR emulation: https://bitbucket.org/superfury/x86emu/src/43 … le-view-default
My current linear to decibel range convertions:

1#define dB2factor(dB, fMaxLevelDB) pow(10, (((dB) - (fMaxLevelDB)) / 20))
2#define factor2dB(factor, fMaxLevelDB) ((fMaxLevelDB) + (20 * log(factor)))

Those linear to decibel range conversions are used in all modules processing sound (including the mixer, which applies volume too (currently at 100% volume=1.0f given to factor2dB with fMaxLevelDB=1)).

We went ten rounds with the dB to linear conversion and the math ended up okay. Not sure if you ultimately decided on 1.0f = 0 dB attenuation or not, but that's a representation issue, not a conversion problem.

I'm seeing both even and odd harmonics of the fundamental at 2097 Hz (expected for a flute tone) with everything else at a -60 dB level. However, I do see some consistency of inter harmonic peaks. I can significantly purify the tone with notch filters. Could you please output the same tone with no filtering and I'll see if any crap is being added. Thanks!

I've made two captures. The first captures the output without the sound module filtering it(high and low pass filters disabled). The second capture also has the MIDI module low pass filter disabled.

Edit: When I open the Soundfont in Viena (from the Synthfont website) and play the tone, the strange effects(lower tones and noise) are not there? Is there something going wrong in the MIDI(and/or Sound module) low pass filter? The MIDI low pass filter is essentially the same as the Sound module low pass filter (The sound module low/high pass filter originally were in the MIDI module only).

Edit: It was using the wrong instrument. It's some instrument called 'Recorder' according to Viena. I'm making some new captures...

Edit: The new 5 filters:
The numbers recorded are the following:
1. No filters (raw sound)
2. MIDI low pass filter only.
3. MIDI low pass filter and Sound low pass filter.
4. MIDI low pass fitler, Sound low pass filter and Sound high pass filter.
5. Only Sound high pass filter.

Currently making the captures. Brb...

Edit: Here are the new captures with the 5 filter settings shown above:

[1]. Nice, sharp peaks on integer harmonics.

[2] No significant change (that's good)

[3] Clean

[4] Clean

[5] Clean

Well, I'm seeing no aliasing, ringing, or any other artifacts here. If you find any particular instruments or note ranges which you feel exhibits the original problem, please record tests [1] and [5] and I'll reply with a comparison of the spectrograms.

Could it be the 'artifacts' I'm hearing isn't caused by the rendering of MIDI sound itself, but rather the music either overflowing(thus clipping) or the rendering not being in time(taking too much time to render, causing very short audio dropouts, which in turn causes the effect?)

This is the recorded result:
http://www.filedropper.com/recordingendresultwithallfilters

It sounds more like vibrating with a high noise when played directly (audio dropouts probably).

Could it be it's causing audio dropouts with the song using many channels (instead of the single channel with the 5 filter dumps), thus affecting output that way? It's simply taking too much time to render, causing lag in the sound, which in turn causes the effect?

I've made a little recording of steps 1 and 5 of the Touhou song (the filtered one being the shorter one): http://www.filedropper.com/recordingfiltersonandoff

The first one is with all filters enabled, the second one is with all filters disabled. Could it actually be a problem with the Soundfont itself? I think it's the Windows(XP?) default Soundfont (as far as I remember, it's either that one, or the Creative default Soundfont). It's 1.04MB in size.

Now I tried recording it with and without filters again. The recording without filters worked, but with the filters enabled again, the emulator hangs about 10-20 seconds in? So it's not just the filters, but something bigger going on that's somehow related to them? Probably something is executing corrupting data or stack?

Without recording it also crashes, but at some point later in the song?

The recording without filters when it still worked: http://www.filedropper.com/recording1

Thinking about it, there was some strange case of data corruption when I was working on integrating the VGA in the main CPU thread that was corrupting it's stack, making it run the Sequencer when it was actually not supposed to run at all. Maybe that's the cause (whatever was causing it, I didn't encounter it again ever since...)?

Edit: I've managed to get it working again, by once again fully recompiling using "make win -rebuild". Here's the captured audio by the emulator:
http://www.filedropper.com/recordingwithoutfi … terswithfilters

1 is the output without any filters (including MIDI filters required by the Soundfont specification).
2 is the output with all filters enabled.

Although this is running at a PC which is more than twice as slow as the first one (Fast one is a Intel i7 4790K@4.0GHz with 8GB RAM used for capturing until yesterday around 20:00 GMT+1, this one is an Intel Pentium processor P6100(2.0 GHz, 3MB L3 cache according to the sticker on the laptop with 4GB RAM).

Edit: The last recordings were only without and with all filters. I've made another one with only the high-pass filter enabled:
http://www.filedropper.com/recording3onlyhighpassfilter

Do you know what's going on here? Is there an error in my High-pass filter?

Of those last three recordings, recording 1 is the [1] case and the last upload is the [3] case.

Of course, you can pull the x86EMU repository from http://bitbucket.org/superfury/x86emu.git and (un)comment the SOUND_HIGHPASS and SOUND_LOWPASS in emu/io/sound.c to enable/disable those filters and add a simple "return;" to the start of the "applyMIDILowpassFilter" funtion to disable the MIDI low-pass filter. Then simply compile and run the application, enter the BIOS menu, make sure the soundfont is loaded(don't forget to save the BIOS to apply changes), start the player, select the song and press Numpad 2 to start playing (you can find a recording option to record the .wav files in the Sound menu as well. Simply click/choose it to start/stop recording).

superfury wrote:

Could it be the 'artifacts' I'm hearing isn't caused by the rendering of MIDI sound itself, but rather the music either overflowing(thus clipping) or the rendering not being in time(taking too much time to render, causing very short audio dropouts, which in turn causes the effect?)

This is the recorded result:
http://www.filedropper.com/recordingendresultwithallfilters

Well, that song is definitely clipping badly. If I were playing that game, I would definitely cut the gain a bit to improve sound quality.

superfury wrote:

It sounds more like vibrating with a high noise when played directly (audio dropouts probably).

Could it be it's causing audio dropouts with the song using many channels (instead of the single channel with the 5 filter dumps), thus affecting output that way? It's simply taking too much time to render, causing lag in the sound, which in turn causes the effect?

If the emulator is not able to feed the audio buffer in real time, sound would definitely suffer. Does the wav file sound worse than direct playback of the emulator? If so, this sounds like a really good theory.

superfury wrote:

I've made a little recording of steps 1 and 5 of the Touhou song (the filtered one being the shorter one): http://www.filedroppe […]
Show full quote

I've made a little recording of steps 1 and 5 of the Touhou song (the filtered one being the shorter one): http://www.filedropper.com/recordingfiltersonandoff

The first one is with all filters enabled, the second one is with all filters disabled. Could it actually be a problem with the Soundfont itself? I think it's the Windows(XP?) default Soundfont (as far as I remember, it's either that one, or the Creative default Soundfont). It's 1.04MB in size.

Now I tried recording it with and without filters again. The recording without filters worked, but with the filters enabled again, the emulator hangs about 10-20 seconds in? So it's not just the filters, but something bigger going on that's somehow related to them? Probably something is executing corrupting data or stack?

Without recording it also crashes, but at some point later in the song?

The recording without filters when it still worked: http://www.filedropper.com/recording1

Thinking about it, there was some strange case of data corruption when I was working on integrating the VGA in the main CPU thread that was corrupting it's stack, making it run the Sequencer when it was actually not supposed to run at all. Maybe that's the cause (whatever was causing it, I didn't encounter it again ever since...)?

Edit: I've managed to get it working again, by once again fully recompiling using "make win -rebuild". Here's the captured audio by the emulator:
http://www.filedropper.com/recordingwithoutfi … terswithfilters

1 is the output without any filters (including MIDI filters required by the Soundfont specification).
2 is the output with all filters enabled.

Although this is running at a PC which is more than twice as slow as the first one (Fast one is a Intel i7 4790K@4.0GHz with 8GB RAM used for capturing until yesterday around 20:00 GMT+1, this one is an Intel Pentium processor P6100(2.0 GHz, 3MB L3 cache according to the sticker on the laptop with 4GB RAM).

Edit: The last recordings were only without and with all filters. I've made another one with only the high-pass filter enabled:
http://www.filedropper.com/recording3onlyhighpassfilter

Do you know what's going on here? Is there an error in my High-pass filter?

Of those last three recordings, recording 1 is the [1] case and the last upload is the [3] case.

Of course, you can pull the x86EMU repository from http://bitbucket.org/superfury/x86emu.git and (un)comment the SOUND_HIGHPASS and SOUND_LOWPASS in emu/io/sound.c to enable/disable those filters and add a simple "return;" to the start of the "applyMIDILowpassFilter" funtion to disable the MIDI low-pass filter. Then simply compile and run the application, enter the BIOS menu, make sure the soundfont is loaded(don't forget to save the BIOS to apply changes), start the player, select the song and press Numpad 2 to start playing (you can find a recording option to record the .wav files in the Sound menu as well. Simply click/choose it to start/stop recording).

I'll have a closer look at the samples in a little bit. I want to test your emulator as well. I want to leave myself enough time that I can tackle any build issues in one go, then I'll see if my system has enough muscle.

The wav files actually sound better(without dropouts) than the sound that's produced when running the emulator. This could be because the other hardware that's rendering constantly fills rendering buffers in the main thread, then pretty much pushes them all in one lock, push, unlock to the renderer. Although the main thread pushes are disabled during this recording from the BIOS settings menu(it effectively disables the CPU part because it's running, thus disabling hardware sound generation in the main thread(not executed), so it shouldn't push anything at all. The audio thread still reads the FIFO buffers one sample at a time(which is locked, read a sample, unlocked) from a during the midi player's playback with(out) recording empty buffer(or last fully filled buffer, then empty onwards, since it isn't refilled until emulation(and audio generation) is started again by closing the BIOS settings menu)).

The midi emulation doesn't suffer from this, as it performs all it's rendering in the audio thread(it doesn't need to be run clocked to the CPU, as with the PC Speaker, Adlib and Sound Source/Covox Speech Thing, which need to be clocked to the CPU to produce accurate samples(PC Speaker PCM, Adlib PCM and Covox PCM need this to properly produce sound accurately)).

I must admit even this 2GHz CPU has trouble keeping up. I already had to implement automatic limiting of the VGA rendering(only rendering as much pixels as it can within CPU execution speed. So if the CPU takes 100ns per instruction to execute, the VGA constantly adjusts it's speed to also only process it's samples in 100ns time, instead of running full blast 28MHz(28M pixels a second), so it will run at 28MHz with a fast enough CPU, but run slower(50% time of the CPU speed) on slower systems that cannot handle it. It does result in the VGA rendering going as slow as 7-10 FPS on a 2GHz machine, but the CPU runs much better(instead of 1% speed with the old full-blown accurate VGA). It's still accurate enough, but just runs slower than 28MHz from the CPU's perspective. This shouldn't be a problem for the CPU, which only depends on checking blanking and retracing periods, which then only last longer. This shouldn't affect software, as it only checks for the register bits going to 1 and to 0(to indicate start and end of the interval)? It simply checks the bit. Then when it goes to 1, it updates stuff. Don't know if it also checks it going to 0 to indicate end of interval, but the software should only run slower doing that. It's not like it will miss the interval(as happened with the VGA being in another thread, thus the CPU missing the intervals, making those DAC tricks impossible to run.

Btw you'll just need about 3 things to compile:
Gcc compiler(Linux or MinGW) or Visual Studio(community) 2015.
SDL installed(google BuildingDosbox for the step to install it)
SDL_gfx(not 2.0!) (Using an adjusted step of BuildingDosbox's SDL_net installation)

Once you've gotten these installed, simply compile x86EMU by cd-ing to it's repository directory(make sure you've copied it's directory structure to ../projects_build/x86EMU) and execute "make win build".

The call is simple: Execute make platform whattodo.

Replace platform with win(windows), psp(when using the pspsdk).
Replace whattodo with the action(s) to execute:
build: Build normally.
rebuild: Short for clean build.

The following is currently only implemented for the Windows target:
debug: Build for debugging and run the debugger(gdb).
redebug: Short for clean debug.
profile: Build for profiling. You need to execute the profiling executable to generate results.
reprofile: Short for clean profile.
profile_use: Process the profiled information dump and generate a profiler.txt file with the results (the GPROF_SWITCHES variable).

The profiler flags currently only have -l used(profile on a line-by-line basis). This can be changed at it's flags at the top of Makefile.win if required. It has it's own line in the makefile.

I've enabled the sound high pass filter again in the latest commit(and fixed Covox bugs).

I currently still disable the low pass filter at the first post: it seems to be messing up the output, making it worse than it is(some hardware becomes very soft sound, like PC speaker and Adlib).