AUDxDAT audio distortion

[Nut]

Hi Toni, I come back to bug you on the audio

So I tested audio on 242beta10 and found out that the same problems remain I was telling you and you fixed some of it already, but the fixes are mysteriously gone, atleast not included on this beta. The issue was that 14bit audio has very strange stepping of 251, 251, 251, 255 (how 8bit audio appears in 16bit signal, those are the amount of steps between the 8bit ladders on the 16bit signal) so these should be 256 ofcourse, 2^8=256. Yes and the 14bit signal has 1,3,1,3 stepping on it, should be 2 ofcourse. You corrected the 1,3,1,3 already, but not the 251 issue. OK, some may say all this don't matter but I'm perfectionist on the Amiga audio. It's hard to describe this stuff, I'm sorry if some of the readers don't understand. The numbers are a sequence of sample steps that repeat over and over again through the 16bit data. It's how the Amiga signal is rendered by the emulator.

But this is NOT the big issue.

So I made test signal programs like I told, took just one day, and I place a link here you can download and test them. Anyone can test who's interested on this. This is a test on 14bit audio and it plays a continuous sinewave. The sinewave is perfect and pure on A500 and A1200. I'm using a sinewave because it's very revealing of errors. There is 4 different tests for non-dma interrupt and copper audio, for both non-lace and interlace modes. All of these work 100% on real Amigas (PAL only). I took care that I wait for stuff properly like long frames on interlace modes. The sources are included. This for me is a very important thing that 14bit audio would work one day. Not necessarily tomorrow, but let's say next year would be nice

http://www.saunalahti.fi/tbsaarni/am...udio_tests.zip

I can already encourage you Toni that one can already hear the sinewave signal in any CPU mode and with JIT also. Great! But there's quite a bit of distortion in the sound. Now I can give you a few hints what could be wrong. I think one thing that might be wrong is that a 14bit signal uses two channels, a 8bit channel and a 6bit channel. For the 14bit signal to be pure, all the channels need to be sample-by-sample in-sync with each other. Otherwise the 8bit/6bit data won't match and there's noise. So this might be one problem. I think there's some other problem too that sounds more like a frame-by-frame crackle on the sound. I have no idea what might cause this but it's something in the emulation, right?

I think I've done my part now and leave it to you. I'd be very grateful if you would concider perfecting the audio one day.

[Toni Wilen]

I forgot

Moved because this is not really beta specific..

I removed the "16-bit hack" because it caused some other problem . Which I don't remember anymore either..

About AUDxDAT distortion, in my scope tests I have noticed that there is no syncronization, Paula analog audio output starts changing immediately after AUDxDAT has been written = it is impossible to have multiple syncronized channels when using manual AUDxDAT audio.

http://eab.abime.net/showthread.php?t=63227

I assume Paula volume system hides the problem or there is some other undocumented feature in Paula..

EDIT: It seems to work fine in cycle-exact modes. This kind of stuff requires accurate timing so I can almost say: "Nothing wrong"

[mc6809e]

Originally Posted by Nut

There is 4 different tests for non-dma interrupt and copper audio, for both non-lace and interlace modes. All of these work 100% on real Amigas (PAL only). I took care that I wait for stuff properly like long frames on interlace modes. The sources are included. This for me is a very important thing that 14bit audio would work one day. Not necessarily tomorrow, but let's say next year would be nice

http://www.saunalahti.fi/tbsaarni/am...udio_tests.zip

Nice work doing copper audio. Have you tried anything fancier to get >14KHz frequencies to output? As great as DMA driven audio is, it did tend to make some samples sound a bit like over-compressed MP3's. Percussive sounds were most affected.

High frequency noise written by the copper to one of the voices should make a nice crisp "crash" sound.

[Toni Wilen]

For some reason I decided to check audio emulation again and noticed one detail, "manual" audio copied AUDxPER to internal counter after current sample has finished, not when sample started. In other words new period value affected only second 8-bit sample of audio word. First sample used previous period.

This probably explains the problem

(I guess no one noticed because manual audio usually always uses static period value..)

[Toni Wilen]

