14.57731 bit audio

[nikosidis]

Originally Posted by orangespider

Ah, I thought you did a cycle exact emulation of it. Well then I guess I'll have to measure on a real Amiga. Also it means whatever I do won't sound well in WinUAE later on. Guess I will have to torture nikosidis or if you can make more precise measurements it would be even better.

In a perfect scenario we should measure audxper at 128/256/512 and 1024 to see if the phase shift changes at all depending on audxper (it does in WinUAE). I have a repeating pattern beep that is perfect for this. If you're up for it, I can send you the 4 test case .exe files.

I'm inn
I like to be tortured

[orangespider]

Another oddity I can't explain is the audxper limits. Ross gave an equation that works to predict it, but it doesn't make any sense. According to Hardware Manual:
http://amiga.nvg.org/amiga/reference.../node00F2.html

The DMA can refill once per scanline. That would actually make the AUDxPER limit be frequency/number_of_scanlines_per_second/2 (because it fetches 2 values at once).

Once you calculate it the AUDxPER limit would become 114 for PAL and 62 for Productivity. This isn't the case. If the DMA is doing one access per scanline, that means that somehow it loses 26 scanlines in PAL and 70 scanlines in Productivity. If this is the case, then which are those scanlines and why?

Or is the Hardware Manual completely wrong and the DMA doesn't fetch during the scanlines at all? I am really confused about this.

[ross]

Originally Posted by orangespider

Another oddity I can't explain is the audxper limits. Ross gave an equation that works to predict it, but it doesn't make any sense. According to Hardware Manual:
http://amiga.nvg.org/amiga/reference.../node00F2.html

The DMA can refill once per scanline. That would actually make the AUDxPER limit be frequency/number_of_scanlines_per_second/2 (because it fetches 2 values at once).

Once you calculate it the AUDxPER limit would become 114 for PAL and 62 for Productivity. This isn't the case. If the DMA is doing one access per scanline, that means that somehow it loses 26 scanlines in PAL and 70 scanlines in Productivity. If this is the case, then which are those scanlines and why?

Or is the Hardware Manual completely wrong and the DMA doesn't fetch during the scanlines at all? I am really confused about this.

It makes sense if you re-read the first sentence of message #169.
Agnus, who fetches the data from memory, is separated from Paula, who manages it.
The line with which Paula signals that wants new data (DMAL, DMA request Line) uses a serial protocol that starts at the beginning of the video line (HPOS=1), a bit at a time, floppy channels comprised.
So for the 'far' channels it takes longer to transmit if new DMA data are required and you have a delay compared to the maximum theoretical obtainable frequency.
The formula takes into account this fixed delay with respect to the length of the line.

[orangespider]

Originally Posted by ross

It makes sense if you re-read the first sentence of message #169.
Agnus, who fetches the data from memory, is separated from Paula, who manages it.
The line with which Paula signals that wants new data (DMAL, DMA request Line) uses a serial protocol that starts at the beginning of the video line (HPOS=1), a bit at a time, floppy channels comprised.
So for the 'far' channels it takes longer to transmit if new DMA data are required and you have a delay compared to the maximum theoretical obtainable frequency.
The formula takes into account this fixed delay with respect to the length of the line.

Re read post #169 and am trying to make sense of it. Does that mean that it isn't in fact tied to scanlines but instead has a HTOTAL based delay on top of the cycles it takes for it to communicate? Meaning it has to have 227 free cycles between sending another batch of requests after a request is done?

If I am getting this wrong, please correct me.

[ross]

Originally Posted by orangespider

Re read post #169 and am trying to make sense of it. Does that mean that it isn't in fact tied to scanlines but instead has a HTOTAL based delay on top of the cycles it takes for it to communicate? Meaning it has to have 227 free cycles between sending another batch of requests after a request is done?

If I am getting this wrong, please correct me.

In fact it isn't tied to scanlines number in any way, but instead on HPOS=1 trigger, that is of course HTOTAL(+1) based for frequency.
At start of scanline begin a 'communication' between Agnus and Paula if there is needed new data through DMA.
But what if the communication that the channel requires new data occurs after the fetch can physically be performed? The old data is used by Paula..
The delay is not constant due to the aforementioned serial protocol and therefore also the maximum frequency for each channel is not constant.
I don't know how to make it clearer, but feel free to ask if it's not yet

