AUDxPER for maximum playback rate

[pandy71]

Originally Posted by 8bitbubsy

pandy71: Increasing the bandwidth of an 8-bit linear PCM signal will not increase the SNR (48dB for 8-bit linear PCM). It doesn't matter how good the original source was before quantizing it to 8-bit, or what kind of dithering technique you applied, you still end up with a maximum of 8 effective bits. Even if you were to compress the signal to always use as many effective bits as possible, you'd still easily be able to hear the quantization noise on certain waveforms (especially bass, sines etc) or quieter parts. It just isn't possible to overcome this issue on linear PCM, and dithering doesn't do magic when you have so few output bits.

Hope you are aware of the SACD, delta sigma modulators (foundation for more than 99% ADC/DAC in modern audio). Of course you can have 24 bit dynamics (and quality) from 8 bit PCM as you can have 24 bit dynamics (and quality) from 1 bit audio - only with 8 bit this is easier (as quantization noise is lower) and worse (as non ideal 8 bit conversion - but this may be overcomed significantly - there is plenty of 4, 5 bit delta sigma converters).
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

(c)
Finally, consider 8-bit, four-times-oversampled PCM with
noise shaping. This is also a data rate one-half that of DSD and
double that of CD, with a sampling rate of 4 × 44,100 =
176,400 Hz. It can achieve a noise floor 120 dB below full
scale up to 20 kHz, using 96 dB of noise shaping, and a total
noise power of –19 dBFS. Its frequency response would be
flat to 80 kHz. This example is perhaps the most instructive of
the lot. For a data rate one-half that of DSD, it achieves a
comparable signal bandwidth, with a similar noise power
density up to 20 kHz, but much lower power above this
frequency, and 28 dB lower total noise power. It is fully
TPDF-dithered, and so is completely artefact free. At one-half
the data rate it outperforms DSD on every count! DSD is a
profligate wastrel of capacity.

Originally Posted by 8bitbubsy

The reason the 14-bit trick works is because the Paula output really isn't 8-bit if you take the volume modulation into account.

There is many reasons why even after calibration 14 bit trick can't provide more than 12 bit, one of the reasons was even provided as oscilloscope picture (if i recall correctly by Toni Willen and/or by Bruce Abott) - PWM audio output from Paula in Amiga is not rectangle (squarewave) - it is rather distorted combo of the rectangle and sawtooth - that's why you can't have PWM linearity so never even close to 14 bit - after low pass filtering (reconstruction filter) 1/64 of PWM sample will be never 1/64 but probably less. Theoretically PWM is inherently linear but only if you can deal with true squarewave.
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).

[pandy71]

Originally Posted by ross

Off topic but interesting.

Many experiments have been done in this regard (and many more would have to be done...) but unfortunately it doesn't work as you say.
The bps you reported are 'just right', but only in an ideal world (for those interested: it is the base frequency of the cells that Paula uses as a reference when start the disk data sampling and initialize the counters [=CCK/7]).
But 'unfortunately' (or fortunately depending on who actually wants the discs to be read even if they are in bad condition) it is not passive when reading data, but adapts the sampling frequency to the state of the input stream.

It is not known what the precise 'algorithm' of this DPLL is, but it is certainly related to the quantity and the distance between the flux changes.
So these bps can also become CCK/6 or CCK/8, adaptively, for a short time and every now and then.

As you can imagine, this does not actually allow you to exceed the expected (MFM=50%) speed by much, otherwise synchronization is lost for certain data patterns
(some 0000.. or 11.. sequences could become different).

Once again - synchronization is required for asynchronous source but if you can feed data synchronously with clock then no need to recover clock and synchronize. At some point it will be serial to parallel conversion - PLL is used only to clock recovery and to synchronize - and MFM data decoding is done in software so all data need to be correct so instead encode MFM you can encode like blocks of data separated with some sequence header to satisfy PLL. And of course data can be scrambled to made them more PLL friendly (XOR with LFSR? - something easy to decode by 68K)