You sure you don't overwrite current copperlist AUDxDAT values while copper is still reading them?

It probably explains non3/non4 distortion in fast cpu modes. CPU accesses to chip ram being slow/DMA contention is only emulated in cycle-exact modes.

[Nut]

Hellos again,

Please don't remove the 16bit hack, but fix the other issue If you keep irregular steps it will cause a slight whining noise to the signal. It's not optimal. Not a big issue but would still be nice to fix this.

I tested 250beta14, thanks for fixing volume level64 ! I wasn't very happy with non-dma though, every mode has noise. You should test WinUAE240, you can get a perfect signal in most of the WinUAE modes (and all 4 tests). Do a trick while playing where you set on/off automatic switching - this will fix the noise for a minute, then it will again appear to the sound. It's very interesting that it starts as a slight crackle then gets continually worse, like some audio-effect. This says to me that the issue can be fixed. It's almost there in version 240 but not perfect.

I understand that AUDxDAT changes the sound immediately and the 4 channels are not exactly in sync. One sample pair plays 160+160 Paula cycles (44.1kHz non-dma interrupt play), where as setting the new audiowords take (8)+8+8+8 Paula cycles. So the 8bit and 6bit signals would be 8 cycles out of sync from each other and left/right channels would be 16 cycles out of sync from each other (one scanline has 454 cycles). This however is not a problem on the Amiga. The result sounds good. In practise the 4 channels are in sync, but what I meant is that bitwise the emulated channels must be in sync as to not have noise in 14bit playback. So maybe the channels drift away from a "virtual sync", it sounds like that on v240, as there is no sync except accidental. Yes it's a difficult problem but surely there's some solution for the emulator we haven't thought yet

When testing you should have interpolation off and filter off from WinUAE settings, because these will mask the noise.



@mc6809e I've tried 88kHz and 176kHz on the Amiga and those work fine ! And they sound really good too. I've played some real music and in my opinion the quality is fine. I even recorded signals back to PC and compared with originals. AGA machines tend to have a noisier signal than A500 but that's something in the analog circuitry, grounding problem likely.



@Toni The audio buffer is written with same data every frame in my tests, the loop does nothing in the test, it's just there in the code for longer sounds I didn't care to remove that part. So there's no buffering problem. Again I say v240 can do perfect copper + interrupt audio in most operating modes, but not continuously, it drifts out of sync and noise appears. The channels can be re-synced by doing the "automatic switching trick".

[Nut]

I like to still point out that in copper audio test3 and test4, you need to manually assemble the sources and uncomment the four lines during the initialization that set periods after AUDxDAT has been written - if you do this copper audio will work on v240 fastest mode. Reason for this behaviour I don't know. Without uncommenting those lines, copper audio will not work on v240 in any mode. Anyway, you can get both interrupt and copper audio to work perfectly on v240 with some of the operating modes (fastest, JIT, adjustable, cycle-exact) but not all of them. On the latest 250beta14 none of the modes really work, but I think accidentally you can get a clean signal once in a while, I've had a few of these surprise moments.

Something funny going on.

[Toni Wilen]

If it works in cycle-exact mode (and possibly aproximate speed mode): everything fine.

Working in any faster mode is only accidental and not a bug, and it never can work in JIT modes without sync issues.

Fastest possibly CPU = CPU emulation is done in bursts, multiple instructions emulated, can be more than 100 depending on PC speed, then chipset is synced with CPU, again more instructions and so on.

It probably worked in older versions because fastest possible mode was not actually fastest possible. It is much faster now.

EDIT: I never recompile or change any tests programs. All test programs must be in confirmed working condition originally!

Copper audio technically should work in all CPU modes.

[dlfrsilver]

i think nut has pointed out the problem many of us have encountered lately.

This is exactly the problem i have, and it happens on some musics and not others.

Toni, i also think that there is maybe an undocumented behaviour of Paula behind this...

Truth is often between both sides

[Toni Wilen]

No you don't have same problem! No program uses non-DMA mode to play music, especially non-DMA 14bit audio!

EDIT: do you notice any difference if you use this: http://www.winuae.net/files/b/winuae.zip

[dlfrsilver]

