14.57731 bit audio

[ross]

@meynaf: yesterday I did an edit to an answer to Don_Adan to indicate what a big problem is: http://eab.abime.net/showpost.php?p=...3&postcount=69

Even if you correct the phase 'manually', syncing the AUDxDATs writes (if and only if it is truly ascertained that it is due to that) then you cannot use anymore the DMA.
And this would be a very big limitation (especially to maintain a constant flow at high frequencies).

[meynaf]

Originally Posted by ross

@meynaf: yesterday I did an edit to an answer to Don_Adan to indicate what a big problem is: http://eab.abime.net/showpost.php?p=...3&postcount=69

Even if you correct the phase 'manually', syncing the AUDxDATs writes (if and only if it is truly ascertained that it is due to that) then you cannot use anymore the DMA.
And this would be a very big limitation (especially to maintain a constant flow at high frequencies).

But if this is Agnus timings that give the phase shift, it becomes known. As data is obtained at fixed times.
And if not, then we can attempt to alter it.
So it all boils down to knowing what exactly gives said phase shift.

[orangespider]

Originally Posted by ross

@orangespider, if you agree, we need to change the thread topic, at this point it is misleading.

At the beginning I was skeptical that it could work properly, and in fact the spikes due to the coupled additive and subtractive approach, plus the phase shifting of the channels, generates too strong distortions and noise, if done with a direct conversion.
But the method is now different and evolved.

The conversion from the 16-bit input signal to the output signal is no longer linked by a surjective function, as in the case of C = V(64) + V(1)), but is now (from the clever trick of swapping channels onward) more a black box containing real time operations and filtering.

So, what do you think of:

"Alternative approch to play 16bit audio samples with Paula quasi-14bit"

or similar?

I don't see any option to change thread name.

Originally Posted by meynaf

Of course they are both delayed.
When DMA fetches the first sample, it sends it to AUDxDAT. If this starts the counter, then all subsequent samples will also be shifted, and by the exact same amount.
So what matters is the exact time the very first sample is sent.

That is a big if imho.

Originally Posted by meynaf

But if this is Agnus timings that give the phase shift, it becomes known. As data is obtained at fixed times.
And if not, then we can attempt to alter it.
So it all boils down to knowing what exactly gives said phase shift.

The reason isn't as important (unless you want to somehow make it disappear which I am still skeptical about) as the actual timing of the shift.

I think I know how we can find out how big the shift exactly is. Since we know it is less than 0.5 because the noise is amplified if I use the LUT approach and delay the 63 values by 1 sample. So, in that case we can do this.

measurement 1:
channel 0 data: 255,-255,255,-255
channel 3 data: 0, 0, 0, 0

measurement 2:
channel 0 data: 255, -255, 255, -255
channel 3 data: -255, 255, -255, 255

we loop with these values forever and sample the output. then we measure the amplitude of the resulting audio and we have the phase shift. If the audio amplitude of measurement 2 is the same as measurement 1, then the phase shift is exactly 0.5, if measurement 2 results in silence, then the shift is 0 and in between the amplitude changes linearly depending on the shift.

[nikosidis]

I got new handle for you :P
Pytagoras Orangespider

[pandy71]

If there is any chance for using 2 audio channels with normal DMA to play samples but in interleaved way - like for example |cn| where c means Channel and n is sample e.g. 00,10,01,11,02,12,03,13 etc? If yes and samples can be interleaved then easily 8 bit but double speed audio (without productivity) can be created and this together with aggressive noise shaping should provide HQ samples - similar to 14 bit mode but without too many complications...

[ross]

Originally Posted by pandy71

If there is any chance for using 2 audio channels with normal DMA to play samples but in interleaved way - like for example |cn| where c means Channel and n is sample e.g. 00,10,01,11,02,12,03,13 etc? If yes and samples can be interleaved then easily 8 bit but double speed audio (without productivity) can be created and this together with aggressive noise shaping should provide HQ samples - similar to 14 bit mode but without too many complications...