Originally Posted by ross

I didn't understand this step, can you elaborate?

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.

[ross]

Originally Posted by pandy71

Once again - synchronization is required for asynchronous source but if you can feed data synchronously with clock then no need to recover clock and synchronize. At some point it will be serial to parallel conversion - PLL is used only to clock recovery and to synchronize - and MFM data decoding is done in software so all data need to be correct so instead encode MFM you can encode like blocks of data separated with some sequence header to satisfy PLL. And of course data can be scrambled to made them more PLL friendly (XOR with LFSR? - something easy to decode by 68K)

There is not 'synchronous transfer' for disk data in Paula, the DPLL is always active.
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).
.

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.

Ah, ok

[pandy71]

Originally Posted by ross

There is not 'synchronous transfer' for disk data in Paula, the DPLL is always active.
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).

Well, everything in Paula is synchronous and this is not about magnetic storage but digital (flash) storage - to decode MFM in software Paula must convert from serial to parallel ALL bits - problems with RLL are related to analog part of floppy (check datasheet for analog floppy frontend - there is bandpass filter that ruin everything not being MFM or close enough to expected). But in this case we have digital data fed to serial/parallel converter and no bandpass filter.

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.

[meynaf]

Originally Posted by pandy71

But there is no hard coded limits so i can wait for ross work.

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

Originally Posted by pandy71

It will, dither linearize quantizer and oversampling increase dynamics.
plain dither (such as TPDF) is flat across whole band but you can use "color" dither similarly to noise shaping.

But up to the point you magically turn 8-bit into 16-bit without using huge frequencies ?
Nah. It would have been done in actual programs if this were possible.

Originally Posted by pandy71

Nope, this is more tricky - PWM is uneasy - Uniform PWM vs Non Uniform (Natural) PWM, slow OPAMP (to not distort signal, operating amplifier need to be capable to deal with 1.79MHz square wave with voltage around few volts - there is very limited number of such amplifiers - we talking about something like: 350-MHz Bandwidth (G = 10, –3 dB), 470-V/?s Slew Rate 40-ns Settling Time (0.1%) - excerpt from ths4022 datasheet).
Calibration can't address those problems - check thread about real dynamics for 14 bit audio - not even close to 14 bit - there is many problems that can't be solved by static calibration.

Most of these problems can't be heard. So while calibration does not solve everything, it still makes things 'good enough' (or at least 'better than what we had before').

Originally Posted by pandy71

But in Amiga RGA address define Read or Write not R/W line status. So you can "write" to "read" register - problem is of course OCS where CDANG restrict access to only RGA>DFF03E and in ECS/AGA you can increase HSync to overcome AUDxPER limitation with DMA.

Even if you get a read on the bus, it doesn't help with the fact the copper will be unable to catch the data...

Originally Posted by pandy71

But i can imagine bruteforce approach - sequence set by Copper.

Set AUDxLEN=1, AUDxDAT=X, Activate Audio DMA, - such sequence, regular pattern should create audio.

If you activate audio DMA, writes to AUDxDAT will be ignored.
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.

Originally Posted by pandy71

Same as "overscan" or "interlace" or 9 bit PCM in YM on Atari ST?

Not really.

Originally Posted by pandy71

This is quite easy to define - you can objectively (measurements) and subjectively (by listening) define HQ

What i meant is that this definition is arbitrary.

Originally Posted by pandy71

Floppy DMA is over 500kbps (precisely it is 506699.285714286 bps) and you don't need to encode MFM or similar as you can feed data synchronously with Amiga. Additionally you can use CIA to synchronize burst sequence - there is even more possibilities - plain Amiga is very neat on this (not sure about emulation).

Yes but this does not change what a normal, physical floppy drive can output.

Originally Posted by pandy71

And CD seem to be nice data source as 150KBps is suffcient to provide 2 channel, 8 bit PCM, 2 times oversampled (AUDxPER = 65 or better 64)