yes there is a difference when i use this new beta build. The sound/music is WAY less noisy (a bit still in some games, otherwise it's a noticeable change).

What did you modified in it to correct the noisy problem ?

[Toni Wilen]

I found one issue that caused bad copper audxdat audio quality in non-ce modes.

UAE has hack that limits min period to 60 in non-cycle exact modes because there are programs that keep playing very short samples with very small period, causing only high CPU usage.

Hack is now only enabled if channel's DMA is also enabled.

[Nut]

Originally Posted by Toni Wilen

If it works in cycle-exact mode (and possibly aproximate speed mode): everything fine.

It does not always work in any mode. Depends on execution of the tests (random behaviour), WinUAE mode, automatic switching etc. The problems are always the same. Crackle in the audio. Random "white noise" hissing. This can happen in any mode including cycle-exact. So it's not a mode-specific problem, but a fundamental emulation problem. This might even happen in dma-audio but since I don't use it, I don't know. Also I don't know the cause of the problem. I'm only guessing. Might be a sync problem, might be a DAT or PER latch problem, might be sound buffer boundary problem, might be resampling / rendering problem or something else. There's probably multiple issues.

Working in any faster mode is only accidental and not a bug, and it never can work in JIT modes without sync issues.

I don't buy this. Why could it not work? It already does work in v240. I get perfect signal in copper audio tests and fastest mode and those can last forever = 30 minutes I've tested and the signal was still playing perfect. I've done a lot of testing. OK, if you changed how fastest mode works, then maybe it doesn't work anymore, but that's another thing. JIT modes work too just fine on v240. Well, not every single mode work perfect but many do depending what test you use.

EDIT: I never recompile or change any tests programs. All test programs must be in confirmed working condition originally!

That's fine because the tests are working, emulation is not I just pointed out a funny detail that shouldn't matter at all, but it does matter for the emulator. On real Amigas writing PERs after DATs make no difference what so ever. PERs should be written before DATs (logically, in practise makes no difference) and that's exactly what the tests do.

Copper audio technically should work in all CPU modes.

It doesn't. Let's clear the vocabulary : not working = crackle in the sound but you can hear the signal. Working = no crackle.


Here's a funny detail. 250beta25 ... test2 interrupt-audio interlace. Execute this test multiple times. You can hear a perfect signal for half a second. Then the crackle will appear in the sound. I recorded this to disk, and analyzed in Sound Forge. Perfect signal for half a second, then brokes. It's almost like two layers of sound. Perfect sinewave signal in the background, like it should be - and a second layer, a crackling / hissing sound. So the intact signal is there. In every mode you can hear intact sinewave test sound and correct pitch. It's just that the signal breaks and crackle appears.

I already like this 250beta25, as you always hear a signal in any mode and any test. It's just the crackling noise that appears. Interesting thing is that the crackling / hissing is different in every test and about every mode. So you have the signal, but for some reason also crackling. There's nothing in the code that would logically cause this. The code just waits and then pushes new audio words for all 4 channels at once to AUDxDATs. Then waits again until next time. So please, don't doubt that there is a problem in the emulation. I've listened the broken audio for years


Thanks for any fixes you might come up with. I'll be testing them.


Yes, period 60 limit would be a huge problem for non-dma too.

[Nut]

If you fixed something (the link) it didn't make any difference.

Tested again 250beta25... every mode has same buzz problem (fastest, adjustable, JIT, cycle exact) and every test has same problem. It's not a mode-specific problem then. Something is wrong with the emulation.

Can you listen to the tests yourself, Toni? Why wouldn't you? The buzz is loud and clear, you can't miss it.

I changed my code so that PERs get written after DATs, made no difference. Same as when DATs get written after PERs. And it should be the same.

Interesting. v240 was pretty good, some modes were crystal clear, others had variable amounts of buzz.

[Toni Wilen]

Unfortunately I don't hear anything interesting.

Above beta fixed (at least for me), horrible noise in non3 and non4 if non-cycle exact. Now also works in JIT mode.

EDIT: Above beta = winuae.zip, not b25. b26 now have same updates.

non1 and non2 shouldn't work in fastest possible mode, yes, it may have worked previously but fastest possible is meant to be fastest possible (it got faster in 2.4.x or so, many games also broke at that point), accuracy was never guaranteed and this method requires good accuracy. (things go bad for example if burst ends between channel pair's audxdat writes)

