14 April 2023, 23:27 | #81 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Btw few messages earlier i've attached spectrogram showing of 96dBFS (16 bit) at 1kHz and 11..13 bits up to 18..19kHz from 8 bit PCM only at 2 times oversampling. Please allow me to quote: https://sjeng.org/ftp/SACD.pdf Quote:
Quote:
To get 14 bit you should probably perform calibration offline (verifying each possible DAC+PWM state, best dynamically, best in wide temp range) and build dedicated fancy encoder not crude 16 to 14 bit conversion. Going for faster OPAMP (to be not overloaded by PWM) probably will help unless Paula itself is problem (insufficient current output capability). |
|||
14 April 2023, 23:46 | #82 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
You have CIA used to control many aspects of floppy communication by GPIO - but using something like Gotek you are no longer tied with floppy interface - interpretation of those signals is up to you - for example SEL0..SEL3 can be considered as 4 bit I/O so you can add logic and decode 4 to 16 or 3 to 8 etc, INDEX can trig communication etc. |
|
15 April 2023, 00:06 | #83 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Quote:
So not ohly for header/sync data, but for the full stream. It try to handle every time a flux, even if it is not. It's the same reason why even a Gotek can't outspeed a DD drive, even though it theoretically could. But always happy to be proven wrong, maybe a possibility to overcome this limit exists About the 'scramble' part: yes, you can gain something, but not much. We experimented and a near to full RLL(1,3) channel capacity is achievable from a floppy, but seems that Paula can easily accept even a full RLL(1,4). . Quote:
|
||
15 April 2023, 00:19 | #84 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Btw - forgot to add - how GCR mode works in Paula? - isn't Paula intentionally differentiate MFM mode from GCR mode by introducing such bit - i agree - it is not covered by HRM and floppy part seem to be most underspecified one. I would be happy to try at least - but first need to finish my home so i can bring my Amiga's from storage. Last edited by pandy71; 15 April 2023 at 09:14. |
|
15 April 2023, 10:04 | #85 | ||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Ask yourself why it hasn't been done already. Perhaps there is a hard coded limit that we didn't think about.
Many things are doable on the paper but have never been done for whatever reason. Some will be done, some will not. So maybe this one will, but maybe it will not. A blind belief in either case, isn't very clever. So yes if someone can do this then it is ross. But if he doesn't, then... Quote:
Nah. It would have been done in actual programs if this were possible. Quote:
Quote:
Quote:
At least, this is what my tests have shown : writing to audio data while dma is active, seems to have no effect. I couldn't perform strict checks, but i'm not optimistic for mixed accesses. Quote:
Quote:
Quote:
Quote:
Besides, you're no longer in the case of unexpanded A500 (and CD drives aren't exactly as common as they used to be). I remember having been able to play 44.1 8-bit (with period=80) on my A1200/030 many years ago (on a PAL display, that is). Going over 28khz isn't the problem. The main problem is being able to do that while OS is still running, otherwise it will not be useful for anything : demos don't need extra audio quality (especially if it eats memory and disk space) and music player programs aren't very user friendly without multitasking... I think that a very good (and fast enough) resampling algorithm so we remain in DMA limits, would be more useful than all these copper audio attempts. |
||||||||
15 April 2023, 12:16 | #86 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Another (long..) off-topic message about the transfer to the floppy port, but not much off-topic because we always talk about Paula
I remain of the opinion that pandy71's solution cannot work because it provides a synchronous approach, with a fixed clock, which Paula tolerates only if within the expected 'MFM-like' specifications. Obviously he can be absolutely right, we have to do experiments "without a floppy device" and I don't have the possibility. But let's try to overturn the reasoning: why not supply Paula with a quasi-asynchronous stream, one that 'fool' the DPLL? Let me explain. Let's neglect the initial synchronism for now, it's not significant at the moment and we can somehow tie it to the INDEX signal (but in any case I think it's very simple in Paula and it's definitely related to an initial phase lock: continuous sampling per CCK until the flux change [1 value detection] -> half cell time counter [3xCCK] -> locked phase -> base counter start [7xCCK]). For analog PLL, in communications, the oscillator is usually at the receiver, and the reference signal is extracted from the signal received from the remote transmitter. Something similar for Digital PLL, where the receiver consist of a serial shift register which receives digital input samples (extracted from the received signal): a stable local clock signal supplies clock pulses to the shift register to drive it and a phase corrector circuit to 'regenerate' the clock by slowly adjusting to match the received signal. If the sampled signal shows a transition 'at the centre' of the bit, the clock is already aligned. If the transition appears to the right of centre, the clock period is too long, and the frequency is increased. If the transition appears to the left, the period must be too short, so the frequency is decreased. Since we are in the discrete field, the clock correction is performed using a reference frequency that is a multiple of the sampling frequency (usually >=x8, to help the 'binary math'). For Paula we are not so fortunate to have a minimum ratio of 1:8 between c:f but 1:7, which in any case is 'enough' good and gives valuable results. So: reference clock -> CCK, reference sampling -> 7xCCK. The DPLL can slow down to CCKx8 or accelerate to CCKx6 based on detected [1] canges in the flux (i.e. 'stream' in our raw tranfer case). This can be done simply with a down counter and trigger, Paula already has them galore inside. {Caveat: these are just my thoughts on how Paula might work, it might be similar or completely different, it's just how I would do it if I had to, based on existing appliances } Returning to the point: instead of supplying a synchronous stream as input, a 'dynamic' one is supplied which changes the bit frequency according to the pattern sent and which causes the DPLL to change the counter period but to be anyway recognized (because it is congruent with the new frequency that Paula assumes has the stream). This of course involves knowing how and when Paula changes the value for the counter (and therefore the sampling frequency for the input shifter). Otherwise with a synchronous stream it is inevitable that, having a fixed distance between the [1] bits in the stream, it make Paula 'corrupting' the signal. I hope I haven't bored you and that what I wrote makes sense, basically are free thoughts, take it with a grain of salt |
15 April 2023, 13:50 | #87 | |
Registered User
Join Date: Sep 2009
Location: Norway
Posts: 1,711
|
Quote:
Anyway: you simply can't get rid of the quantization noise by increasing the frequency and using dithering before converting to 8-bit linear PCM. You can somewhat improve it, but it will always be there. Sometimes less audible, depending on the actual frequency content in the sample. If you are still convinced it's possible, feel free to create a magic 8-bit linear PCM sine sample that is free of audible noise. Last edited by 8bitbubsy; 15 April 2023 at 14:18. |
|
15 April 2023, 22:38 | #88 | ||||||||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Luxury usually spoiling people... poverty usually force people to be creative and clever... Quote:
Code:
@setlocal @REM Where to Find SoX @set SoX=C:\sox @set PATH=%PATH%;%SoX% @set PAL=28375160 @set NTSC=28636363 @rem Paula PAL=3546895 @rem Paula NTSC=3579545.45454545 @rem SET CLK=28375160 @rem LowPassFilter F= @rem Amiga 500/2000: 4.42 kHz (100 nF, 360 ?) @rem A600: 4.42 kHz (100 nF, 360 ?)11 @rem A1200 Rev1d: 27.7 kHz (3.9 nF, 1.5 k?) @rem A1200 Rev2: 34.4 kHz (6.8 nF, 680 ?) @rem A4000: 4.52 kHz (47 nF, 750 ?) @SET LPF=4420 @rem lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata @set noiseshp=improved-e-weighted @rem period accurate freq PAL 64:55420.23 ; 65:54567.62 @SET /a CLK=%PAL%/8 @rem SET PERIOD=124 @SET PERIOD=65 @SET /a AFREQ_I = (((100*%CLK%)/(1*%PERIOD%))+1) / 100 @SET /a AFREQ_F = (((100*%CLK%)/(1*%PERIOD%))+1) %% 100 @SET AFREQ=%AFREQ_I%.%AFREQ_F% @SET /a APREC_I = (((100*%CLK%)/(4*%PERIOD%))) / 100 @SET /a APREC_F = (((100*%CLK%)/(4*%PERIOD%))) %% 100 @SET APREC=%APREC_I%.%APREC_F% @SET file=%1 @SET fname=%~n1 @ECHO Samplerate=%AFREQ% @ECHO Precompensation=%APREC% @ECHO file=%file% @ECHO filename=%fname% @ECHO %LPF% @SET aproc= @rem SET aproc=compand 0.25,1 6:-inf,-90.1,-inf,-90,-75,-70,-70 -3.0103 -90 0.20 treble +6.0206 %LPF% .5 treble +6.0206 %APREC% .5 treble +6.0206 18000 .5 @rem SET aproc=treble +6.0206 %LPF% .5 treble +6.0206 %APREC% .5 treble +6.0206 18000 .5 @rem SET aproc=treble +6.0206 %LPF% .5 treble +6.0206 %APREC% .5 @rem SET aproc=treble +12.0412 %LPF% .5 @sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V4 -D -G %file% -t s32 "%fname%.s32" remix - rate -v -s -I %AFREQ% %aproc% stats -b 8 stat @sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r 48299 -e signed-integer -b 32 -t s32 "%fname%.s32" -c 1 -b 8 -e signed-integer -t s8 "%fname%.s8" gain -n -1.769537 dither -f %noiseshp% -p 8 stats -b 8 stat @sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -b 8 -e signed-integer -t s8 "%fname%.s8" "%fname%.8svx" @sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -e signed-integer -b 32 -t s32 "%fname%.s32" -n spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_32.png" @sox --multi-threaded --buffer 524288 --input-buffer 524288 -S -V6 -D -c 1 -r %AFREQ% -e signed-integer -b 8 -t s8 "%fname%.s8" -n spectrogram -z 96 -q 13 -w Kaiser -y 513 -x 496 -o "%fname%_8.png" @del -q "%fname%.s32" @del -q "%fname%.s8" @endlocal @pause Quote:
Quote:
Quote:
If you say so... Common - most of us has some life experience, we was exposed to various audio reproduction technologies and in average can have some consensus... 60..66dB SNR is threshold between HQ and not... Quote:
Quote:
Quote:
Coding of 8 bit PCM will stay same so independent from playing strategy. Last edited by pandy71; 15 April 2023 at 23:02. |
||||||||
15 April 2023, 22:49 | #89 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
My case is just bitstream without fluctuations, also there is question how GCR bit affect described by you DPLL logic - as Paula don't decode data then it must be something behind... |
|
15 April 2023, 23:02 | #90 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Such two tone signal should be fine for testing - as i have no access to Amiga HW then i use PC and i can hear -90dBFS (approx -93dBFS) 4kHz sine in headphones on my notebook (but to be honest it is not the best PC audio i've ever heard - there is lot of PC noise) Code:
@set rate=48000 @set time=10 @sox --multi-threaded --buffer 131072 -S -V -D -r %rate% -c 2 -n IMD_c_%rate%.wav synth %time% sine 4000 gain -n -90 synth %time% sine mix 23000 gain -n -3.010299957 dither -S -p 24 stat stats -b 24 @pause At the end you should get something like this (this is FFT from 8 bit 8svx file i've created few moments ago - period 65 i.e. sample rate is 54567.62Hz, 8svx shows as 54568Hz sample rate) - : Last edited by pandy71; 15 April 2023 at 23:24. |
|
16 April 2023, 00:12 | #91 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Quote:
(for example to fire an IRQ that uses the CPU to shorten lines). Another problem could be the whole vsync phase: you have to think carefully how to behave because on OCS every signal is mainly hardwired, there is the high risk to make something that works only in some devices (or at all). And more, since you have to be cycle exact it would only work with the 68000 at 7MHz.. It's probably not impossible but we're very close. ECS exist basically for this very reason |
|
16 April 2023, 15:01 | #92 | |
Registered User
Join Date: Sep 2009
Location: Norway
Posts: 1,711
|
Quote:
|
|
16 April 2023, 19:32 | #93 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Generated new one for you - accordingly to Audition 4000Hz sine level is over -89dBFS (so it is more than 14 bit - approx 14.5 bit).
btw - quite important is that designing optimal from Amiga perspective noise shaping filter can deliver even better results. Last edited by pandy71; 16 April 2023 at 22:28. |
16 April 2023, 22:56 | #94 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
|
|
16 April 2023, 23:16 | #95 |
Registered User
Join Date: May 2021
Location: Los Angeles / USA
Posts: 135
|
This may be helpful, not sure. The Kipper2K/Nonarkitten project,
What could be done with Willoe and Harmonie (A500/A2000/A3000): - Paula 2x and 4x audio and disk speeds - Support for HD floppy speeds (60kbps) - Support for either 112kHz 8-bit or 56kHz 16-bit audio A better tuned DAC filter would be lots of help for sure Last edited by QuikSanz; 16 April 2023 at 23:18. Reason: more info |
17 April 2023, 09:00 | #96 | ||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
But SoX will still reduce quality.
You also need to prepare your samples in advance, it's not useful for real time playback (i.e. for normal audio player program). Quote:
Quote:
Quote:
Quote:
It will also not solve the main problem : where does that data we play come from if we can't access hd ? |
||||
17 April 2023, 15:28 | #97 | |
Registered User
Join Date: Sep 2009
Location: Norway
Posts: 1,711
|
Quote:
How about this one? https://www.dropbox.com/s/gvahglpihn...sine.flac?dl=1 16-bit 96kHz, 50Hz sine wave. Last edited by 8bitbubsy; 17 April 2023 at 15:36. |
|
17 April 2023, 20:06 | #98 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
It is not problem in sampling rate - can generate even MHz range sample rates - it about levels and Paula reproduction capability. If i can measure (FFT) tone then tone exist - you may not hear tone due lowpass filter activity (-89dBFS is really low so even 3dB attenuation introduced by LPF can prevent to hear and on generic Amiga it may be buried in overall noise floor). 50Hz is quite suboptimal choice - i expect lot of 50Hz interference from power supply in Amiga (you and i living in 50Hz countries, poor grounding - ground loop - may significantly impact results - i can generate for you something else - subsonic 0.2Hz - single period, almost full scale(-2.99dBFS) and 4kHz tone (at -86.79dBFS) we can only hope that 0.2Hz will not overload OPAMP easily as 23kHz tone) |
|
17 April 2023, 20:29 | #99 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Preparation is anyway required also for 14 bit trick - it can be done on the fly but with limited success only. Perhaps some multiplierless (adds + shifts) implementation can be created, also enhanced blitter could offer such conversion in HW block. For sure plain 68000 will be probably too slow for real time. Fair point and i don't argue - probably this is beast real time trick. Well... you can always find people claiming that audiophile power socket golden plated (bargain just 43$ - https://www.amazon.com/Monosaudio-Au.../dp/B087TRMCDR ) substantially improved sound panarama even if power cabling in home was done with aluminum wires... Look at those guys - they are very serious on this https://forum.audiogon.com/discussio...ile-ac-outlets Quote:
Quote:
Well - you can create miniOS or perhaps you can create this in OS friendly way - or you can create code with low level HDD read (at least for embedded HDD interface). Why not, if you can emulate Macintosh or ST then why not? |
|||
17 April 2023, 20:37 | #100 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
It is about passive DAC filter to remove MHz from relatively slow OPAMP input.
Nonarkitten/Kipper2K project will be different than Paula in terms of DAC so probably also they can offer true 14 bit mode without calibration (similarly to WinUAE where 8 bit is multiplied by 6 bit so you have perfect 14 bit). It would be nice to get ADPCM HW decoder in improved Paula - this could give some boost to 16 bit and higher sample rates without pushing too much on other resources. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"EaglePlayer" playback VS "real" playback | chip | support.Other | 31 | 27 September 2020 13:14 |
winuae 3.4.0 - cd playback | honx | support.WinUAE | 10 | 26 February 2017 00:00 |
XBox 1 video playback | Peter | Retrogaming General Discussion | 19 | 18 January 2011 16:33 |
Q: recording 4-channels sound output and "Playback Rate" | jbl007 | support.WinUAE | 0 | 07 June 2005 18:23 |
DivX Playback | Echo | support.Hardware | 10 | 24 January 2003 18:45 |
|
|