[orangespider]

It's not clear.

When does Paula actually request the new DMA read? When it starts playing the second sample or when the second sample is done?


edit: I think I finally got it. It requests it as soon as it starts playing sample 0. The reason we need the 19 extra cycles is because if it requests at HPOS = 2, the new data must be there before HPOS=20 of the new scanline, when it needs to play the new sample pair. It will go in/out of sync but if we give it the extra 19 cycles it will never actually fail. This is why we can't resync the channels, no matter what we do, the new data will always come at HPOS=20 of the next scanline and in the c0/c1/c2/c3 order. We could sync it at near 50% phase shift if the audxper is exactly the same as the HTOTAL+1 because then channels0/1 would get a sample every even and channels2/3 would get a sample every odd scanline, but for other AUDxPER values, syncing is out of question.

edit2: This means I finally know why my productivity version is so noisy as well. I used period 72, but the actual limit is 72.5 -- so 73 in effect. It was missing samples on channel 3.

[orangespider]

Well, for anyone who cares the measurements are done. It is clear now that the noise issue I was having is coming from the fact that the phase shift isn't static as I've thought, instead it is changing depending on the AUDxPER value. I couldn't figure out how exactly it changes (yet), but working on it. The audio volume measurements are kind of inconclusive, some measurements indicate that the audio volume does get reset after the 2 samples have been played while the others don't. The issue here is probably the +-3% tolerance, which makes it way less conclusive.

Here are the results for channel 0/3 (the expected columns are what I thought should be happening, the channel 1/2 data is not yet done, will post that one too when I finish the analysis):

edit: measurements deleted, got a better set of data - stay tuned

[ross]

Originally Posted by orangespider

It's not clear.

When does Paula actually request the new DMA read? When it starts playing the second sample or when the second sample is done?


edit: I think I finally got it. It requests it as soon as it starts playing sample 0. The reason we need the 19 extra cycles is because if it requests at HPOS = 2, the new data must be there before HPOS=20 of the new scanline, when it needs to play the new sample pair. It will go in/out of sync but if we give it the extra 19 cycles it will never actually fail. This is why we can't resync the channels, no matter what we do, the new data will always come at HPOS=20 of the next scanline and in the c0/c1/c2/c3 order. We could sync it at near 50% phase shift if the audxper is exactly the same as the HTOTAL+1 because then channels0/1 would get a sample every even and channels2/3 would get a sample every odd scanline, but for other AUDxPER values, syncing is out of question.

edit2: This means I finally know why my productivity version is so noisy as well. I used period 72, but the actual limit is 72.5 -- so 73 in effect. It was missing samples on channel 3.

Make it simpler, see Audio State Machine: AUDxDR and AUDxDSR are latched at HPOS=1, 'inserted' in the shift register and then transmitted serially on the DMAL line to Agnus.
This dmal 'shift register' is constructed like:

for (int channel = 0; channel < 4; channel++) {
	if (AUDxDR) dmal |= 1 << (channel * 2);
	if (AUDxDSR) dmal |= 1 << (channel * 2 + 1);
}
dmal <<= 6;
dmal |= disk_dmal; //14 bits total

line:
-1 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
RR xx RR xx RR xx RR xx F0 xx F1 xx F2 xx C0 xx C1 xx C2 xx C3 xx
------|-----------------D0-D1-D2-D3-D4-D5-D6-D7-D8-D9-Da-Db-Dc-Dd
  dmal start delay

RR=refresh slot
Fx=floppy fetches
Cx=audio fetches
Dx=dmal bits
[there may be differences regarding the start of the signals
 due to delays on the bus or unknown details, but the concept is this]

So you have to deal to a synchronized counter (AUDxPER) and a different sync one (HPOS and relative DMAL cumulative delay).
That's why you sync at alternating lines, but it's just a side effect of the request made at the time of the latch.

