14.57731 bit audio

[robinsonb5]

Originally Posted by orangespider

Then after a short while the channel continues the playback. This keeps happening periodically. At 64 this effect happens most often, then as you go up towards 68 it happens less and less often. Then at 68 it works normally although for whatever reason the audio quality is lower than it should be until 72.

And this is with the Multiscan:Productivity screenmode - have you adjusted the totclks count with MonEd?

[malko]

Originally Posted by nikosidis

Recorded from output of my A1200 latest version from orangespider.

This is the productivity output. The 2 files will be played in order.

https://files.fm/u/7jkjvztkn

The same goes for PAL.

https://files.fm/u/d889s6jfj

Last and not least the original file of the first song. Not output from my Amiga

https://files.fm/u/bwevv52uq

Wow !

[Thorham]

Originally Posted by orangespider

I have uploaded the latest version:
http://s000.tinyupload.com/index.php...91824436594910

Awesome, thanks

I converted your converter to c# if you're interested.

[orangespider]

I need someone who can run 2 short exe files on a real machine as I can't right now.

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

Please let me know if they work and if they sound different. If I did this correctly, I managed to change the audio channel phase shift from copper. I need this info, if this works (and it does in winuae), we can throw everything I did so far away because we are going to have some real audio quality then.

[Thorham]

Originally Posted by orangespider

Please let me know if they work and if they sound different.

If the sound is supposed to be a beep then it works and they both sound the same.

[orangespider]

They sound exactly the same? And yes, it's a beep.

edit: they both should be at the same frequency but should have a different waveform.

[Thorham]

Originally Posted by orangespider

They sound exactly the same?

They sound identical.

[orangespider]

Originally Posted by Thorham

They sound identical.

That is -very- unfortunate. For several reasons. One is that I can't use winuae to test any of this and the second one is that it seems that regardless of when you start the DMA on the real amiga, it will still "sync" the samples as if you started them at the same time.

[Thorham]

Originally Posted by orangespider

That is -very- unfortunate.

On my A1200 the screen goes black for a second. If that's not supposed to happen it may be a bug.

[Gorf]

Originally Posted by orangespider

They sound exactly the same? And yes, it's a beep.

edit: they both should be at the same frequency but should have a different waveform.

At what frequency?
at lower frequencies the difference should be more obvious, while it can be hard to tell apart at higher ones...

[ Show youtube player ]

[orangespider]

Originally Posted by Thorham

On my A1200 the screen goes black for a second. If that's not supposed to happen it may be a bug.

nah, its just my dumb way of taking over the copper from the system for a while.

Originally Posted by Gorf

At what frequency?
at lower frequencies the difference should be more obvious, while it can be hard to tell apart at higher ones...

[ Show youtube player ]

It was at 1732Hz.

[Thorham]

Originally Posted by orangespider

nah, its just my dumb way of taking over the copper from the system for a while.

If they're supposed to be different wave forms than something else might be happening. If you post the source code I can take a look just to make sure.

[Gorf]

Originally Posted by orangespider

nah, its just my dumb way of taking over the copper from the system for a while.


It was at 1732Hz.

So we should hear something like the 2kHz example in the video (at 3:39)?
Of course the difference is less prominent on less different waveforms ...

by the way I was thinking of yet another possibility:
dividing the frequencies for each channel.

so we could play lower frequencies (eg. <1kHz) with a period of 128 ticks and the higher frequency part with 64 ticks.
Additionally we could try to correct the values of the 8bit-Low frequency part with the high-fequency channel 2 times per time period ...

so it would be:
AUD0DAT 64 (right HF)
AUD1DAT 64 (left HF)
AUD2DAT 128 (left LF)
AUD3BAT 128 (right LF)

With this we could play c3 without "collapsing" on normal productivity (and without Copper feed) and we also would need 25% less sample data ...

Just a crazy thought ....

[orangespider]

Originally Posted by Thorham

If they're supposed to be different wave forms than something else might be happening. If you post the source code I can take a look just to make sure.

I'm trying to do this:

Originally Posted by Toni Wilen

Bit late answer but I wasn't sure if this thread will become one of those threads or not..