But you'll have a hard time accessing CD outside of OS (xcept maybe on a CD32).
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.

[ross]

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

[8bitbubsy]

Originally Posted by pandy71

Hope you are aware of the SACD, delta sigma modulators (foundation for more than 99% ADC/DAC in modern audio).

Yes, and that's why I specifically stated 8-bit linear PCM, which is what Paula uses. Using 1-bit non-PCM techniques is not going to be feasible because of the low ~29kHz/~55kHz DMA limits. And if you were to do it another way, you would still need a reconstruction filter, as far as I know.

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.

[pandy71]

Originally Posted by meynaf

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

On Amiga there is many things never done - to be honest - lot of functionality is implemented in HW and Amiga developers opposite to Atari ST ones simply don't need do anything...
Luxury usually spoiling people... poverty usually force people to be creative and clever...

Originally Posted by meynaf

But up to the point you magically turn 8-bit into 16-bit without using huge frequencies ?
Nah. It would have been done in actual programs if this were possible.

It can be done easily with for example SoX:

@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

Originally Posted by meynaf

Most of these problems can't be heard. So while calibration does not solve everything, it still makes things 'good enough' (or at least 'better than what we had before').

Well... length of the few threads dedicated to 14 bit audio shows something else...

Originally Posted by meynaf

Even if you get a read on the bus, it doesn't help with the fact the copper will be unable to catch the data...

It was just idea, probably stupid.

Originally Posted by meynaf

If you activate audio DMA, writes to AUDxDAT will be ignored.
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.

Same as above - just idea... probably stupid.

Originally Posted by meynaf

Not really.

If you say so...

Originally Posted by meynaf

What i meant is that this definition is arbitrary.

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

Originally Posted by meynaf

Yes but this does not change what a normal, physical floppy drive can output.

lol... magnetic floppies are fine but floppy emulation is more convenient...

Originally Posted by meynaf

But you'll have a hard time accessing CD outside of OS (xcept maybe on a CD32).
Besides, you're no longer in the case of unexpanded A500 (and CD drives aren't exactly as common as they used to be).

yes, but... having nice HW make people ...

Originally Posted by meynaf

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.

OS friendly way assume DMA and productivity or similar increased horizontal frequency video mode, Copper audio can be useful on OCS/ICS where productivity is not possible by HW (but no one tried to for example reduce length of video line and as such increase horizontal frequency - perhaps with help of Copper).

Coding of 8 bit PCM will stay same so independent from playing strategy.

[pandy71]

Originally Posted by ross

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

not at all - like to read technical discussions - but once again - perhaps you are right, me not - fine, issue is that Paula need to be able to sample correctly MFM coded bitstream and provide it in track buffer to be decoded from RAW MFM to data (500 vs 250kbps) - floppy make this process difficult due magnetic limitations, mechanical limitations - you need recover clock from MFM as your bitstream speed changing (floppy rotate but even with flywheel there are fluctuations so overall speed may be inaccurate, random, speed between different floppy drives etc).

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

[pandy71]

Originally Posted by 8bitbubsy

Yes, and that's why I specifically stated 8-bit linear PCM, which is what Paula uses. Using 1-bit non-PCM techniques is not going to be feasible because of the low ~29kHz/~55kHz DMA limits. And if you were to do it another way, you would still need a reconstruction filter, as far as I know.

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.

You can prepare such samples by your self - already provided SoX batch to prepare 2 times oversampled 8 bit pcm with noise shaping, as script trying to push used levels to maximum then there is normalization (up to -1.7dBFS) - this is to make headroom for noise shaping - this mean that every signal will be normalize so you can't feed for example -90dBFS 4 kHz sine wave, you need to add for example second tone beyond audible range for example 23kHz and very high level - lets say for example -3dBFS.

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)

@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

You can use this stimulus as source for batch to prepare 8svx files.

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) - :

[ross]

Originally Posted by pandy71

