About apu making noise

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
About apu making noise
by on (#40678)
Sorry i come again with this issue, but now i have a dsound interface wich works well (Disch's one) and it seems that the noise comes from the apu (yeah it's not the same terrible noise when i had bad dsound implementation).
I only have square with its ptimer, duty cycle and envelope generator emulated.
I hear the tones, but very bad.
What could it be?

by on (#40679)
Almost anything. I'm skeptical your DSound code is working properly. Can you record the output to a wave file, so one of us can examine it? Here's a simple wave file writer: wave_writer.zip
To use it, just call wave_open( sample_rate, "file.wav" ), then wave_write( buffer, number_of_samples ) (NOT number_of_bytes, mind you) one or more times with your samples (at the same place you play them with DSound), and wave_close() when you're done.

by on (#40680)
yeah, it's a dsound problem. I used a library named "bass" and when i play the sample i get the same error that i get with disch interface. How could it be? If im going to use a lib wich lib do you recommend?
Anyway I will have to take a the wav output.

Thanks for the source file.

by on (#40697)
I post the link to a zip file that contains emu.cpp and emu.h as well disch dsound interface. I have comented neary all lines ant it isn't difficult to understand. The code isn't clean and is not the best, but if someone can help me please i will appreciate it.

http://yanese.freehostia.com/sources.zip

by on (#40702)
It would help if you supplied code we could compile.

But anyway.. my money is on the sound just dropping out. From the looks of this code, you seem to be doing everything one instruction at a time which simply might be too slow for the audio to be generated and streamed in realtime.

I like to make an analogy by comparing audio programming to an hourglass. With an hourglass you pour sand in the top, and it slowly drains out the bottom at a fixed rate. Audio programming is the same -- you put audio (sand) in the buffer (top) and it slowly plays back (drains out) at a fixed rate. If you ever run out of audio, the playback stops -- just like an hourglass stops once it runs out of sand. This stop causes breaks in the sound and makes it sound bad. This is referred to as "buffer underrun". To prevent this from happening, you always need to make sure you have enough audio in the buffer.

What I suspect is happening is that the audio you put in the buffer is draining faster than you can refill it. But that's just a guess -- without being able to compile or hear the broken audio, it's hard to tell.


Also you have the right idea with the linear interpolation -- however you're doing it wrong. The code you have there may be adding to the problem. For now, stick with nearest neighbor (get rid of that block that averages them and just output GetEnvelope() << 8 directly). Worry about one thing at a time -- once you have audio working -- then go back and fix your linear interpolation. Don't bite off too much at once -- makes problems much harder to diagnose and solve.

by on (#40704)
Quote:
What I suspect is happening is that the audio you put in the buffer is draining faster than you can refill it. But that's just a guess -- without being able to compile or hear the broken audio, it's hard to tell.


The emulator code could be slow, but running on a 2.2 ghz processor?

Anyway i made a test. I put your fillbuffer() func after the nes frame completes to fill a 1500 bytes (16 bits) separate buffer, then i lock and copy the buffer to the dsound one with the sine wave sample and the the tone isn't interrupted or messed up.

This thing is getting me crazy.

by on (#40705)
Anes wrote:
then i lock and copy the buffer to the dsound one with the sine wave sample and the the tone isn't interrupted or messed up.


Good! This tells me that the DSound is working. The problem must then be in your emu core. Either that or you're copying to the dsound buffer incorrectly (but I find that much less likely).

Keep in mind -- I haven't seen any of your APU code or even heard the broken sound you're describing, so I'm driving blind here. Unless you give me more info (like the full source so I can try it out myself) it's impossible to diagnose your problem. All I can do is make guesses.