15 bit 44 khz audio idea.

[Thorham]

Hi,

The idea is based on the fact that some programs can playback 8 bit 84 khz audio on a standard A500 (Megalo Sound sampler software, for example).

Basically you create two 14 bit channels by changing the volume bits along with the sample data (you convert the 16 bit data to an 8 bit sample, and 6 bit volume part), and then combine the two 14 bit channels to get one 15 bit channel. Because you can't use DMA for this, a timer interrupt is used (tried something with the copper, but was unsuccessful).

Sounds plausible? Is it worth trying?

Any thoughts are appreciated

[meega]

I think I prefer the already established 14-bit approach (8-bit "high" + 6-bit "low" for each of left and right, works because you have 4x 8-bit channels available).

[Kalms]

1) unless you build this into a copperlist or do *nothing* else during replay, timing will be very difficult
2) 8bits data * 6bits volume will not necessarily give you 16384 unique output values. You will get more precision close to 0.0 than at the end of the interval. This may or may not be good.

[Thorham]

Originally Posted by Kalms

1) unless you build this into a copperlist or do *nothing* else during replay, timing will be very difficult

Perhaps I'll try that copper list method again, because I might just have made a mistake. As for timing, it's not really a problem, until you start reading data of the HD, then it becomes impossible. Should have known it was too easy

Originally Posted by Kalms

2) 8bits data * 6bits volume will not necessarily give you 16384 unique output values. You will get more precision close to 0.0 than at the end of the interval. This may or may not be good.

Yep, that's very true. Perhaps I'll first try this on the peecee with some raw audio data: The higher the volume, the more bits get chopped off (up to eight).

Thanks for the input It's perhaps not such a good idea after all, unless it can work with the copper, and the precision for loud samples isn't a problem.

[pandy71]

I have similar idea - did anyone try to play in non-DMA mode samples by using a copper instead of the CPU?

With using proper noise shaping 8 bit can be "easily" pushed to the 16 bit like quality (similar idea as in 1 bit/few bit Delta Sigma or noise shaping converters).

[Thorham]

I've tried copper DMA, but I failed. This doesn't mean it's not possible, of course

What might be an option would be to have one channel play back at, say, 28Khz, and use the copper to change the volume. If it works, you have something like 'hardware ADPCM', with just a single channel.

[pandy71]

What type of fail we talk? No sound at all or weird sounds - please describe Your experiment - maybe some copper list - TIA.

Probably Toni knows more about magical 28867Hz - I know allocation for DMA cycles during line but what with distribution of DMA cycles during field/frame

It is not clear for me how DMA cycles for audio are located on blanking lines - or maybe DMA is stopped so we have this limitation - 28867 instead 31250Hz

Also im curious how normal ie DMA samples are distributed - they are combined in analog way? digital? interleaved? I need to recover my Amiga's and buy some o-scope to watch this but it take some 2 -3 months...

[Toni Wilen]

Originally Posted by pandy71

What type of fail we talk? No sound at all or weird sounds - please describe Your experiment - maybe some copper list - TIA.

Probably Toni knows more about magical 28867Hz - I know allocation for DMA cycles during line but what with distribution of DMA cycles during field/frame

It is not clear for me how DMA cycles for audio are located on blanking lines - or maybe DMA is stopped so we have this limitation - 28867 instead 31250Hz

Probably related to timing/delay between DMA cycles and Paula's DMAL-pin that is used to request data from Agnus. I have been planning to check this using my logic analyzer but audio related stuff is not as interesting as copper or blitter or bitplanes

Also im curious how normal ie DMA samples are distributed - they are combined in analog way? digital? interleaved? I need to recover my Amiga's and buy some o-scope to watch this but it take some 2 -3 months...

No idea.

[yaqube]

Originally Posted by pandy71

Probably Toni knows more about magical 28867Hz

This maximum sampling frequency is determinated by the DMA request logic from Paula to Agnus. On the first refresh slot the 4 pairs of AUDxDR and AUDxDSR signals are latched in the internal shift register. Then it's transmitted with a delay (TDM) on the DMAL line to the Agnus. [you can find more info in the Minimig's sources].