Hi pandy71, with the phase shift that seems to be there, impossible in DMA mode.
In any case then you should modify the samples on both channels, as they work in hold mode (but that would be simple )

[orangespider]

Originally Posted by pandy71

If there is any chance for using 2 audio channels with normal DMA to play samples but in interleaved way - like for example |cn| where c means Channel and n is sample e.g. 00,10,01,11,02,12,03,13 etc? If yes and samples can be interleaved then easily 8 bit but double speed audio (without productivity) can be created and this together with aggressive noise shaping should provide HQ samples - similar to 14 bit mode but without too many complications...

Actually my last 2 exe files already double the playback frequency like that. It's just not 100% correct because we don't know the exact shift yet. The idea is something like this:

c0: 0000.1111.2222.3333.4444
c3: x000.0111.1222.2333.3444

So you have say 25% of 0 and 75% of 1 from c3 while c0 is holding 1. So you can then get those 2 values to compensate to 2 values from the original file. Say you wanted to play 10 and 14 during 1 frequency tick. You would have to adjust 01, 30 and 31 to produce what you want. But to get to the exact values, you need to know the exact shift.

edit: For the example above we would already have the 30 set in the previous sample, let's say it was 8. So to get 10 and 14, we would have to set 01 at 4 and 31 at 24, which would then give us for the first half of the sample:
(8 + 4*2 + 24)/4 = 10
and for the other half:
(4+24)/2 = 14

This is one of the things my program currently does, altho it does with an assumed phase shift value which is incorrect. But it also spreads the errors and has the channels set to volume 64 and 63 to be able to get a greater number of combinations.

[ross]

Originally Posted by orangespider

Actually my last 2 exe files already double the playback frequency like that.

Well, in your case is in a software way (like an oversampling).
I think pandy71 mean an interleaved split from the original sample in high frequency, using an halved frequency.

[Don_Adan]

Originally Posted by ross

The problem here is that it is unclear how much the phase difference is, and even if it is possible to start DMA channels with such a precise delay..