[orangespider]

edit: more precise measurements:

channel 0/3:
AUDxPER = 1024
volume = 48
expected = 0.75
measured = 0.750643239632036
volume = 32
expected = 0.5
measured = 0.500026678875093
volume = 16
expected = 0.25
measured = 0.248842063220488
Phase shift:
expected = 0.01171875
measured = 0.091934192553536
cycles = 94.1406131748209


AUDxPER = 512
volume = 48
expected = 0.75
measured = 0.753444150585907
volume = 32
expected = 0.5
measured = 0.503062535963278
volume = 16
expected = 0.25
measured = 0.250810991191725
Phase shift:
expected = 0.0234375
measured = 0.0994732127376043
cycles = 50.9302849216534


AUDxPER = 256
volume = 48
expected = 0.75
measured = 0.762072790918855
volume = 32
expected = 0.5
measured = 0.513136489890822
volume = 16
expected = 0.25
measured = 0.257104413528066
Phase shift:
expected = 0.046875
measured = 0.117910048957869
cycles = 30.1849725332145


AUDxPER = 161
volume = 48
expected = 0.751552795031056
measured = 0.750627749643138
volume = 32
expected = 0.503105590062112
measured = 0.504574873426377
volume = 16
expected = 0.254658385093168
measured = 0.255610611220159
Phase shift:
expected = 0.0745341614906832
measured = 0.144409202297481
cycles = 23.2498815698945


AUDxPER = 128
volume = 48
expected = 0.75
measured = 0.783793822770762
volume = 32
expected = 0.5
measured = 0.538053063338414
volume = 16
expected = 0.25
measured = 0.272856768733526
Phase shift:
expected = 0.09375
measured = 0.169859378147562
cycles = 21.742000402888


AUDxPER = 124
volume = 48
expected = 0.774193548387097
measured = 0.753444424186417
volume = 32
expected = 0.516129032258065
measured = 0.511258270047225
volume = 16
expected = 0.258064516129032
measured = 0.262943207392207
Phase shift:
expected = 0.0967741935483871
measured = 0.173993469008998
cycles = 21.5751901571157


AUDxPER = 80
volume = 48
expected = 0.8
measured = 0.764299210521312
volume = 32
expected = 0.6
measured = 0.546336916757656
volume = 16
expected = 0.3
measured = 0.304600735812456
Phase shift:
expected = 0.15
measured = 0.249001012724879
cycles = 19.9200810179903


channel 1/2:
AUDxPER = 1024
volume = 48
expected = 0.75
measured = 0.750589654733054
volume = 32
expected = 0.5
measured = 0.499991037614782
volume = 16
expected = 0.25
measured = 0.248804051534788
Phase shift:
expected = 0.01171875
measured = 0.0257918886746533
cycles = 26.410894002845


AUDxPER = 512
volume = 48
expected = 0.75
measured = 0.753312026904749
volume = 32
expected = 0.5
measured = 0.502964171881404
volume = 16
expected = 0.25
measured = 0.250683847457676
Phase shift:
expected = 0.0234375
measured = 0.0282822154436125
cycles = 14.4804943071296


AUDxPER = 256
volume = 48
expected = 0.75
measured = 0.762005119156824
volume = 32
expected = 0.5
measured = 0.512980201937168
volume = 16
expected = 0.25
measured = 0.25701023260804
Phase shift:
expected = 0.046875
measured = 0.0343099479775933
cycles = 8.78334668226389


AUDxPER = 161
volume = 48
expected = 0.751552795031056
measured = 0.752264394856939
volume = 32
expected = 0.503105590062112
measured = 0.505818618229815
volume = 16
expected = 0.254658385093168
measured = 0.256297276132646
Phase shift:
expected = 0.0745341614906832
measured = 0.0433753708125403
cycles = 6.98343470081899


AUDxPER = 128
volume = 48
expected = 0.75
measured = 0.783896156980897
volume = 32
expected = 0.5
measured = 0.538126479702122
volume = 16
expected = 0.25
measured = 0.2729295048051
Phase shift:
expected = 0.09375
measured = 0.0514400181962014
cycles = 6.58432232911377


