14.57731 bit audio

[orangespider]

Ok so, I have finished the productivity resolution version as well now.

The simulated frequency is at 98.524Hz, same method as for the PAL version. Put the source code of the PC converter and the Amiga player as well as 2 assembled exe files with the usual song + piano solo:
http://s000.tinyupload.com/index.php...53388914051728

The 55.420Hz PAL version is at:
http://s000.tinyupload.com/index.php...53815532511093

Notice, the conversion routine differs because the phase shift isn't in the same relation to the frequencies.

[Gorf]

Originally Posted by chb

I think buggs reported something similar here:

It is a bit funny, because I have seen that 56 kHz figure for AGA/ECS countless times, but it seems like almost no one tested it.

A period of 64 should give us 55.4 kHz and still be fine according to buggs, right?
Edit:

Ahh ok - he said 54.5 and not 55.4 ...

[orangespider]

btw: For my conversion to work, the AUDxPER needs to be dividable by 8. Which is why I ended up going for 72, that's the highest I can go with this. 128 is the highest I can go for PAL as well.

[robinsonb5]

Try using moned to reduce the number of clks per line and thus boost the horizontal frequency - can you get clean playback at period 64 that way?
http://aminet.net/driver/moni/MonEd3a.lha
(You might lose the right-hand edge of the screen as a side-effect...)

[Gorf]

@ nikosidis

So what is your real A1200 verdict on the "98.524Hz" version?

[ross]

Ok, period=64, channel3 need HTOTAL=$6D.

This is bad, really bad

(technical reasons will follow)

[Gorf]

Originally Posted by ross

Ok, period=64, channel3 need HTOTAL=$6D.

This is bad, really bad

(technical reasons will follow)

Ok .. explanation is very welcome

But $6d (109 ticks) vs. $71 (113 ticks) seems doable with a custom screen mode

[nikosidis]

No more errors in right channel

Here are the outputs.

https://files.fm/u/pdkgcb7hm

Piano recording.

https://files.fm/u/kmxrbzzfx

[ross]

The minimum audio Period usable by DMA mode is determinated by the request logic from Paula to Agnus.
On the line first refresh slot some signals are latched in the internal shift register, then transmitted with a delay on the DMAL line
(with a serial protocol that select if grab new data by selected DMA channel).
The delay is not constant but depends on the temporal distance between this first slot and the moment in which the sample data is transmitted.

From the HRM you know that C0->slot 13, C1->15, C2->17, C3->19

As in a PAL line there is 227CCK, you can calculate min Period*:
C0=(227+13)/2=120
C1=(227+15)/2=121
C2=(227+17)/2=122
C3=(227+19)/2=123
(*add 1 to this figure if a dma pointer reload from location register request is also transmitted)

Back to Period=64:
With $6D CCK per line (109+19)/2=64

Problem here is that no one use this default HTOTAL value in productivity mode...

If there are any mistakes Toni can correct me.

[Gorf]

Originally Posted by nikosidis

No more errors in right channel

Here are the outputs.

https://files.fm/u/pdkgcb7hm

Piano recording.

https://files.fm/u/kmxrbzzfx

WOW
This sounds great! Especially the "Productivity1.wav"
The Piano has some big noise floor ... a litte bit less than in the Pal version
Is this already there in the original audio file?
(did not find the source to compare :-/)

[Gorf]

Originally Posted by ross

The minimum audio Period usable by DMA mode is determinated by the request logic from Paula to Agnus.
On the line first refresh slot some signals are latched in the internal shift register, then transmitted with a delay on the DMAL line
(with a serial protocol that select if grab new data by selected DMA channel).
The delay is not constant but depends on the temporal distance between this first slot and the moment in which the sample data is transmitted.

From the HRM you know that C0->slot 13, C1->15, C2->17, C3->19

As in a PAL line there is 227CCK, you can calculate min Period*:
C0=(227+13)/2=120
C1=(227+15)/2=121
C2=(227+17)/2=122
C3=(227+19)/2=123
(*add 1 to this figure if a dma pointer reload from location register request is also transmitted)

Back to Period=64:
With $6D CCK per line (109+19)/2=64

Problem here is that no one use this default HTOTAL value in productivity mode...

If there are any mistakes Toni can correct me.

(my mistake was thinking that "everything" gets divided by two in productivity ... but that is of course only true for CCK .. the audio fetch stays at the same slots no matter what ... )

Strange though that the "64" sample did run most of the time and only has some break downs from time to time...

[robinsonb5]

Originally Posted by ross

Problem here is that no one use this default HTOTAL value in productivity mode...

Does the mode actually work OK with this HTOTAL value?

[orangespider]

I have found a brand new approach at the conversion side that has no audible difference between the source and the Amiga one. I have tested with the productivity version vs a sample at 98.524Hz and when both source and amiga version are being synced and swapped there is no change in the audio.

I have removed all of the preprocessing, instead I just take a raw 98.524Hz signal, convert it to amiga format, then emulate amiga playback and find the difference between the output and the input. Then I simply add the difference to the input and rerun the conversion. This perfectly restores any lost frequencies and even improves the perceived bit depth (which might be because this produces more aggressive dithering). Will convert everything and post it all soon.

I think this method can be actually used to play any frequency up to twice of the Amiga playback frequency with a slight modification.

[orangespider]

Originally Posted by Gorf

WOW
This sounds great! Especially the "Prodictivity1.wav"
The Piano has some big noise floor ... a litte bit less than in the Pal version
Is this already there in the original audio file?
(did not find the source to compare :-/)

There is a slight noise in the source that did get amplified by a factor of 2 or so.

[nikosidis]

Originally Posted by orangespider

There is a slight noise in the source that did get amplified by a factor of 2 or so.

No matter what, this approach sounds cleaner and with less noise, hiss than before with the 14-bit amplifier

When it is this clean I wonder about the high-freqency filter. It would be cool if there was an option in a future player for different high-freq. filters.

[orangespider]

Btw whoever said they can play 54.5 KHz, they didn't try to play it for long enough. It takes longer time but eventually the same audio channel collapses there too.

edit: 64, 65 and 66 all collapse.

edit2: 67 does too.

[nikosidis]

https://files.fm/u/uk84j6u2c

This is the Productivity screenmode
I use ScanPlusAGA as scandoubler to this 15" vga monitor.

[Gorf]

Originally Posted by orangespider

Btw whoever said they can play 54.5 KHz, they didn't try to play it for long enough. It takes longer time but eventually the same audio channel collapses there too.

edit: 64, 65 and 66 all collapse.

edit2: 67 does too.

Still strange .... I do get the calculation from the HRM ... so far so good.
What I don't get is, that it starts playing channel 3 at all and does so for quite some time on real hardware ... while a period of 64 would dictate a fetch in every line - which should be impossible according to the manual :-/

still scratching my head

[Gorf]

Originally Posted by nikosidis

https://files.fm/u/uk84j6u2c

This is the Productivity screenmode
I use ScanPlusAGA as scandoubler to this 15" vga monitor.

This mode looks definitively slim enough ...

[orangespider]

update: All experiments to further improve on this have failed, seems like the versions I've posted are the best possible both for PAL and productivity. Will try to adapt it for 124 for PAL and for 70 for productivity later just to squeeze out a bit more samples per second.