But yes, volume counter is reset when: audio channel state transitions from 0 to 2 (=Copper/CPU AUDxDAT write) or DMA does AUDxDAT write (channel's horizontal slot position) and state is 5.

Check "volcntrld" in HRM audio state diagram.

I think it can be reset manually by doing this:
1: Make sure audio channel is idle.
2: CPU/copper write to AUDxDAT. Volume counter is reset. (Probably needs copper to guarantee correct timing?)
3: Switch DMA on. DMA mode "starts" and volume counter is not reset because state transition from 5 to 2 didn't happen.
4: Audio continues in DMA mode with original AUDxDAT position "synced" volume counter.

Step 3 needs extra care because DMA must be switched on before period has counted down. It also bypasses stages 1-5-2 which means DMA continues from previously latched position, which is not necessarily same as AUDxLC, same with AUDxLEN. To make this work, you probably need to start normal audio DMA first, wait a bit, turn off DMA. Wait until audio state is back to zero. Now AUDxLC and AUDxLEN has been "prelatched". Then continue with step 1.

This is not tested but should work

The goal is to set channels 2 and 3 at exactly half phase from 0 and 1. Then we would actually have double the frequency discrete samples of the same length.

Once we have that we could get either up to 15 bit base frequency or 14 bit double frequency quality without the noise of the old style 14 bit way. We could even go with less bits but higher volume. Also, the player code would become quite simple as we could just use the 2 channels as a DPCM signal, getting something like this:

0a 0a 0b 0b 0c 0c 0d 0d
   3a 3a 3b 3b 3c 3c 3d

So if we set the volume at 64 for both channels we would still get 9/10 bit quality depending on the frequency. But it's a delta modulation because you can only jump with one value at a time. You would get 10 bits for the same frequency playback because you would mix like this:
0a + 0a + 3a + 3b - which means you could get 1024 different values within each sample.

[Gorf]

Originally Posted by orangespider

I'm trying to do this:
...

I fear this only makes things worse instead of better ... at least for normal PAL playback. On productivity it might sound not that different ... except a little bit noisier than previous attempts.

Just my bet on this, don't think this will be better - but I might be completely wrong here.

[Toni Wilen]

Could you include binary that causes the "collapse". If it really happens in emulation too, then there is no way for it to be anything unknown

(and I can usually debug things but requirement is always test binary)

[ross]

Originally Posted by Toni Wilen

Could you include binary that causes the "collapse". If it really happens in emulation too, then there is no way for it to be anything unknown

(and I can usually debug things but requirement is always test binary)

I send to you something to try
An exe that open a custom video mode specifically to use period 64.

Video Resolution: 640x512, H-freq: 33.5Kz, V-freq: 60Hz


EDIT:
My code doesn't do a 'channel collapse' on WinUAE, I think that orangespider do not use a proper screen mode (or some software related thing)

[orangespider]

Originally Posted by Toni Wilen

Could you include binary that causes the "collapse". If it really happens in emulation too, then there is no way for it to be anything unknown

(and I can usually debug things but requirement is always test binary)

I'm pretty sure it's a DMA fetch failure. I can make an example later, but its generally any program that plays audio at 64 audxper on all 4 channels at the same time.

Originally Posted by ross

EDIT:
My code doesn't do a 'channel collapse' on WinUAE, I think that orangespider do not use a proper screen mode (or some software related thing)

I was testing in productivity mode, 29.29kHz / 58Hz because its a standard mode plus it's the mode we use for recording the output. 64 doesn't work in that mode.




Anyway, I need someone to test this on real iron:
http://s000.tinyupload.com/index.php...05319330510531

It has 2 exe files
audio-phaseshift-1.exe -- tries to do 50% phase shift
audio-phaseshift-2.exe -- minimizes phase shift by reordering channels to 0,3,1,2

If it works the screen will turn dark blue and there will be a constant beep sound. audio-phaseshift-1.exe should be way louder than audio-phaseshift-2.exe, I reduced the frequency of the sound to 432Hz, so the difference should be clear. Please let me know if they work as intended. Thanks.

[Thorham]

Originally Posted by orangespider

If it works the screen will turn dark blue and there will be a constant beep sound. audio-phaseshift-1.exe should be way louder than audio-phaseshift-2.exe, I reduced the frequency of the sound to 432Hz, so the difference should be clear. Please let me know if they work as intended. Thanks.

I don't think it works properly. Audio-phaseshift-1.exe produces a beep, but audio-phaseshift-2.exe doesn't always. Also, the screen doesn't go blue, it goes black, and it doesn't exit to Workbench properly, because the screen stays.

Note: I'm using a custom double scan mode (productivity tuned with MonSpecs).

[orangespider]

Originally Posted by Thorham

I don't think it works properly. Audio-phaseshift-1.exe produces a beep, but audio-phaseshift-2.exe doesn't always. Also, the screen doesn't go blue, it goes black, and it doesn't exit to Workbench properly, because the screen stays.

Note: I'm using a custom double scan mode (productivity tuned with MonSpecs).

Ugh... This literally wasn't made to work with double scan modes, it expects a PAL screen.

edit: Is the phaseshift-1.exe beep loud? And when phaseshift-2 does produce audio is it lower volume...

edit 2: Anyone with PAL can test this?