AUDxPER = 124
volume = 48
expected = 0.774193548387097
measured = 0.753745801272701
volume = 32
expected = 0.516129032258065
measured = 0.511471793075795
volume = 16
expected = 0.258064516129032
measured = 0.263094212957233
Phase shift:
expected = 0.0967741935483871
measured = 0.0528149593375087
cycles = 6.54905495785108


AUDxPER = 80
volume = 48
expected = 0.8
measured = 0.765168679545257
volume = 32
expected = 0.6
measured = 0.546748468532973
volume = 16
expected = 0.3
measured = 0.304886422763829
Phase shift:
expected = 0.15
measured = 0.0769019813554684
cycles = 6.15215850843747

[orangespider]

Just to add: The measurements above were taken in Productivity resolution. I have just finished analyzing the measurements for 124-1024 in PAL, and there is no difference in any of the stats (in the first 4 decimals that is). So the phase shift seems to depend on AUDxPER only.

The easiest approximation that gives relatively good results to calculate delay in cycles based on AUDxPER is:
left delay = 12 + AUDxPER * 0.08
right_delay = 4 + AUDxPER * 0.02

[Gorf]

Originally Posted by orangespider

Just to add: The measurements above were taken in Productivity resolution. I have just finished analyzing the measurements for 124-1024 in PAL, and there is no difference in any of the stats (in the first 4 decimals that is). So the phase shift seems to depend on AUDxPER only.

The easiest approximation that gives relatively good results to calculate delay in cycles based on AUDxPER is:
left delay = 12 + AUDxPER * 0.08
right_delay = 4 + AUDxPER * 0.02

Is that on real hardware?

mysterious

[orangespider]

Originally Posted by Gorf

Is that on real hardware?

mysterious

Yeah, that was measured on the real hardware. The volume level seems to be consistent of using the counter and then reseting at audxper x2. Which is why 16 volume at audxper 80 doesn't reduce the volume to 0.25 -- as one might expect, but to 0.3... The volume values are actually only correct for audxper values that are dividable by 64. For the rest you have to count how many ticks they will have, and you won't always have the same volume for both samples in the pair. For volume 16 at audxper 80 you have this:
cylce 0: volume counter resets
cycle 16: volume counter reaches 16, so it stops playing
cycle 64: volume counter is 0 again, so we play sample 1 again
cycle 80: volume counter reaches 16, so it stops playing, but we do switch to sample 2
cycle 128: volume counter is 0 again, so we play sample 2
cycle 144: volume counter reaches 16, so it stops playing
cycle 160: we start playing the next sample pair, so everything goes back to cycle 0

This means we played:
sample 1 - 32 cycles out of 80 (40% volume)
sample 2 - 16 cycles out of 80 (20% volume)

The average volume is 30% (instead of 25%), but every even sample will be twice as loud as the odd ones. This all seems to be in line to what HRM says.

The phase shift values make absolutely no sense on the other hand.

[Thorham]

Damn, this sure turned out to be more complicated than I expected!

[robinsonb5]

Originally Posted by Thorham

Damn, this sure turned out to be more complicated than I expected!

Learning new things about the Amiga's audio though. I'd assumed the volume counters were free-running - what orangespider's learned here is enough to explain why Thomas measured more noise than expected in the traditional "14-bit" mode.

[orangespider]

I need your help.

I've tested the conversion with the measured phase shift values, but there was only a slight improvement, most likely because at such low volume levels the noise is too high and the data I get is useless.

So I made a series of fine-tune executables to try and manually find the phase shift for left/right channels at different AUDxPER levels.

nikosidis has already reported the numbers for AUDxPER values 80 and 124, but the more people we have the less subjective errors will be in the final result.

I have included executables for the following AUDxPER values:
73 - highest you can go with standard Productivity resolution
80 - closest to 44100
124 - highest you can go with PAL
128 - cleanest you can go with PAL if you want to use Volume
161 - closest to 22050