Very interesting is the fact that the maximum sampling frequency isn't the same for every audio channel. It depends on the delay from the first refresh slot to the moment the sample data is transmitted.

The minimum sampling periods for the audio channels:
#0 : 120 (121)
#1 : 121 (122)
#2 : 122 (123)
#3 : 123 (124)
In the parenthesis is the minimal value when the DSR (dma pointer reload from location register) request is transmitted (typical case when the sample length is 1).

When the variable display mode is used (ECS/AGA feature) the scan line may be shorter (Multiscan, DblPAL, DblNTSC) and the maximum audio sampling frequency higher (56 kHz).

- I know allocation for DMA cycles during line but what with distribution of DMA cycles during field/frame

There is no difference. The DMA engine is scan line based.

It is not clear for me how DMA cycles for audio are located on blanking lines

Exactly the same as during any other scan line.

- or maybe DMA is stopped so we have this limitation - 28867 instead 31250Hz

It's not stopped.

Also im curious how normal ie DMA samples are distributed - they are combined in analog way? digital? interleaved?

Taking into account that the Paula is made using NMOS technology the sample combining has to be made in the analog domain (current mode DAC).

[Toni Wilen]

Originally Posted by yaqube

DMAL

Thanks, I thought it was something much more complex..

It is time to emulate this properly after 2.2 is out

[absence]

Does this mean that when playing a sample using DMA, the samples aren't evenly distributed (i.e. the time between each sample isn't constant), or is that what the need for oscilloscopes is about? Or am I completely missing the point?

[pandy71]

Thx Yaqube - Minimig is not a good example (i greatly appreciate work behind Minimig - this is great project) - You can implement functionality in a different way than it is made in original chipset - more interesting to me is A-Clone to be honest - but obviously details about IC internal life will be never presented wide open.

So why we have 28867Hz limitation - not simple 2x625x25? - seems that not all lines are used for audio and way to workaround is to equally distribute sampling on time - ie kind of FIFO.

Im also not sure about analog combining of channels - typical DAC is a quite big in terms occupied silicon area - even on SID 6 DAC occupy over 60 - 70% of die.
I can imagine that samples are combined in 14 bit words then 2 DAC convert them to analog (all you need to do this is a 2-to-1 muxer ) - in terms of circuitry cost much less than create 4x 14 bit DAC's

And if samples are not produced at the same moment there is channel that higher than 28867Hz samples can be played on OCS with hardware - only samples need to be distributed on 2 channels.

pzdr
ap

[Toni Wilen]

Originally Posted by pandy71

So why we have 28867Hz limitation - not simple 2x625x25? - seems that not all lines are used for audio and way to workaround is to equally distribute sampling on time - ie kind of FIFO.

Yaqube's answer explains it completely. It has nothing to do with lines.

There is 13 DMA cycle difference between DMA request and DMA transfer (for channel 0, channel 1 has 15 cycle difference etc..)

Min period = (color clocks in horizontal line + 13) / 2 + channel. Period counting to zero between hpos=1 and DMA cycle: sample repeats. (EDIT: remember that new word is getting fetched while previous is playing)

I assume DMAL is also used for disk dma? I guess disk dma DMAL pulses come before audio? (odd/even for reads and writes?)

[pandy71]

Yaqube answer explain for me latency (delay between DMA request and sample arrive).
Lines are important for me due of that at the begining each of line are 4 DMA slots for audio samples. Only this HPOS=1 explain mystery a bit

And Next question appears...

"Shorten" line can create possibility to play faster than 28.8ksps?
then DMA sound over 28.8kpsp can be even on OCS.
I'm asking because i never made experiment with software shortening lines - i only extend number of the lines and this work quite well AFAIR (at a cost fps abviously).

"Shorten" mean end line by explicit write to the VHPOSW something like $xxFF?


--

Originally Posted by Toni Wilen

I assume DMAL is also used for disk dma? I guess disk dma DMAL pulses come before audio? (odd/even for reads and writes?)

Accordingly to the EP0317567 and US4829473 - there is serialization logic in Paula that allow to send all DMA request to ? Agnus?

