14.57731 bit audio - Page 13

a/b · 16 February 2021, 14:54

Maybe relevant, several times you have:

Code:

	lsl.l	#7,d1
	addq	#1,d7
	cmp.l	d6,d7
	blt		.sk4_left

addq is missing size, typically defaults to .W, and you are using it as .L right before/after with a signed branch (supposedly unsigned data, so additionally 1 bit shorter range).

Code:

	eor.l	d6,d6

WHHHYYYYYYYYYYYYYYYY?!? moveq pretty please with sugar on top... and 5 hail Marys to get exorcised ;p.

ross · 16 February 2021, 15:05

Quote:

Originally Posted by a/b

Code:

	eor.l	d6,d6

WHHHYYYYYYYYYYYYYYYY?!? moveq pretty please with sugar on top... and 5 hail Marys to get exorcised ;p.

Unbeliever, use code like on x86 or you'll going to hell!

a/b · 16 February 2021, 15:08

Quote:

Originally Posted by ross

Unbeliever, use code like on x86 or you'll goto hell!

Reporting Ross' account to admins, must've been hacked by litwr.

ross · 16 February 2021, 15:11

Quote:

Originally Posted by a/b

Reporting Ross' account to admins, must've been hacked by litwr.

ROTFL

orangespider · 16 February 2021, 15:21

Quote:

Originally Posted by a/b

Maybe relevant, several times you have:

Code:

	lsl.l	#7,d1
	addq	#1,d7
	cmp.l	d6,d7
	blt		.sk4_left

addq is missing size, typically defaults to .W, and you are using it as .L right before/after with a signed branch (supposedly unsigned data, so additionally 1 bit shorter range).

Code:

	eor.l	d6,d6

WHHHYYYYYYYYYYYYYYYY?!? moveq pretty please with sugar on top... and 5 hail Marys to get exorcised ;p.

Fixed the addq thing and it just made things worse somehow. I clearly have some bugs in that converter, will have to clean it all up.

I kinda like eor tho.

Thorham · 16 February 2021, 15:42

Quote:

Originally Posted by orangespider

I kinda like eor tho.

Use clr on 68020+

Quote:

Originally Posted by orangespider

UPDATE:
https://files.fm/u/y6pgb8fvp

The low noise level without calibration is crazy

a/b · 16 February 2021, 16:03

Quote:

Originally Posted by Thorham

Use clr on 68020+

Incorrect! There's a 23.453443466666% chance that programmer will forget to specify the size and summon a guru. And with moveq there's a 100% chance that programmer will specify the .L size although it's completely pointless.

Quote:

Originally Posted by orangespider

I kinda like eor tho.

Interesting... I like Lea, with a single L.

8bitbubsy · 16 February 2021, 17:02

Quote:

Originally Posted by Thorham

Use clr on 68020+

I use clr as seldom as possible, it's slower than move. I tested this on a 68020 benchmark I made.

Thorham · 16 February 2021, 17:19

Quote:

Originally Posted by 8bitbubsy

I use clr as seldom as possible, it's slower than move.

Clr memory is slower, but not clr register.

8bitbubsy · 16 February 2021, 17:21

Oh ok, I see. I was indeed using it on memory in my benchmark test ( clr.l (a0)+ ).

orangespider · 16 February 2021, 17:34

Looks like I am going to have to revert to the previous version. Some people are reporting noisy playback on this one, and I think I know what is causing it.

It would appear it isn't possible to fully sync the channels. I can sync them no problem for lower frequencies, for example audxper = 2048 will be synced without any measurable impact. However, somewhere below 256 the syncing doesn't work anymore. It would appear that starting an audio DMA event at cycle 4 or cycle 80 yields the exact same result. I am guessing the same issue persist in larger audxper values, but it isn't audible because the margin of error is higher.

So the only thing I can see as a solution is to use the previous method of having the channels unsynchronized and then compensating for that as that method gave the best results. Which is a pity because that code is way more CPU intensive.

Apparently the:
cycle 0: channel 0
cycle 4: channel 1
cycle 8: channel 2
cycle 12: channel 3
Dynamic is somehow set in hardware.

I still don't know why, when I look at the audio diagram, manual writes to audxdat will reset the volume counter and the percounter is always 0 while dma is off and the audio chip has done it's work. So manually setting the audxdat values and then starting the dma before they expire should work.

Even just starting the DMA channels should work because even though they don't have a built in volume counter reset, they should reset the volume counters when the next DMA fetch occurs. Yet they somehow don't.

robinsonb5 · 16 February 2021, 17:50

Quote:

Originally Posted by orangespider