The process is simple:
step 1) start the .exe file you want to fine tune
step 2) press left mouse button to decrease and right mouse button to increase the assumed phaseshift by 1
step 3) press both buttons at the same time to increase tuning precision
step 4) press left mouse button to decrease and right mouse button to increase the assumed phaseshift by 0.1
step 5) press both buttons at the same time to increase tuning precision
step 6) press left mouse button to decrease and right mouse button to increase the assumed phaseshift by 0.01
step 7) press both buttons at the same time to leave

Try to find the values where the noise level is the lowest. Once you get the values, write them down somewhere and send it to me in private messages. I don't want the values to be in the thread because I don't want people to get influenced by the values other people have measured to get more precise end results.

You can run the programs in Productivity or PAL, but if you are running in PAL don't go below 124 AUDxPER, just test the 3 largest ones.

Here are the .exe files.
http://s000.tinyupload.com/index.php...97285814691162


What I am trying to do here is to reduce the playback noise as much as possible. The theory is simple. Amiga playback has 4 sources of noise.
1) DAC/amplifier noise
2) Volume implementation noise
3) Bitrate conversion noise
4) Phase shift noise

I am trying to minimize each in the following way:
1) DAC/amplifier noise
This is unavoidable, but the louder we play the audio the less percentage of it will be this noise. Therefore we should go with 64/64 volumes to minimize this noise
2) Volume implementation noise
We can simply use 64/64 volume and completely avoid this.
3) and 4) we will look at together
Since we are using 64/64 volumes, the effective bitrate is 9 bits per channel. However, there are multiple ways to get to the same 9 bit values:
2+3 = 5
1+4 = 5
3+2 = 5
4+1 = 5
etc.

Each number combination will produce the exact same 9 bit value, but will produce a different phase shift noise. If we know the exact amount of the phase shift, we can force it to produce a noise equal and opposite to the 9 bit conversion noise and those 2 can then negate each other and we have a clean sounding output.


edit: This is what we have with the current assumed phase shift values:
https://files.fm/u/sgzcbz6jz#/view/medazgbs5
Left channel is crystal clear, but right seems to have issues still.

[orangespider]

On a related note: Here is my take at an uncalibrated "14-bit" version at 44336 Hz (Productivity):
http://s000.tinyupload.com/index.php...17287308820719

The difference between this and the traditional 14bit is that it assumes a volume of 2/80 for sample 1 and volume of 1/80 for sample 2. So every even sample is 13.32bit and every odd sample is 14.32bit. It still averages out to 14 bit, but it should have less noise than the traditional 14bit code. Also this is agnostic to phase shift, which I am still having problems with.

edit: Here is recording from nikosidis, 44336KHz, 64/64 volume, phaseshift method with values L=30, R=15 cycles for the phaseshift:
https://files.fm/u/zmpe8up9c

[nikosidis]

No question. Phaseshift give more quality. More space, dynamics to the music. It will be very nice to compare music with the old 14bit amp. with the new method

[8bitbubsy]

Originally Posted by robinsonb5

The point is that the volume PWM runs once every 64 colour clocks, so if you set AUDxPER to be a multiple of 64 it will remain in phase with the volume PWM, which is desirable.
Using AUDxPER of 128 will give you exactly 2 iterations of the PWM per sample.

Does this also apply to the more traditional way of doing 14-bit audio on Amiga? I'd use period 124 (normal video modes) if I could, but if period 128 is more sensible then I'll stick with that.
Also how much of a difference does it make in terms of the audio result?

[robinsonb5]

Originally Posted by 8bitbubsy

Does this also apply to the more traditional way of doing 14-bit audio on Amiga?

Yes, the implication here is that if the period counter and the volume PWM don't "align", then there will be interference patterns between them, and on the quiet channel one of the two bytes from each DMA fetch will have a disproportionate influence on the output.

Also how much of a difference does it make in terms of the audio result?

That would need to be measured.

[MisthaLu]

I'm currently stuck in a phase where I enjoy experimenting with various ways of reducing noise in my MOD files.
So I'm wondering if there is any way this technique will work in a MOD?
I'm assuming not, since it seems to require even more precise timed playback than the old 14-bit trick.
Maybe something like LSP would work though?