EDIT: if Paula's internal counters are initialized at the first AUDxDAT write then it is useless to delay the start of the DMA, because even 'de-synced' start is fixed by Agnus' scheduler (you could delay it of a "scanline time", but it wouldn't make sense ..).
Yes, in case you could do it manually but then it would be just a proof of concept.

You like tests
For me you can choose very good quality mono 16 bit raw sample, 256KB length. Set only left channels 2 buffers, every 128KB (AudLen = $0000). And try to choose the best 64 and 63 tables for left channel. Later set right channel only and choose different (best) tables 64 and 63 tables for right channel. Fiinally you will be have 4 tables for 4 Amiga channels.

[orangespider]

Originally Posted by ross

Well, in your case is in a software way (like an oversampling).
I think pandy71 mean an interleaved split from the original sample in high frequency, using an halved frequency.

No, that's not what is happening. I am actually using the phase shift to get 2 values within 1 frequency tick, that's why I need double the frequency for the source.

edit: The sample I am talking about is this one:
http://s000.tinyupload.com/index.php...43813088953288

If you listen to it you'll notice there are frequencies in there that shouldn't exist at 27710. Altho since I am using wrong shift values, the output is not good enough yet.

[SpeedGeek]

Originally Posted by orangespider

I don't see any option to change thread name.

The moderating staff can do this for you but you will need to make a specific request for this to happen.

[ross]

Originally Posted by Don_Adan

For me you can choose very good quality mono 16 bit raw sample, 256KB length. Set only left channels 2 buffers, every 128KB (AudLen = $0000). And try to choose the best 64 and 63 tables for left channel. Later set right channel only and choose different (best) tables 64 and 63 tables for right channel. Fiinally you will be have 4 tables for 4 Amiga channels.

Hi Don , sorry, I'm not sure I understand what you mean..

Originally Posted by orangespider

No, that's not what is happening. I am actually using the phase shift to get 2 values within 1 frequency tick, that's why I need double the frequency for the source.

Ok, I saw your (two) edits with the additions only after

[orangespider]

Ok, so nikosidis and I have finished the measurement process and I know the actual phase shift. It appears to be around 4 bus cycles or 1/886718.75 seconds on a PAL screen regardless of the playback frequency - which btw is the exact delay of DMA writes.

edit:
At 27710Hz this translates exactly into:
channel0 start: 0/32 samples
channel1 start: 1/32 samples
channel2 start: 2/32 samples
channel3 start: 3/32 samples

edit 2:
At any AUDxPER the delay translates into this:
channel0 start: 0/AUDxPER samples
channel1 start: 4/AUDxPER samples
channel2 start: 8/AUDxPER samples
channel3 start: 12/AUDxPER samples

Don't know about the scandoubled values though, they might or might not differ.

[ross]

Originally Posted by orangespider

Ok, so nikosidis and I have finished the measurement process and I know the actual phase shift. It appears to be around 4 bus cycles or 1/886718.75 seconds on a PAL screen regardless of the playback frequency - which btw is the exact delay of DMA writes.

AUxDATA write by DMA is spaced 2 bus cycles, 1 bus cycle is 3546895Hz (~282ns), so is double the DMA writes.

[orangespider]

Originally Posted by ross

AUxDATA write by DMA is spaced 2 bus cycles, 1 bus cycle is 3546895Hz (~282ns), so is double the DMA writes.

I wonder if the read isn't 2 cycles as well... Imagine reading volume and data and using 4 cycles for that. Could be an explanation?

[ross]

Originally Posted by orangespider

I wonder if the read isn't 2 cycles as well... Imagine reading volume and data and using 4 cycles for that. Could be an explanation?

No, in a cycle 2 samples for a channel are read, then there is an idle cycle free for those who request it (CPU/Copper/Blitter), then the next channel.
Maybe something related to DMAL?

[Gorf]

Originally Posted by orangespider

Ok, so nikosidis and I have finished the measurement process and I know the actual phase shift. It appears to be around 4 bus cycles or 1/886718.75 seconds on a PAL screen regardless of the playback frequency - which btw is the exact delay of DMA writes.

edit:
At 27710Hz this translates exactly into:
channel0 start: 0/32 samples
channel1 start: 1/32 samples
channel2 start: 2/32 samples
channel3 start: 3/32 samples

edit 2:
At any AUDxPER the delay translates into this:
channel0 start: 0/AUDxPER samples
channel1 start: 4/AUDxPER samples
channel2 start: 8/AUDxPER samples
channel3 start: 12/AUDxPER samples

Don't know about the scandoubled values though, they might or might not differ.

This delay should stay exactly the same for 31kHz screen modes.

But percentage or degree wise the influence is bigger on shorter periods (= higher playback frequency)

So 12 cycles delay are <10% for a 128 ticks period or ~33° phase for 27kHz

But for a 64 ticks period this are ~19% or 67.5° phase mismatch at 54kHz...

(that is for channel 0+3)

For channel 1+2 it is no problem at all for normal PAL and and can maybe even be neglected for 54kHz playback, or should at least be fine with your "dominance switch avoidance".

[Gorf]

For the 0+3 channel @54kHz playback we could maybe take the following approach:

we would need a high quality audio sample and convert it to 5x of our target frequently - in this case 277kHz.

for every point in time a regular 54kHz playback would need we have now 4 additional points between them.
Let's call them t0, t1, t2 t3, t4
t0 is the time channel 0 starts playing - the next value comes in at t(0+5)
t1 is due to the delay of about 20% or 1/5 the time channel 3 starts playing - the next value comes in at (t1+5)

at t0 channel 0 needs to play a value that in combination with the previous value of channel 3 at time t(1-5) represents the desired "14.5bit" value at the timecode t0 of our 277kHz sample.

at t1 channel 3 needs to play a value that in combination with the value we did put in channel 0 at t0 gives us a good representation of the value at the timecode t1 of our 277kHz sample.

the values at timecode t2, t3 and t4 of our 277kHz sample are ignored and we repeat our procedure at t(0+5) ....

[ross]

Originally Posted by ross

Maybe something related to DMAL?

Nah .. this can't be the case, deleted

[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