29 January 2016, 16:46 | #161 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,884
|
Quote:
But i see no need for this as sampled data require only accurate clock - you can perfectly represent sine 997Hz or sine 1001Hz on Amiga. Of course there are some tricks in DSP to speed up some things (in sample rate conversion common is CIC https://en.wikipedia.org/wiki/Cascad...%93comb_filter that doesn't require mutiplication) but still Amiga CPU and Amiga architecture are not capable to perform such thing - this can be made by switching whole Amiga idea to FPGA but this will not happen soon... |
|
29 January 2016, 20:55 | #162 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
To give an example, if you decide to use the period 216 for the note C, you can get various integer ratios out of that. For instance D=192 (9:8), F=162 (4:3), G=144 ( 3:2), but you can't get E (5:4), A (5:3) or B (15:8) because 216 is not divisible by 5 or 15.
So suppose you choose 215 instead, which is divisible by 5, so you can get E=172 and A=129, but still not B, and worse, you can no longer get D, F, or G, because 215 is not divisible by 8, 3 or 2. (Usually in Amiga period tables, C has a period of 214, which is even worse, because it only has two factors, 2 and 107, and the only ratio that gets you is the octave, but it's too high a note for Paula to play.) Quote:
PAL: 3546895 / (frequency * length) NTSC: 3579545 / (frequency * length) These don't have very many prime factors: 3546895 = 5 x 11 x 64489 3579545 = 2 x 3 x 41 x 14551 1001 = 7 x 11 x 13 and 997 is prime... so neither of these frequencies is exactly possible with any combination of period and length, either on NTSC or PAL. |
|
29 January 2016, 21:35 | #163 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,884
|
Quote:
Code:
0078 120 29557.458333 29829.541667 14778.729167 14914.770833 0079 121 29313.181818 29583.016529 14656.590909 14791.508264 007A 122 29072.909836 29340.532787 14536.454918 14670.266393 007B 123 28836.544715 29101.991870 14418.272358 14550.995935 007C 124 28603.991935 28867.298387 14301.995968 14433.649194 007D 125 28375.160000 28636.360000 14187.580000 14318.180000 007E 126 28149.960317 28409.087302 14074.980159 14204.543651 007F 127 27928.307087 28185.393701 13964.153543 14092.696850 0080 128 27710.117188 27965.195313 13855.058594 13982.597656 0081 129 27495.310078 27748.410853 13747.655039 13874.205426 0082 130 27283.807692 27534.961538 13641.903846 13767.480769 0083 131 27075.534351 27324.770992 13537.767176 13662.385496 0084 132 26870.416667 27117.765152 13435.208333 13558.882576 0085 133 26668.383459 26913.872180 13334.191729 13456.936090 0086 134 26469.365672 26713.022388 13234.682836 13356.511194 0087 135 26273.296296 26515.148148 13136.648148 13257.574074 0088 136 26080.110294 26320.183824 13040.055147 13160.091912 0089 137 25889.744526 26128.065693 12944.872263 13064.032847 008A 138 25702.137681 25938.731884 12851.068841 12969.365942 008B 139 25517.230216 25752.122302 12758.615108 12876.061151 008C 140 25334.964286 25568.178571 12667.482143 12784.089286 008D 141 25155.283688 25386.843972 12577.641844 12693.421986 008E 142 24978.133803 25208.063380 12489.066901 12604.031690 008F 143 24803.461538 25031.783217 12401.730769 12515.891608 0090 144 24631.215278 24857.951389 12315.607639 12428.975694 0091 145 24461.344828 24686.517241 12230.672414 12343.258621 0092 146 24293.801370 24517.431507 12146.900685 12258.715753 0093 147 24128.537415 24350.646259 12064.268707 12175.323129 0094 148 23965.506757 24186.114865 11982.753378 12093.057432 0095 149 23804.664430 24023.791946 11902.332215 12011.895973 0096 150 23645.966667 23863.633333 11822.983333 11931.816667 0097 151 23489.370861 23705.596026 11744.685430 11852.798013 0098 152 23334.835526 23549.638158 11667.417763 11774.819079 0099 153 23182.320261 23395.718954 11591.160131 11697.859477 009A 154 23031.785714 23243.798701 11515.892857 11621.899351 009B 155 22883.193548 23093.838710 11441.596774 11546.919355 009C 156 22736.506410 22945.801282 11368.253205 11472.900641 009D 157 22591.687898 22799.649682 11295.843949 11399.824841 009E 158 22448.702532 22655.348101 11224.351266 11327.674051 009F 159 22307.515723 22512.861635 11153.757862 11256.430818 00A0 160 22168.093750 22372.156250 11084.046875 11186.078125 00A1 161 22030.403727 22233.198758 11015.201863 11116.599379 00A2 162 21894.413580 22095.956790 10947.206790 11047.978395 00A3 163 21760.092025 21960.398773 10880.046012 10980.199387 If you sample sine 997Hz with for example 28603.991935Hz sample rate then this sine will be 997Hz during replaying it with sample rate 28603.991935Hz - there can be any frequency between DC and 14301.995968Hz - this is simple, on other way when you replaying sine with sample rate different than sampling rate then sine frequency will be shifted by ratio between sampling rate and playback rate. Your remark was related to accuracy or rather frequency resolution for set-able play-out rate of Paula. As Paula is equipped with very simple frequency generator then delta between two nearest values depend from period value (higher period value i.e. lower sampling rate mean higher frequency resolution) and usually is lower than +-122Hz (approx). In theory at a cost of jitter you may introduce finer frequency resolution - not sure how it can sounds (i assume it can be described by Bessel function). This can be verified by hooking to Amiga audio output a PC audio card input and record signal (and perform on sampled signal spectral analysis). Anyway by switching AUDxPER value for every sample (in Amiga case sample pair i assume will be easier as Copper can be used or CPU) a finer frequency resolution can be reached (this assumption is fair if we have sufficient time). Alternatively maybe HW Paula capabilities can be used (4 byte period table and use one channel to modulate second but this reduce speed by half ). I assume improved Paula may use NCO http://en.wikipedia.org/wiki/Numeric...led_oscillator instead simple divider and as such significantly higher frequency resolution can be reached (also constant delta limited only by Phase Accumulator accuracy - usually fraction of Hz) - compatibility can be achieved by using LUT (when classical AUDxPER access is used). Last edited by pandy71; 29 January 2016 at 21:41. |
|
29 January 2016, 22:14 | #165 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
But this is of course an academic argument because no normal person will hear the difference. Although someone very pedantic might want to take it into account when writing an emulator. Although it is possible to hear a difference in quality between the same chord in different tuning systems. And it is not for nothing that so many different systems exist! Last edited by Mrs Beanbag; 29 January 2016 at 22:38. |
|
29 January 2016, 23:33 | #166 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
I don't know if it would be practical for something like a fully compatible module player but for e.g. sound effects and/or music with some limitations it is obviously usable. |
|
30 January 2016, 01:28 | #167 | ||||
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
Quote:
Quote:
But just so that you can't claim I'm only talking how about something a bit different: Code:
; unrolled loop ... move.b (a0, d0.w), d1 ; fetch sample move.w (a1)+, d0 ; fetch next offset from table move.w (a2, d1.w), d2 ; apply volume ... add.w d2, (a3)+ ; mix into buffer Quote:
I get the impression we are somehow talking past each other... |
||||
30 January 2016, 10:53 | #168 |
Registered User
Join Date: Jan 2016
Location: Knivsta / Sweden
Posts: 20
|
Am I missing something basic here, or shouldn't those two last instructions operate on bytes instead of words?
|
30 January 2016, 12:16 | #169 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
About doing things faster, has the gain been quantified ? I asked Drhex to produce code because this is the best way to see if something can work or not. I posted code so that we have some reference to compare with. Now what ? Quote:
Because there is actually no problem at hand. Mixing for the mere sake of mixing is useless ; we should be doing that for a specific application. Usually the best optimizations take into account for which application we're doing the stuff... For games the classical 3mus+1sfx (or 2mus+2sfx, some games do this) are the best bet. Mixed music (like tfmx 7v) are for menus. SFX are usually of a single period, btw. For a music player targeting formats like protracker, no trick will do : we need to have the ability to mix anything. So i still fail to see any application that can use this frequency limitation trick. Maybe here the talk is purely academic, but in that case i'll just leave because that doesn't interest me. That's very possible. |
||
30 January 2016, 12:17 | #170 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
|
30 January 2016, 13:29 | #171 |
Registered User
Join Date: Jan 2016
Location: Knivsta / Sweden
Posts: 20
|
|
30 January 2016, 13:48 | #172 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
One could multiply d1 by 2 before the access. On 68000 this kinda sucks. On 020+ we can write move.w (a2,d1.w*2),d2 instead. |
|
30 January 2016, 14:32 | #173 |
Registered User
Join Date: Jan 2016
Location: Knivsta / Sweden
Posts: 20
|
Getting a little off topic here, but I just thought of a way to make that lookup suck a little less on 68000. To fix the code you'd need a moveq #0,d1 at the beginning to clear out the overflow from the previous doubling, and an add.w d1,d1 to fix the index.
Let's say the loop is unrolled 4 times. Then, one could have the moveq in only the first copy, and compensate by having 8 copies of the lookuptable at consecutive adresses. Always fun to trade ram for speed |
30 January 2016, 14:40 | #174 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,884
|
Quote:
From my observations it quite clear that people ignore this Amiga uniqueness and they try to use for example samples from different audio hw with bad sample rates - classical example is 22050Hz i.e. half of the 44100Hz - perfectly working in PC world but completely wrong in Amiga world where 22050Hz can't be correctly set and you must use 22030.403727Hz so sample rate conversion must be integral part for using PC sample on Amiga. |
|
30 January 2016, 20:19 | #175 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
It is not the absolute frequency of a note that matters, only the ratio between the different notes that you want your playroutine to be able to reproduce. Unless you want a different sample for each note on the scale, you will have to be content with an approximation because Paula's period register is an integer value, and all software resampling code mentioned so far also uses an integer value. In fact irrational ratios such as square root of two is impossible on any computer ever, because it has infinite number of digits and can never be computed exactly in the lifetime of the universe. |
|
30 January 2016, 21:12 | #176 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
Well one can use the same technique for 8 bit mixing instead and avoid that :/ Or mixing 3 channels at a time to lower the lookup overheads. Doing a 8bit lookup and a 16bit add is of course possible too but then the whole idea of keeping the mixing buffer at a higher precision makes no sense. |
|
30 January 2016, 21:17 | #177 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
|
|
30 January 2016, 21:41 | #178 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Watch me call a floating point number an integer! A fixed point number is only non-integer on a semantic technicality... there is no actual point in the hardware or the asm. It's just integer arithmetic but shifted. But... the point is, that any integer, fixed point, or floating point number of finite precision, can only approximate irrational numbers, or most rational numbers.
Quote:
|
|
31 January 2016, 00:03 | #179 | ||
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
Quote:
|
||
31 January 2016, 00:54 | #180 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
|
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sound channels switched? | bLAZER | support.WinUAE | 21 | 28 October 2014 08:43 |
A600: missing sound channels | cosam | support.Hardware | 28 | 23 May 2010 06:43 |
More that 4 Sound Channels??? | Dragon3d | support.WinUAE | 8 | 01 February 2008 17:30 |
shufflepuck cafe 4 channels sound is crazy | turrican3 | support.WinUAE | 5 | 08 November 2007 15:41 |
help sound 4 channels | turrican3 | support.WinUAE | 37 | 13 April 2007 09:17 |
|
|