Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: paul1981 on October 08, 2012, 11:08:30 PM
-
I'm going to downsample some of my audio cd's so that I can play them in 14-bit on my Amiga's through Paula in PAL mode (approx 28.8KHz).
I've read conflicting reports scattered throughout the web as to the precise maximum sample rate that is supported under PAL. Some say the limit is 28837 for PAL, with the 28867 limit being for NTSC. Others say that the limit is 28867Hz for PAL and NTSC. Personally, the former seems to make more sense to me. It's only 30Hz difference I know, but I'd like to know the correct answer anyway!
Question number 2: Should the answer be, for instance, 28837, will the playback program (such as HippoPlayer/EaglePlayer/Songplayer/AHI) use that absolute precise playback rate?
Thanks...
-
Hiya,
I'm about to do the same thing (well it's on my very long todo list at any rate).
I'm going to use http://www.exactaudiocopy.de/ (http://www.exactaudiocopy.de/) rip my CD's to 22050Hz MP3's with the least compression.
Then play them back using AHI (v4.81) using Paula 14bit stereo++ FAST
I'm currently playing back MP3's with a 44k sample rate, that worked well when I was running in VGA mode but now that I've switched to PAL I need to lower the rate.
-
If you intend to adhere to some sort of standard, then 24 KHz MP3's would probably be your best bet.
If you're compressing them into a format that allows custom sample rates, then go for 28837 Hz.
Edit: Re-read the question. Max. sample rate for a PAL Miggy is 28837 AFAIR. I haven't tried to play such files in Hippoplayer, but the sampling program I used back in the days (Perfect sound) had no problems playing such files.
-
I have played countless samples over the years in PAL mode and I can tell you that 28Khz is not reliable. I don't care what the documentation says. The samples play correctly sometimes and sometimes not. Its weird.
I would stick to 27Khz or less to be 100% safe.
I think the unreliability may be related to the screenmode that is currently being displayed at that exact second.
-
Thanks for replies. Still no absolute definitive answer, but I'll go with my instinct with 28837 Hz.
I've played many samples over the years as well, and the only time I had unreliable sample playback was when using AMOS. For whatever reason, AMOS sucks at playing samples, and an intermittent tone change can become apparent (more noticable with higher sample rates). Other than AMOS, I'll say I've had good results with higher rates. The maximum rate that AMOS permits is 28149. And up until now I have always used 28149 as a maximum (outside of AMOS) for all my song rips etc.
I'm not impressed with MP3's at all, so I stay away from them as much as I can. 320KBPS ones are acceptable to me though. They're such a strain on the old 68K processor, so 16bit wav's or aiff's are what I use. With hard drive storage so plentiful these days, I just don't see the point in lossy audio compression.
-
I'm going to use http://www.exactaudiocopy.de/ (http://www.exactaudiocopy.de/) rip my CD's to 22050Hz MP3's with the least compression.
NovaCoder, just so you know, the optimum sampling/playback rate for Black Eyed Peas is 0Hz....
-
From AHRM 89, p. 137:
Minimum sample time in DMA mode is 124 ticks for NTSC, 123 for PAL.
Ticks are based on 28.63636 MHz (NTSC) or 28.37516 MHz (PAL) main oscillator, divide by 8.
Maximum sample rate for a PAL machine in PAL mode: 28,836.54 Hz.
The absolute maximum is an NTSC machine in PAL mode: 29,101.99 Hz.
Of course, you can also feed Paula from the CPU - don't think there's a real limit here other than chipmem bandwidth and CPU latency, but you'll need some software to support that. Anyone?
-
I never played a sample using AMOS.
I only play samples using:
Various versions of Protracker
Octamed Sound Studio Professional
Various asm protracker replay routines
Various versions of Octamed asm replay routines
All produce unreliable results with 28Khz samples on my NTSC A1200 in PAL mode.
I am afraid that once you display some sprites or change screenmodes or whatnot that things will go wonky.
-
I'm currently playing back MP3's with a 44k sample rate, that worked well when I was running in VGA mode but now that I've switched to PAL I need to lower the rate.
If you want to go exactly by the PAL-rates, I'd suggest you use 22030hz instead of 22050hz :)
I was actually thinking of converting some albums to 22khz/16bit/stereo adpcm-files, in which case they would be playable even on an plain A1200 with fastmem (or even A500 in mono).
-
From AHRM 89, p. 137:
Minimum sample time in DMA mode is 124 ticks for NTSC, 123 for PAL.
Ticks are based on 28.63636 MHz (NTSC) or 28.37516 MHz (PAL) main oscillator, divide by 8.
Maximum sample rate for a PAL machine in PAL mode: 28,836.54 Hz.
The absolute maximum is an NTSC machine in PAL mode: 29,101.99 Hz.
Those are theoretical maximums. Theoretical maximums require the support of software which is 100% perfectly coded. As the perfect way to code Paula-banging software was never documented anywhere official, you just can't count on these sample rates.
Practical maximums are different and are extremely dependent on the exact hyper-technical coding technique used.
If u insist on using theoretical maximums then don't be surprised when ur samples play perfectly for a while then one day the exact same sample starts freaking out because the temperature in your room is 1 degree warmer than usual. :crazy:
Good luck. :mickeymouse:
-
Hmm...
Have never actually banged Paula, but DMA mode seems pretty straightforward. You allocate two buffers, initialize hardware, start DMA and when the IRQ for 1st buffer empty comes switch to 2nd buffer, reload 1st and so on. I guess the IRQ comes pretty late (last sample pair loaded) and you (=audio.device) need to react pretty quickly to set the other buffer (within 69 µs) - may be a bit tight with an 68000 w/o fast RAM, but an '020+ should really be able to do it. Think I need to try it out some day.
BTW: has anyone ever used the Copper to load samples in non-DMA mode? :lol:
Seriously, that might be a reliable way to run high sample rates on low bandwidth machines. You'd need to stay low with bitplane DMA but that's probably the same with CPU loading and even in DMA mode since you need to access the registers before the last sample's been played - so no superhires full overscan screens please.
-
@Zac67
Your description left out a ton of details.
Try writing such a program and you will have a 99% chance of it failing on either very slow samples, very fast samples, or both. Or your method will waste tons of CPU power.
There is a 1% chance of success based purely on luck that you might somehow code it just the right weird way to work.
-
I found this thread on EAB a while ago:
http://eab.abime.net/showthread.php?t=52746
Looks like someone tried it but failed. Quite likely if someone digs threads further can find more answers...
But generally it is not good idea push hardware to the limits but leave small error margin...
-
@ChaosLord: care to elaborate?
Of course, it'd waste lots of chipmem but feeding e.g. triple hsync frequency should be fairly easy. Running arbitrary sample rates is somewhat more complicated but you only need to calculate the 'Copper feed coordinates' for a single screen or maybe two or three and then reuse them as often as the sample requires.
Where does it waste CPU cycles other than for inserting the samples into the prebuilt Copper list?
But generally it is not good idea push hardware to the limits but leave small error margin...
Why not? Nothing's gonna break, just samples repeating if you fail.
-
Now that this thread has gone a bit quiet, can someone please explain the relation between screen refresh frequency and audio playback frequency? I cant imagine Im the only one being puzzled by this. I mean Ive always known about a certain connection, but not why it's there.
-
Now that this thread has gone a bit quiet, can someone please explain the relation between screen refresh frequency and audio playback frequency? I cant imagine Im the only one being puzzled by this. I mean Ive always known about a certain connection, but not why it's there.
It's all related to how much data can be pumped across the custom chip bus. The more graphics data you push across the bus the less time is left for audio data... Well, that's a bit simplistic, but you get the idea :)
-
All Amiga chipset DMA is tightly coupled to horizontal video timing. Paula's audio data has one DMA timeslot per scanline allocated for each of the audio channels. The bus is 16 bit wide, so two samples can theoretically be played during each scanline. Some internas of the chipset limit the theoretical 31+ kHz max sample rate to 28867 Hz (according to AHRM).
So, if you increase the horizontal scan frequency Paula is allocated more DMA slot time (shorter intervals) and can increase the sample rate without underrunning DMA throughput.
Another way is to feed data through the CPU - but that would require very fast IRQ handling and produce significant overhead. It should also be possible to use the Copper to feed data into the D/A registers (like in CPU mode) but apparently nobody has done it yet.
-
yeah, previous post was pretty much the most correct. It's the reason why DSS (Digital Sound Studio) changed screenmodes when you selected HQ sampling or playback. Some other stereo sampling programs (VideoMaster AGA's audio sampler) wanted to be in a dbl mode to have HQ sampling.
-
Understood. Thanks for your replies. I assume that is the reason why you can get higher frequency playback when you run Workbench in RTG mode.