Apparently the:
cycle 0: channel 0
cycle 4: channel 1
cycle 8: channel 2
cycle 12: channel 3
Dynamic is somehow set in hardware.

Perhaps there's only one adder multiplexed between the four period counters, so they're updated in turn?
(Perhaps in the down cycles between channel 3 and 0 it's also handles SERPER, and maybe a fixed period for the disk subsystem too?)

Don_Adan · 16 February 2021, 18:46

Perhaps i have one idea for sync channels, which perhaps can works. I dont know if you tested this idea before. You can start/set up to play empty sample (128KB, maybe less) with different periods and maybe different start address and sample length. And when leading channel is looped set only periods for 2,3,4 channels.

orangespider · 19 February 2021, 10:14

Well, I think I reached as far as objectivity, goes, I need subjective input on these:
http://s000.tinyupload.com/index.php...57391871838150

I will add detailed explanation about each later, but I really need people who would just listen to it and report which one sounds cleanest. Thanks.

orangespider · 20 February 2021, 00:47

True to my tradition, I managed to assemble and post examples with a huge bug in them: the right channel was playing the same thing the left one was, which made a huge noise in all of the samples.

Here are the fixed versions and also the old method for reference:
http://s000.tinyupload.com/index.php...88271423456522

The difference between the new and the old method is that the old one had 32bit float as a source in the PC converter, which gave it a headstart, but it also used calculations that might be too complex for a realtime conversion. The new ones can be easily converted on amiga, if they pass, I will write the assembler code for those.

Here is what each does:
PAL-piano-none.exe -- only compensates for the noise that is added in the phase shift and is playing the audio in a constant slightly above 9bit bitrate
PAL-piano-full.exe -- shapes the phase shift noise to be equal and opposite of the 16 bit to 9 bit conversion noise in the hopes that the 2 noise signals cancel each other out and we get to 11 bit quality
PAL-piano-thrd.exe -- has a threshold on the added phase shift noise so that the output is 10 bit quality, but in case the phaseshift noise is too audible, this will help with that
PAL-piano-half.exe -- reduces the added phase shift noise by 50%, which should also result in 10 bit quality but in a different way compared to the threshold one
PAL-piano-old.exe -- using the old method with 64/63 volumes
PAL-song-full.exe -- converted the song with full noise shaping just because the piano is boring (at the end of this, random stuff will be played because I didn't quit on time, just ignore that, thx)

None of these methods are too computationally complex - except the old one.

Thorham · 20 February 2021, 11:30

Sadly they're all still more noisy than traditional calibrated 14 bit.

orangespider · 20 February 2021, 11:50

Quote:

Originally Posted by Thorham

Sadly they're all still more noisy than traditional calibrated 14 bit.

Are you sure that you're not comparing it to 44Khz+ 14bit? The noise frequency at audxper 80 and below is above human hearing range.

Also, can you test with a freshly restarted system? If I use different audio sources it messes up the audio sync and I still didn't figure out how to resync it. Once the sync is completely messed up you get 10x the noise you get while the channels are in default sync.

Thorham · 20 February 2021, 12:12

Quote:

Originally Posted by orangespider

Are you sure that you're not comparing it to 44Khz+ 14bit?

Yes. I actually have two versions of the piano music. One 28 khz and one 44 khz and using traditional calibrated 14 bit they sound equally noisy.

Quote:

Originally Posted by orangespider

Also, can you test with a freshly restarted system?

Tried it. Did a reset after each executable and it made no difference.

nikosidis · 20 February 2021, 12:15

Quote:

Originally Posted by Thorham

Sadly they're all still more noisy than traditional calibrated 14 bit.

Remember this is PAL and not productivity outputs.

orangespider · 20 February 2021, 12:17

Quote:

Originally Posted by Thorham

Tried it. Did a reset after each executable and it made no difference.

This is weird. I did manage to get it to play noisy on my system, but the noise is gone every time I do a full shut down, wait 10s and start. Maybe your system has a different default channel delay?

If it's not same on all systems, then I won't get away without figuring out a way to sync the channels.

16 February 2021, 14:54	#241
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	Maybe relevant, several times you have: Code: lsl.l #7,d1 addq #1,d7 cmp.l d6,d7 blt .sk4_left addq is missing size, typically defaults to .W, and you are using it as .L right before/after with a signed branch (supposedly unsigned data, so additionally 1 bit shorter range). Code: eor.l d6,d6 WHHHYYYYYYYYYYYYYYYY?!? moveq pretty please with sugar on top... and 5 hail Marys to get exorcised ;p.

20 February 2021, 00:47	#255
orangespider Registered User Join Date: Feb 2021 Location: Becej / Serbia Posts: 120	True to my tradition, I managed to assemble and post examples with a huge bug in them: the right channel was playing the same thing the left one was, which made a huge noise in all of the samples. Here are the fixed versions and also the old method for reference: http://s000.tinyupload.com/index.php...88271423456522 The difference between the new and the old method is that the old one had 32bit float as a source in the PC converter, which gave it a headstart, but it also used calculations that might be too complex for a realtime conversion. The new ones can be easily converted on amiga, if they pass, I will write the assembler code for those. Here is what each does: PAL-piano-none.exe -- only compensates for the noise that is added in the phase shift and is playing the audio in a constant slightly above 9bit bitrate PAL-piano-full.exe -- shapes the phase shift noise to be equal and opposite of the 16 bit to 9 bit conversion noise in the hopes that the 2 noise signals cancel each other out and we get to 11 bit quality PAL-piano-thrd.exe -- has a threshold on the added phase shift noise so that the output is 10 bit quality, but in case the phaseshift noise is too audible, this will help with that PAL-piano-half.exe -- reduces the added phase shift noise by 50%, which should also result in 10 bit quality but in a different way compared to the threshold one PAL-piano-old.exe -- using the old method with 64/63 volumes PAL-song-full.exe -- converted the song with full noise shaping just because the piano is boring (at the end of this, random stuff will be played because I didn't quit on time, just ignore that, thx) None of these methods are too computationally complex - except the old one. Last edited by orangespider; 20 February 2021 at 05:16.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
15 bit 44 khz audio idea.	Thorham	Coders. General	33	15 September 2021 06:22
24 or 32 bit audio capture within WinUAE	EAUniW	support.WinUAE	7	17 September 2018 22:22
Questions about 14 bit audio playback	xxxxx	Coders. Asm / Hardware	16	22 December 2014 19:30
High Quality reproduction of Audio on 8 bit.	pandy71	Amiga scene	0	01 July 2013 15:08
Simple 14 bit audio question...	Thorham	Coders. General	7	06 June 2010 10:55

16 February 2021, 17:21	#250
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Oh ok, I see. I was indeed using it on memory in my benchmark test ( clr.l (a0)+ ).

16 February 2021, 17:34	#251
orangespider Registered User Join Date: Feb 2021 Location: Becej / Serbia Posts: 120	Looks like I am going to have to revert to the previous version. Some people are reporting noisy playback on this one, and I think I know what is causing it. It would appear it isn't possible to fully sync the channels. I can sync them no problem for lower frequencies, for example audxper = 2048 will be synced without any measurable impact. However, somewhere below 256 the syncing doesn't work anymore. It would appear that starting an audio DMA event at cycle 4 or cycle 80 yields the exact same result. I am guessing the same issue persist in larger audxper values, but it isn't audible because the margin of error is higher. So the only thing I can see as a solution is to use the previous method of having the channels unsynchronized and then compensating for that as that method gave the best results. Which is a pity because that code is way more CPU intensive. Apparently the: cycle 0: channel 0 cycle 4: channel 1 cycle 8: channel 2 cycle 12: channel 3 Dynamic is somehow set in hardware. I still don't know why, when I look at the audio diagram, manual writes to audxdat will reset the volume counter and the percounter is always 0 while dma is off and the audio chip has done it's work. So manually setting the audxdat values and then starting the dma before they expire should work. Even just starting the DMA channels should work because even though they don't have a built in volume counter reset, they should reset the volume counters when the next DMA fetch occurs. Yet they somehow don't.

16 February 2021, 18:46	#253
Don_Adan Registered User Join Date: Jan 2008 Location: Warsaw/Poland Age: 55 Posts: 1,975	Perhaps i have one idea for sync channels, which perhaps can works. I dont know if you tested this idea before. You can start/set up to play empty sample (128KB, maybe less) with different periods and maybe different start address and sample length. And when leading channel is looped set only periods for 2,3,4 channels.

19 February 2021, 10:14	#254
orangespider Registered User Join Date: Feb 2021 Location: Becej / Serbia Posts: 120	Well, I think I reached as far as objectivity, goes, I need subjective input on these: http://s000.tinyupload.com/index.php...57391871838150 I will add detailed explanation about each later, but I really need people who would just listen to it and report which one sounds cleanest. Thanks.

20 February 2021, 11:30	#256
Thorham Computer Nerd Join Date: Sep 2007 Location: Rotterdam/Netherlands Age: 47 Posts: 3,764	Sadly they're all still more noisy than traditional calibrated 14 bit.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)