And answering me on question how many DAC's is in Paula - there are four DAC's (seems that each is 14 bit or 6+8 bit) - IMHO this is huge waste of silicone or maybe potential area to optimize silicon for different Paula revisions (latest rev seems to be 7 for Paula?)

[yaqube]

Originally Posted by Toni Wilen

I assume DMAL is also used for disk dma? I guess disk dma DMAL pulses come before audio? (odd/even for reads and writes?)

Yes, there are 6 DMAL slots directly preceeding the 8 dedicated for the audio subsystem.

The slots 1, 3 and 5 are active whenever the disk DMA is idle or in write mode.
The slots 2, 4 and 6 signal the need for data transfer.

During writes the slot #2 is active whenever there is at least one empty entry in the FIFO inside the Paula. The slot #4 is active whenever there are at least 2 empty entries and the slot #6 whenever the FIFO is empty.

During reads the slot #6 is active whenever there is at least one word to transfer. The slot #4 whenever there are 2 words to transfer and the slot #2 whenever there are 3 words to transfer. During disk reads the DMA slots are allocated in the reverse order (the first used is the third one). That might be important for cycle exact emulation.

[yaqube]

Originally Posted by pandy71

And Next question appears...

"Shorten" line can create possibility to play faster than 28.8ksps?
then DMA sound over 28.8kpsp can be even on OCS.
I'm asking because i never made experiment with software shortening lines - i only extend number of the lines and this work quite well AFAIR (at a cost fps abviously).

"Shorten" mean end line by explicit write to the VHPOSW something like $xxFF?

It should work. But remember the OCS copper cannot write registers in the range $000-$03E (that includes VPOSW and VHPOSW).

[pandy71]

Thx Yaqube!
I know limitation of the OCS - so change of VHPOSW must be done by CPU but CPU can service interrupt routine then i assume that this should be possible with minimal CPU overhead.

And next question (wrong thread but...) how frequently can be changed ColorXX register in OCS? (ie external writing - data injected by external circuit)

And next question related to the sound.
There is possibility to modulate AUDxVOL by another channel - but there is only possible to use words's not byte's - so we loss half sample periods and we use only 6 from 16 bites.
But can with short video line (even shorter than half), with proper data processing - small buffer, lower half of 16 bit expanded twice - ie oversampled by 2 with for example simple dither - like LFSR low 2 bit pseudo noise dither so dither is 2x faster than our audio data, upper half used 6 bit from 8 then extended to the 16 and placed in second buffer, then buffers played with 2 channels with enabled modulation so system meet Nyquist criteria (lower half is oversampled and dithered) - only problem with usability of graphics (but 160 - 240 pixels in hires should be available).
So theoretically speaking can we meet almost hardware >14bit with something over usable >32 ksps?

Sorry for strange questions but...

TIA
BR

[Kalms]

The Copper can perform one write to ColorXX every 8 LORES pixels.


However I should point out that if you end scanlines prematurely by writing to VPOS, this will affect the display timing. The horizontal refresh rate will no longer be 15kHz. I doubt that any TV will be happy to display the video signal that the Amiga will send out.

[pandy71]

Thx Kalms,
Yes, i know that - and to be honest i count on that (higher sampling speed for audio - i need something like 64 - 88 ksps) - timing is not so important as i can catch externally whole video and buffer in some memory and display with something more use full or i can even use some multi-frequency monitor (like LCD - they usually cant sync lower than 24 - 28kHz but they can accept frequencies even up to the 75 - 90kHz so after shorting lines i expect approx H Sync around 60 - 64kHz))

i know that copper is 8 low res pix fast - but im curious that using fast CPU for example - can we create something like 1 low res or even 1 hires directly putting data - or access to register can't be made more frequent than for example 1 CCK ( or 1/8 SYSCLK)

[Kalms]

With a fast CPU, you will be bottlenecked by the customchips. I don't know the exact max speed, but if I am to guess then the theoretical max speed for a CPU writing to COLOR00 is one write every 4 lowres pixels.

Not to leak onto your parade, but if you're contemplating using an A500 with a fat accelerator card and custom-made video capture hardware... perhaps it's time to reconsider your choice of base platform?