Tests to do:

Do you get the noise if you record using built-in wave recording? (must use built-in recording)

If you do, attach short example wave file, thanks. (output panel, click "...", set "save as type:" to "wave sound (*.wav")")

Do you get noise if you disable other channels? (use WinUAE debugger, don't change code because it may change timing, Shift+F12, "Ma x" where x is channel mask, "Ma 1" = first channel only, "Ma 3" first and second only and so on..) In other words, does noise appear only when both "pairs" of 14bit channels are enabled?

[Nut]

I've been thinking. There's atleast two problems that are both mode-independent. First is a buzz. Second is a resampling problem. The buzz is probably something very simple, a logical fallacy in the emulation. The resampling problem is part of the 14bit simulation by using two channels of audio and is a natural phenomenon that occurs do to a delay between updating the AUDxDAT registers for multiple channels. Which entity pushes data to AUDxDAT registers is irrelevant. It could be dma, copper or cpu, or all the three at the same time. So 14bit dma-audio users suffer from this just aswell.


Resampling problem description :

A perfect emulator would create 4 datastreams for 4 channels, 454x313x50 = 7105100 AUDxDAT samples per second per channel. This is the data that flows to the DA converter from AUDxDAT registers. In a way, Amiga always does 7.1 million samples per second audio. The emulator must resample this data to 44100 samples per second stream for PC output. Thus there's about 160.5 AUDxDAT samples per one PC output sample. (This is why 44.1kHz interrupt audio must variate periods between 80 and 81).

Because the AUDxDAT registers can not be written at the same time, there is always a delay between any writes to channels A,B,C or D. The 14bit stream is constructed from two channels AD (left) or BC (right). One is a 8bit stream and the other is a 6bit stream. There is always a small delay of several AUDxDAT cycles between these two streams when data is pushed into the DAT registers. Thus when resampling, if the 8bit and 6bit streams are updated in a "boundary area" between two PC output samples, the 8bit data point can end up in another "sample" than the 6bit data point - a one-sample-out-of-sync condition in the emulated channels. This can happen multiple times per second. This is where the 14bit audio fails and noise appears. This is why we can hear a clean signal and later in time the noise starts appearing in the sound. If we wait the noise will disappear and again we can hear a clean signal. This is the boundary condition in the resampling algorithm.

(The emulator could also function by having only one AUDxDAT stream of 7105100 samples per second by marking which channel A,B,C or D is updated by each entry in the stream. This stream could further be compressed by leaving out every entry that does nothing.)


How to fix it :

What I suggest is only one possible way to fix this. There might be better ways. This one is quite simple. Have a window of say "10 cycles" in the resampling algorithm. If channels A and D both are updated during this time frame, then update both channels at the exact same time. Do the same for channels B and C. Fix the stream of AUDxDAT this way. Then there will be no problem in 14bit audio because the 8bit and 6bit data always end up into the same PC output sample. Problem solved.

We can not assume if channel A goes first or if channel D goes first, or if channel A is 8bit stream or 6bit stream. But we know that both channels will be updated as close as possible in time for each 14bit sample. Also we can not assume if AD and BC are updated at the same time, but this doesn't matter. The fix will still work.

This fix does nothing for 8bit audio, it will sound the same even if applied. We could have an option in WinUAE sound tab called "14bit audio sync" which will activate this fix so people that use 14bit audio can either apply it or not care about it. 8bit users would not suffer either way.


Thank you !

[Nut]

One more message. Here's audio samples of the tests recorded on v240 and v250beta25. This is self explanatory. Listen to these folks.

http://www.saunalahti.fi/tbsaarni/wi...st_samples.zip

The buzz in v250beta25 is caused by wrong number of samples per frame. See for yourself in Sound Forge / Cool Edit Pro or what ever. I even made you a mixed inversion of both signals. The signal should be zero, flat, nothing.

[Toni Wilen]

What do you mean by wrong number of samples?
Did you record it using built-in wave recording? (It bypasses later sound sync stuff)

ADDED:

I am not trying to be annoying, I only need more information because I can't duplicate this (except fastest possible mode non1/non2 distortion which is "normal")
Worst bugs are those that I can't duplicate.

Me and who reports the bug shouldn't assume anything if bug is as annoying as this, narrowing down the problem area is 100% required. (In this case "is the problem in audio emulation/resampler or in host-specific sound sync stuff/driver calls)

Last working version does not help much in this case because sound sync stuff changes all the time (vsync updates).

[Nut]

Toni you are doing a great job. Don't worry

Buzz problem solved. I didn't notice that v250 defaults to 49.92 fps where as v240 defaults to 50 fps. So this was the problem as the audiotests sync to 50 fps. I choose 50fps and not 1 second because this way copperwait positions stay static while doing copper audio. So I manually set 50fps and everything works. Every test works in every mode. This is great. There's still some noise in fastest mode with interrupt audio, but you described it already that it's normal. Copper mode works in fastest, so that's great. Also cycle exact is a little unstable with both copper and int-audio but don't really matter. I can say v250 is the best version for emulating audio so far.

And thanks for fixing the stepping problem and audio periods.


Audio-jitter

I would still like to propose a solution to audio-jitter for constant rate applications like WAV/MP3 players and software mixing routines. The problem is like you know that there's no sync between the AUDxDAT stream and the PC output stream. I suppose the emulator is simply truncating the AUDxDAT stream to the 44100sps PC output stream. So the samples lay where they lay and there's no intelligence where they end up. This causes jitter in the audio even if the application produces 44100sps signal and emulator is set to 44100sps output, because there can be small timing differences. You can hear this effect on one of the samples I recorded (all is recorded inside WinUAE ofcourse). Jitter is when one sample gets played two times in the output stream or one sample is skipped in the output stream, because there's no sync between the signals and they can drift in relation to each other. All audio 8bit and 14bit is subjected to this jitter, it's the nature of the resampling routine. This is also why the 14bit stream can "split" in the output stream.

This fix is only for constant rate audio. Normal variable rate audio like MOD music gains nothing from this. Jitter will always be there for variable rate. So this is for purists and hifists. So let's have an intelligent resampling routine that has a sliding time-window that slides through the AUDxDAT data and picks up the tight groups of audio changes (4 values for 4 channels) and assigns these values to one output sample, then the time-window catches the next group and assigns these values to the next output sample, and so on. This way we can get a jitter-free audio output that perfectly reflects the audio that a real Amiga would output. (Fixing the jitter by interpolation is not a good solution because then the output data wouldn't reflect the real data anymore and the signal will sound different, and you should never interpolate 8bit audio anyway.) So this would be an option on the WinUAE sound tab, call it "intelligent sync" or what you will. I know I'm asking a lot now but I hope you concider doing this. It would be awesome to listen to jitter-free audio on the emulator. Pre-requirements for this would be that the user knows how many samples per second the constant rate audio is and sets the emulator output to the same amount and then clicks the "intelligent sync".

All this may sound a little funny but I promise, people will ask for this one day. I'm being deliberately mysterious here

[Nut]

Here's a way to test the jitter-effect. Set emulator to 49.99 fps and run test non1. Then try 49.999, then 49.9999. You will immediately understand what I mean. This can also happen at 50 fps and it takes 2 minutes for the effect to pass from right to left and disappear. It all depends at what time point you run the test, how much you have to wait for it or if it's instant.

If you have a motherboard sound solution then it may be hard to hear it because these basicly have only one output mode 24bit 96kHz and everything is automatically resampled to this, thus the effect can smooth out by the interpolation process. But I've tried with 3 sound solutions, Asus Xonar Essence, Mackie Onyx Firewire and mobo-audio. It was the same for all and ofcourse it was because you can record it in WinUAE output tab and see it in the sound file. It's very real and very annoying at 50 fps because the buzz takes 2 minutes and all you can do is resync the audio by doing the "automatic switching" trick.

Thanks, bye