..(but no one tried to for example reduce length of video line and as such increase horizontal frequency - perhaps with help of Copper).

This is probably even more complex than Copper Audio because in this case the copper can only be used as an indirect aid
(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

[8bitbubsy]

Originally Posted by pandy71

You can prepare such samples by your self - already provided SoX batch to prepare 2 times oversampled 8 bit pcm with noise shaping, as script trying to push used levels to maximum then there is normalization (up to -1.7dBFS) - this is to make headroom for noise shaping - this mean that every signal will be normalize so you can't feed for example -90dBFS 4 kHz sine wave, you need to add for example second tone beyond audible range for example 23kHz and very high level - lets say for example -3dBFS.

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)

@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

You can use this stimulus as source for batch to prepare 8svx files.

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) - :

Can you attach that sample?

[pandy71]

Originally Posted by 8bitbubsy

Can you attach that sample?

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.

[pandy71]

Originally Posted by ross

This is probably even more complex than Copper Audio because in this case the copper can only be used as an indirect aid
(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

Well... if ST can do this: https://atari.8bitchip.info/movpst.php then perhaps OCS "productivity" is also possible?

[QuikSanz]

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

[meynaf]

Originally Posted by pandy71

It can be done easily with for example SoX:
<snip>

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).

Originally Posted by pandy71

Well... length of the few threads dedicated to 14 bit audio shows something else...

No better solution has been proposed.

Originally Posted by pandy71

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

You will always find someone who does not agree...

Originally Posted by pandy71

lol... magnetic floppies are fine but floppy emulation is more convenient...

The point is that if expanding the machine is allowed, we have better solutions than copper audio.

Originally Posted by pandy71

OS friendly way assume DMA and productivity or similar increased horizontal frequency video mode, Copper audio can be useful on OCS/ICS where productivity is not possible by HW (but no one tried to for example reduce length of video line and as such increase horizontal frequency - perhaps with help of Copper).

Increasing audio DMA limits isn't copper audio, even if done with copper
It will also not solve the main problem : where does that data we play come from if we can't access hd ?

[8bitbubsy]

Originally Posted by pandy71

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.

I can't even hear any sine. Now try this on a low-pitch single-tone sine.

How about this one? https://www.dropbox.com/s/gvahglpihn...sine.flac?dl=1
16-bit 96kHz, 50Hz sine wave.

[pandy71]

Originally Posted by 8bitbubsy

I can't even hear any sine. Now try this on a low-pitch single-tone sine.

How about this one? https://www.dropbox.com/s/gvahglpihn...sine.flac?dl=1
16-bit 96kHz, 50Hz sine wave.

Try but what? I hear 4kHz tone... if you not hearing 4kHz tone then perhaps you can record audio and analyse it offline on for example PC?

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)

[pandy71]

Originally Posted by meynaf

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).

i trust SoX - it can deliver over 25 bit precision - more is necessary for UHQ audio.

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.

Originally Posted by meynaf

No better solution has been proposed.

Fair point and i don't argue - probably this is beast real time trick.

Originally Posted by meynaf

You will always find someone who does not agree...

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

Originally Posted by meynaf

The point is that if expanding the machine is allowed, we have better solutions than copper audio.

perhaps yes... but why not try something not practical? and i don't agree that using gotek or similar solution is expanding - not per se rather this is creating way to replace no longer produced floppies - same issue for not only retor computing but also for example CNC machines (some of them are being use constantly for 30..40 years without problems - only problem is floppy drive and floppy disks)

Originally Posted by meynaf

Increasing audio DMA limits isn't copper audio, even if done with copper
It will also not solve the main problem : where does that data we play come from if we can't access hd ?

Why not? If you can bend DMA to work for you then it is fine - this way or another one to create stable audio is OK (i know - we can use CPU to feed AUDxDAT).

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?

[pandy71]

Originally Posted by QuikSanz

A better tuned DAC filter would be lots of help for sure

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.