English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 14 May 2010, 21:12   #1
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,085
15 bit 44 khz audio idea.

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
Thorham is offline  
Old 14 May 2010, 23:08   #2
meega
Secret Lemonade Drinker
meega's Avatar
 
Join Date: Dec 2007
Location: Oooh what a feeling yeaaah dancing on the ceiling
Posts: 313
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).
meega is offline  
Old 15 May 2010, 20:31   #3
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 198
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.
Kalms is offline  
Old 16 May 2010, 12:18   #4
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,085
Quote:
Originally Posted by Kalms View Post
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
Quote:
Originally Posted by Kalms View Post
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.
Thorham is offline  
Old 07 June 2010, 18:53   #5
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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).
pandy71 is offline  
Old 09 June 2010, 15:50   #6
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,085
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.
Thorham is offline  
Old 12 June 2010, 02:11   #7
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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...
pandy71 is offline  
Old 12 June 2010, 10:13   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
Quote:
Originally Posted by pandy71 View Post
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

Quote:
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.
Toni Wilen is offline  
Old 12 June 2010, 12:19   #9
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
Quote:
Originally Posted by pandy71 View Post
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).

Quote:
- 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.

Quote:
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.

Quote:
- or maybe DMA is stopped so we have this limitation - 28867 instead 31250Hz
It's not stopped.

Quote:
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).
yaqube is offline  
Old 12 June 2010, 12:44   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
Quote:
Originally Posted by yaqube View Post
DMAL
Thanks, I thought it was something much more complex..

It is time to emulate this properly after 2.2 is out
Toni Wilen is offline  
Old 12 June 2010, 14:07   #11
absence
Registered User
 
Join Date: Mar 2009
Location: moon
Posts: 353
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?
absence is offline  
Old 12 June 2010, 16:23   #12
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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
pandy71 is offline  
Old 12 June 2010, 17:21   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,110
Quote:
Originally Posted by pandy71 View Post
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?)

Last edited by Toni Wilen; 12 June 2010 at 17:34.
Toni Wilen is offline  
Old 12 June 2010, 18:38   #14
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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?


--
Quote:
Originally Posted by Toni Wilen View Post
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?)

Last edited by pandy71; 13 June 2010 at 13:16.
pandy71 is offline  
Old 16 June 2010, 23:40   #15
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 16 June 2010, 23:45   #16
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
Quote:
Originally Posted by pandy71 View Post
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).
yaqube is offline  
Old 17 June 2010, 00:27   #17
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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
pandy71 is offline  
Old 17 June 2010, 12:41   #18
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 198
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.
Kalms is offline  
Old 17 June 2010, 23:58   #19
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,653
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)
pandy71 is offline  
Old 18 June 2010, 00:08   #20
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 198
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?
Kalms is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
High Quality reproduction of Audio on 8 bit. pandy71 Amiga scene 0 01 July 2013 16:08
Best Audio Config in Winuae for a Creative X-Fi Audio Card shaf support.WinUAE 2 14 June 2012 17:27
REQ: 17-Bit Artwork 2 (1988-04)(17-Bit Software) Sea7 request.Demos 5 13 May 2011 02:07
8 bit to optimized 6 bit palette histogram improvements needed NovaCoder Coders. General 0 14 April 2011 03:13
Simple 14 bit audio question... Thorham Coders. General 7 06 June 2010 11:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.12376 seconds with 14 queries