Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: biggun on March 16, 2008, 05:48:19 PM
-
Hi,
Thomas, and me did some brainstorming which sound capabilities make sense to include in the enhance PAULA chip of the NATAMI.
If you have experience in creating music then I would appreciate if you could participate in the discussion.
We want to include good enhancements into the new Paula chip. Of course the focus should be put on only putting important addition to the chip and not bloat it with unnecessary stuff.
As we know the original Paula had
- 4 channels (2 Left / 2 Right)
- each supporting 8 Bit samples
- and in addition to this 6 Bit Volume.
- The resulting audio output quality was 14 bit.
- All 4 channels used DMA to read their sample data.
- The DMA of two channels could be combined to read both
the sample and the volume values in for one channel.
- Doing this Paula could DMA create 2 channels with 14 bit.
The Natami New Paula:
- Audio output quality upgraded to 24 bit.
- Support for both 8-bit and 16-bit samples.
- combined with 6-bit or 8-bit volume.
I'm interested in your educated opinion, whether it makes really sense to increase the number of supported channels over 4.
A few opinions that we had:
a) The original Amiga could have a sound at left or right.
If you wanted to have a sound in the center both left and right then you needed to play it in two channels.
Having a center channel would be nice addition.
b) Octamed showed that its relative cheap to virtuelle increase the number of channels by mixing channels with the CPU. If you for example play a MP3 in a game on the natami then it will use 2 channels (1 left / 1 right) - This would leave you two free channels for effects. The CPU can mix many virtual channels into those in no time at all.
In less time then decoding a mp3 you can probably mix 1 dozend extra channels - So having extra HW audio channels might be important at all.
If you have experience in creating music it would be nice if you could add your opinion.
Cheers
Gunnar
-
- The DMA of two channels could be combined to read both the sample and the volume values in for one channel.
- Doing this Paula could DMA create 2 channels with 14 bit.
This is not how the 14bit audio works.
It works by playing the high 8bits with full volume, and the lower bits with volume 1 on the other channel.
Octamed showed that its relative cheap to virtuelle increase the number of channels by mixing channels with the CPU.
Actually octamed 8-channel mode was quite horrible (lots of limitations) and very CPU hungry. AFAIK it didn't use similar channel mixing to sp3m and AHI.
Whatever you do, preferably totally separate the new modes from the old audio registers. The best solution would be to allow old and new audio to co-exist, this way you can have old apps using audio.device or direct hw register banging after allocating the channels, and new apps using the high definition audio thru AHI. AHI supports 24- and 32-bit precision with 7+1 channels.
-
Ideally I would want at least 4 (or better 6) physical audio outputs. Which would allow me to route audio in a studio environment... or could be configured as left and right for standard desktop work, or as multichannel surround sound for entertainment.
Each physical output would require it's own channel... you wouldn't want 8 or 16bit support, 24bit is al that is required.
From a hardware point of view, you would probably really want a small "DSP like" processor and a bunch of SigmaDelta DACs... that would be the simplest way.
-
I'm very interested in the NatAmi, but have been wondering why the new audio capabilities didn't seem to be upgraded much. So I'm glad you ask us ;)
I've made music for my own enjoyment and programmed some players, including software mixing. I'm not sure I agree that mixing channels is relatively cheap. It quickly gets expensive if you were to play a 32 channel mod at 44.1 kHz. I worry a bit for the '060 even if it is 90 MHz.
Some things I've always missed in the Paula:
* A panning register so channels could be moved from left to right. Much like your center channel idea, but configurable by software. For instance a signed value from -128 (left) to 128 (right) per channel would be a VERY nice addition. .mod's sound SO much better in headphones when the channels are moved away from the extreme left and right position. It also opens up for some great effects in a tracker.
* 4 channels IS a bit limited, often you fight the tracker and end up having to cut off notes. I would definitely prefer 8. Some might want more, but I'd be happy with 8.
These two fairly simple additions to your existing design would make me very happy, it would be a pretty damn good sound card. Still not as advanced as say a Gravis Ultrasound, but still miles better and more useful than the original.
-
Oh! And another really annoying thing about the Paula ...
This I would consider essential - some kind of strobe register to force it to load the location and length registers, so you can set up the loop location and length quickly, without having to set up a timer! Man, is that annoying...
EDIT: Or simply guarantee that the internal location and length registers are loaded as soon as DMA is started....
EIDT: And you may want to think about increasing the size of the length registers. If people start using high quality 16 bit samples 128k would quickly get pretty small.
-
These days a pro musician or even someone recording a demo would need more capabilities then a 24bit Super Paula could provide.
I think it would be great for games and regular Amiga audio output though. It would be a long needed upgrade.
I think your specs are pretty right on for regular users.
for high end users we would really need some kind of drivers (AHI or not) for pro sound stuff like the Firewire/USB interfaces or even things like the M-Audio Delta 10/10 add on card style.
-
Actually octamed 8-channel mode was ... very CPU hungry.
Yes, octamed was CPU hungry on a A500.
Of course the memory bandwidth of the old 68000 and in general form the CPU to the AMIGA Chipmem was a real limiting factor even on AGA.
But the Natami with 68060 will have no problem at all, to mix 16 or more channels.
You have to mind that the NATAMI 060 is not only running at 90 MHz and that the Fastmen is many times faster than the AMIGA fastmem was, and most important that the bus between CPU and Chipmem is many many many times faster than it was on classic AMIGAs.
In theory you could create a DMA channel on the NATAMI (like special blitter mode) that can mix sources. But as the CPU could mix for free it probably not worth doing.
Even a 48KHz sound with 16Bit samples is only 94 KB per second. If you have 16 channels this is 1.4 MB sample data to mix per second. That just about 1% of the memory bandwidth of the Natami 060, so really no problem.
-
Hi Riftcon,
Thanks for your input
* A panning register so channels could be moved from left to right.
Valuable point, thanks.
How much resolution of the RIGHT/LEFT gradition is really needed?
It it needed to have a fine graine of 256 values or
would a simpler right/left position of something like (0%, 25%, 50%, 75%, 100%) be enough too?
* 4 channels IS a bit limited.I would definitely prefer 8
Thanks, noted.
-
The point I was trying to make: Octamed is particularly bad example. sp3m was the first app to really show what can be done with real channel mixing.
-
spihunter wrote:
These days a pro musician or even someone recording a demo would need more capabilities then a 24bit Super Paula could provide.
Oh, the Natami is NOT designed for pro musicians at all.
Sorry if my question sounded like this.
The question was to ask experienced music developers, as what in their opinion are the minimum requirements for good sound in a Amiga home computer.
We all agree that CD is good quality sound, and for perfect CD player quality all you need is 2 Channels with 16 bit samples each.
So 4 channels with 24bit quality is a very good start, I think.
I acknowledge that HW support for having channels in between left and right, and a few channels more will help creating AMIGA mods with zero CPU useage.
-
biggun wrote:
How much resolution of the RIGHT/LEFT gradition is really needed?
It it needed to have a fine graine of 256 values or
would a simpler right/left position of something like (0%, 25%, 50%, 75%, 100%) be enough too?
Hmm, I think 5 bits of precision would be good enough. It would be nice to be able to pan a playing sound from left to right and back in not all too discrete steps. At least not too audible. I guess 4 bits MIGHT be enough, but slow panning might suffer.
It would also be great for positional sound in games.
EDIT: I just looked it up, the Gravis Ultrasound got away with 4 bits (unsigned, 0-15) and that worked just fine in trackers on the PC. So I think 4 bits would be fine.
-
riftcon wrote:
Hmm, I think 5 bits of precision would be good enough. It would be nice to be able to pan a playing sound from left to right and back in not all too discrete steps. At least not too audible. I guess 4 bits MIGHT be enough, but slow panning might suffer.
It would also be great for positional sound in games.
EDIT: I just looked it up, the Gravis Ultrasound got away with 4 bits (unsigned, 0-15) and that worked just fine in trackers on the PC. So I think 4 bits would be fine.
Yes, I think one of the first AMIGA games doing this
panning of sounds from LEFT to RIGHT and back was Archon.
They did this by playing the same sample on one channel on each side and alter the volume to get this effect.
Actually the HW needs to do about the same work for panning channels.
For each channel that can be panned, the HW will have to mix two channels - One to the right and one to the left.
In other words for the HW supporting one panning channel
needs as much HW mixer resources as two non panning channels.
-
Actually the HW needs to do about the same work for panning channels.
For each channel that can be panned, the HW will have to mix two channels - One to the right and one to the left.
In other words for the HW supporting one panning channel
needs as much HW mixer resources as two non panning channels.
Hmm fair enough, I guess the only thing that would be faster is DMA, it would only have to fetch half as much data if it had a panning register.
Since the hardware already has some channel bundling features, as you also mentioned in the original post, what about a feature that would enable panning on a channel, but disabling another channel in the process?
For instance, it's already possible to use channel 0 to modulate channel 1, perhaps it could also be possible to disable channel 0 and get a panning register for channel 1?
But in this case I would probably like to have 16 raw channels :)
-
This sounds (no pun intended) great Gunnar.
I would say post this on amigaworld.net too to increase your chances of feedback from expert Amiga musicians. :-)
-
Oh I see now why you suggested 100%, 50% etc. That's obviously very fast to implement in hardware.
It would definitely make a big improvement, and musicians would still be able to make some much better stereo mixes.
If you could set a mode on, say, a left channel to be either 100% left, 50% left or %0 left (center), that would make for some much better sounding music as well! Even better if you can also move it to the right (that would require 5 panning settings per channel) so musicians don't have to think about which channel they use, but can simply set the panning in the instrument.
Yes. That would be pretty good actually. Eight of those channels, people who need better precision or stereo sweeps can do their own manual panning using two channels and volume.
-
vote for original amiga channels + 24 bit ahi mode
-
The rough capabilities of the Mary chip might be worth examining, but it looks like the key elements have already been addressed in this thread. Anyway, info's here (http://www.amigau.com/aig/amigaaaa.html), about halfway down the page.
-
Piru wrote:
The best solution would be to allow old and new audio to co-exist, this way you can have old apps using audio.device or direct hw register banging after allocating the channels, and new apps using the high definition audio thru AHI.
Interesting point, I'll note this one.
But do you think any user will run two music applications old/new at the same time?
That like playing AmiNetradio and the Game Hybris at the same time, isn't it?
A question to AHI:
Can you tell us what feature might be helpful to run AHI/SDL sounds with low CPU usage?
Cheers
-
Matt_H wrote:
The rough capabilities of the Mary chip might be worth examining, but it looks like the key elements have already been addressed in this thread. Anyway, info's here (http://www.amigau.com/aig/amigaaaa.html), about halfway down the page.
Wow, I hadn't really read that much about AAA before, that's just uncanny. Pretty close to what I would like to see in Paula. That, and a strobe register to load the location and length registers ;)
biggun wrote:
A question to AHI:
Can you tell us what feature might be helpful to run AHI/SDL sounds with low CPU usage?
I've never done AHI programming, only audio.device and hardware banging. I would guess that it would be simple to extend the Paula AHI driver to support the new features. The only thing I would look out for in the docs is stereo sound - whether it supports separate left/right streams at 16 bit or it requires interleaved left/right samples for 16 bit stereo. As AHI is an Amiga thing it can probably handle two independent left/right streams. If nobody else beats me to it, I'll have a look at it tonight.
-
riftcon wrote:
Wow, I hadn't really read that much about AAA before, that's just uncanny. Pretty close to what I would like to see in Paula.
While it offers no real technical information to how Mary would have worked, or how the registers would have co-existed with the older Paula set there is some more information HERE (http://www.thule.no/haynie/research/nyx/docs/AAA.pdf)
-
But do you think any user will run two music applications old/new at the same time?
Yes. It'd be really cool to be able to use old apps such as protracker, delitracker (the native noteplayers) or HippoPlayer, without rendering the new audio unusable. Since the old audio would be independent (with it's own volume) it could nicely co-exist with the new AHI controlled audio.
Think of it like having external soundcard in your amiga, only integrated.
Can you tell us what feature might be helpful to run AHI/SDL sounds with low CPU usage?
I'd take a look at some AHI driver, preferably one with 24bit support. AHI source (http://arp2.berlios.de/ahi/#source)
-
Perhaps add a simple off-the-shelf Realtek audio chip that takes SuperPaula as an input and passes it through and still offers you digital output.
That way "classic" apps still work with the Paula/SuperPaula and new apps could target a more modern chip...
-
The question was to ask experienced music developers, as what in their opinion are the minimum requirements for good sound in a Amiga home computer.
What's the target signal to noise ratio on Natami?
-
I'm interested in your educated opinion, whether it makes really sense to increase the number of supported channels over 4.
Of course it does... And the more the better... If mixing is not noticable in today computers, it sure will be with a slow 060 (yes, you may have memory as fast as you want, its raw CPU power is slow... and many many times than current CPUs...).
-
warpdesign wrote:
I'm interested in your educated opinion, whether it makes really sense to increase the number of supported channels over 4.
Of course it does... And the more the better...
If you are experienced in creating module music,
please tell us how many channels are in your opinion are needed for a good mod. If you have no experience in creating music, then please do not respond.
If mixing is not noticable in today computers, it sure will be with a slow 060
What you say is non true at all!
Even with a stock 68000 you can mix 8 channels.
For a 68060 mixing 8 extra channels takes no time.
-
I'm somewhat puzzled... if these new channels, new panning features, repeat/looping etc are meant for mods, who's going to write the new trackers and replay routines? Further, what will convince any tracker musician to create mods using this specific tracker program / mod format?
IMO it still would be smarter to keep the old audio hw as-is (wrapped to use the new HW obviously) and add the new stuff as common audio hw, with high quality audio output (say 8/16/24bit, 11/22/44/48 kHz, mono, stereo, 5+1, 7+1).
New trackers can use the HW thru AHI (OctaMed SS, DigiBooster, HivelyTracker etc).
If the old audio HW wrapper stuff is implemented too, you can use older trackers such as noisetracker, soundtracker, protracker and so on.
-
Even with a stock 68000 you can mix 8 channels.
For a 68060 mixing 8 extra channels takes no time.
There are many different ways of mixing though, and some are far more cpu intensive than others. There are various types of interpolation as well as oversampling and so on.
Playing a 32 channel fasttracker mod on an 060 with software mixing (oversampling) & panning @ 44.1khz uses a fair amount of cpu. And this using ptimised mixing code (I have faith that platon42 knows his stuff!).
-
I'm going to add some new audio features I'd like to see in a new Amiga (not sure if all this applies to Paula). I currently use an Amiga in a home music recording project studio (with Repulse audio card).
- definitely 16/24 bit audio playback.
- two channels is fine with me, although I can see the need for more than two in some cases.
- provision for real-time DSP (effects) would be useful.
- some way to have audio input (analogue to digital coversion) of 16 or 24 bits (for sampling or recording audio to the Amiga at these bitrates).
- AHI support.
- compatability with legacy software (i.e. emulate the original Paula 100%). Bars & Pipes relies on (steals) one channel of the original Paula for internal timing. If the new Paula was not compatible, it would break Bars & Pipes (which is a big reason a lot of musicians still use Amigas).
-
biggun wrote:
warpdesign wrote:
I'm interested in your educated opinion, whether it makes really sense to increase the number of supported channels over 4.
Of course it does... And the more the better...
If you are experienced in creating module music,
please tell us how many channels are in your opinion are needed for a good mod. If you have no experience in creating music, then please do not respond.
In OctaMED Sound studio, I would rarely ever use more than 16 channels at most in mix mode... though I would often use two channels (panned hard left and hard right) for a single sound, and then mess around with the play back to simulate various effects and delays.
If mixing is not noticable in today computers, it sure will be with a slow 060
What you say is non true at all!
Even with a stock 68000 you can mix 8 channels.
For a 68060 mixing 8 extra channels takes no time.
I totally agree with Piru, have a decent Paula emulation... and a nice modern audio chip with an AHI driver... Audio is a commodity now, technologically it's reached a plateau... you can't really do anything innovative (as is still possible to some degree in the GFX space). Great audio chips can be bought off the shelf for next to nothing.
-
quote]
I totally agree with Piru, have a decent Paula emulation... and a nice modern audio chip with an AHI driver... Audio is a commodity now, technologically it's reached a plateau... you can't really do anything innovative (as is still possible to some degree in the GFX space). Great audio chips can be bought off the shelf for next to nothing.[/quote]
I know were you are coming from.
I think there is a very important point you are missing here. It might be my fault explaining it not good enough before.
The think is that:
-The Natami is fully Paula compatible already.
-The Natami can already switch to a new mode providing working 24bit Paula enhancements.
-And the Natami has working upsampling to 96kHz
-And the Natami has a very high quality DA converter.
The DA is of higher quality than the typical "next to nothing" sound card will have.
I fully agree with you that it makes no sense try to beat professional sound studio cards with the Natami.
If you need Studio feature the simplest solution is to buy such a card. And of course you can plug in any PCI soundcard into the Natami if you want.
But as the Natami sound device in on the board already
and as is able to produce good quality sound.
It makes good sense to think about how to get the most out of it without less effort.
Adding some extra features as panning, or 8 channels support
are only little firmware work for us now.
So if more channels is what people want, or if support for interleaved wave data is what would speed up AHI
then we can add this all "for free" now.
Please mind that adding an extra sound chip to the board is not a good idea. Putting another chip on the board would require that its DA-out gets mixed back with the Paula signal. This solution would consume a lot extra space on the board. As it would require extra wires from the FPG, we would not a more expensive FPGA to connect that extra chip.
And of course this would make the mainboard a lot more expensive as the board would need to be bigger. And this would require a new board layout.
The audio out of the Natami is quite good quality for a consumer device.
We have now the possibility to add some nice features to the Natami audio for free.
We could as well add new features with a firmware update at a later time.
If you have input and sensible wishes now, fine
If not then this is okay for us too.
Cheers
Gunnar
-
The thing I'd want is an AC3 multichannel output on eigther spdif or coax out so it can be hooked up to a modern Home theater system. Not shure about the rights for a Dolby Digital compatible stream though, although an open source project is available here (http://aften.sourceforge.net/).
-
Well I ain't an audio expert, but I would mind seeing:
8 channels of sound.
Definable left/centre/right for each channel (or the four new channels). Preferably capable of a nice smooth pan.
Sure, a 68000 can software mix 8 channels of audio down into 4, but it's not doing much else at that time (which ain't too hot for a multitasking computer). Nice to have it all done in hardware, without having to end some notes early to play another one, etc.
Also it would be nice if the end spec was published, so, for example, MiniMig could implement that audio spec (on a hardware level at least, maybe the outputs wouldn't be the same quality) which would increase the market for that implementation, thus increasing the software that would support it.
-
IMHO, as a musician, I'd like to see the following things per channel for an enhanced Paula:
1) 8/16-bit sample depth support
2) 8-bit volume register
3) 8-bit pan register (-127 full left, 127 full right)
4) Optional interpolation for playback of sample data below the hardware mixing frequency.
If you can do that per-channel, then I'd like to see at least 16 of them :-)
I use OctamedSS for pretty much all my composition, using it to drive MIDI kit as well as sample playback. Mix mode works well but these days I tend to render stuff to AIFF then do post-processing and mixing on the rendered output.
-
Also it would be nice if the end spec was published, so, for example, MiniMig could implement that audio spec (on a hardware level at least, maybe the outputs wouldn't be the same quality) which would increase the market for that implementation, thus increasing the software that would support it.
This is an excellent point!
Thanks for bringing this up.
I'm a big fan of open specification and fully agree with you that this is an important part.
You are absolutely right, that if the new Amigas will
share a common Paula audio enhancement this would be a good thing.
If the new Generation of Protracker Mods will play both on MiniMig and Natami this would be really cool.
It think it will be real nice if we as Amiga community will manage to come up with a good spec for New Paula all together.
Cheers
-
So I've had a look at the various AHI documents, the device interface in particular and some device source code.
As I suspected the AHI mixing routines output interleaved stereo sound in signed 16 (or 32) bit. So if the audio device doesn't support interleaved samples, the CPU will have to do some work. The Paula driver splits the stream itself.
Eight or more channels is supported (as is panning), but the mixing routines will obviously have to come into play if a program needs more.
EDIT: Having said that - if you're already spending time resampling and mixing, splitting the buffers is not going to add anything significant to the total...
While looking through the docs and the code, I thought of another addition to the wishlist. You've probably already thought of this, but the period registers need better precision, they're already a bit inadequate for the higher octaves - some higher notes are a bit off. When the samplerates go up, they will be next to useless for realtime playback as found in trackers.
-
I'm not the music guy you want, so you might want to ignore my ramblings:
8-bit volume on both left and right for each DMA channel. (You can do positional yourself with that.)
A small DSP for mixing. With DMA feed?
Instant DMA start as someone else said.
Oh, and I hope you have blitterlists (like copperlists) for the new blitter.
-
I'm not a music guy either, but it seems to me you should Keep It Simple Stupid (KISS) : Don't bother with fancy panning modes, when you can achieve the same with two audio channels. Better to just have as many h/w channels as you can easily accomodate (8 at least, 16 would be cool, but 32 might be overkill), and then let the CPU handle any complex effects.
IMHO the "Amiga way" was to have flexible/semi-programmable hardware, rather than to hard-code specific effects into the hardware. So any semi-general functionality which would allow you to reduce the CPU load (say some clever DMA modes) for certain effects would be great (and maybe programmers can find ways to use such functionality in ways not imagined).
-
>> If mixing is not noticable in today computers, it sure >>will be with a slow 060
>What you say is non true at all!
>
>Even with a stock 68000 you can mix 8 channels.
>For a 68060 mixing 8 extra channels takes no time
Better to keep as much in hardware as possible. Even in the B&W Mac days, they thought the 68000 was so powerful that they put so much in software that nowadays that Mac is pretty much obsolete since all that software functionality can be done better on a PC. If something time-critical was being done and music/samples were playing in the back-ground, at least the hardware can be exactly measured rather than relying on a software module to mix tracks.
Also, today's PCs also seem to have a mixer of analog signals as well since the CDROM-audio can be mixed with the wave audio at various volume levels. I'm not a musician but I sample lots of stuff from cassettes into compressed digitized audio and I find that some parts of the music is very low in volume and has to be normalized by hand. I don't know if there's a music term for that but a dynamic normalization mode could help there (perhaps playing lower bits as if they were higher bits in a 24-bit/8-bit mode).
-
nowadays that Mac is pretty much obsolete since all that software functionality can be done better on a PC.
Macs use exact the same common audio components as PCs.
Also, today's PCs also seem to have a mixer of analog signals as well since the CDROM-audio can be mixed with the wave audio at various volume levels.
I don't know which decade you're living on, cd-rom audio hasn't been analog for years (the analog audio cable isn't even connected).
-
Piru wrote:
nowadays that Mac is pretty much obsolete since all that software functionality can be done better on a PC.
Macs use exact the same common audio components as PCs.
I think he's taking about the old Macs (of the 80s)
Also, today's PCs also seem to have a mixer of analog signals as well since the CDROM-audio can be mixed with the wave audio at various volume levels.
I don't know which decade you're living on, cd-rom audio hasn't been analog for years (the analog audio cable isn't even connected).
Very true! I think the last time I connected a CD ROM audio cable was 1999...
-
Yes, the Macs before they switched identities and still used the same name.
>>
>> Also, today's PCs also seem to have a mixer of >>analog signals as well since the CDROM-audio can be mixed >>with the wave audio at various volume levels.
> I don't know which decade you're living on, cd-rom audio >hasn't been analog for years (the analog audio cable isn't >even connected).
>Very true! I think the last time I connected a CD ROM audio >cable was 1999...
On my PC the audio cable is connected to the motherboard (it's a 1Ghz Dell running Windows 3.11). It saves on the bandwidth to have it mix the analog audio rather than run it through some Media Player that reads the digital data off the CD and plays it like a WAVE which prevents using applications at the same time that use the WAVE output. The old Thinkpads had some sort of module that let you play multiple wave files simultaneously-- may be it was their MWAVE DSP that did that.
Anyway, I guess any analog mixing would be external to the Paula chip if this is going to be a plug-in replacement or backward compatible on the hardware level.
-
it's a 1Ghz Dell running Windows 3.11
Ouch. This is not "today's PC".
Regardless, even 1GHz system (running proper OS) can mix at least 128 simultanous audio sources together without any trouble. You're most certainly not limited to a single wave.
-
Hello Biggun,
I am also working on a AAA FPGA Amiga but my pace is a lot slower (because of work, family, ...).
Anyway, I thought about the same compatibility issues in my design. Here is what I came up with :
- 16 16-bit channels.
- 2 volume control registers (one for left, one for right).
- Better precision for the period register. I guess your SuperPaula clock will be 28 MHz at least. Even at 28 MHz, you need to have a "fractional" part for the period register so you can generate 32 kHz, 44.1 kHz or 48 kHz sampling rate.
- The 4 standard Paula channels are mapped on channels 10 - 13 (because of the address decoding :-D )
- Have one or two DSPs that can access the chip registers and the chip RAM (or the DMA FIFOs ?) and have their own instruction memory (32KB or 64KB per DSP).
Regards,
Frederic
-
I just would like to know Natami's complete specs. Do you have this in a document, or do you intend to let this public?
I believe many people here would like to help you in this project someway. I'm the first one to raise my hand :-)
-
And thus you have it, you can't possibly beat today's PC or Mac but you can come close to a 1999 PC without destroying compatibility. Given that this is retro-computing some might complain that that's not retro enough!
-
Karlos wrote:
IMHO, as a musician, I'd like to see the following things per channel for an enhanced Paula:
1) 8/16-bit sample depth support
2) 8-bit volume register
3) 8-bit pan register (-127 full left, 127 full right)
4) Optional interpolation for playback of sample data below the hardware mixing frequency.
If you can do that per-channel, then I'd like to see at least 16 of them :-)
1) 8/16-bit sample depth support
I agree, and this is included already.
2) 8-bit volume register
I agree, its also included.
3) 8-bit pan register (-127 full left, 127 full right)
I agree, that panning is useful.
Its certainly good to be able to put some voices in the center. But I feel that 8 bit panning volume is overkill and not needed for most cases. I would prefer have simpler HW panning support for the majority of cases.
I think the question is how often to you need panning.
I think every song can make use of having a drum "in the middle" or "having the bass in the 1-part LEFT / 2 parts RIGHT position".
For the rare cases where you need 256 positions of panning "for the helicopter if circling around you effect" you can always use two channels and do the panning the normal ways over the volume.
4) Optional interpolation for playback of sample data below the hardware mixing frequency.
I fully agree. And the new Paula ie "Pamela" chip does HW oversampling of all samples automaticly.
I think it to make the HW support those feature that most songs will need.
If a rare case does needs something special, then its okay to use the software for this. Even the not upgraded Natami, is at least over 100 times faster than a classic A500.
Its okay to use the CPU from time to time.
But it would be nice if we could catch the majority of cases with HW support. E.g if 95% of the AHI music does play without CPU usage and if the majority of SDL games will play without CPU usage then this is great.
What is your opinion as musician:
How many HW channels are needed to play 90% of the mods?
Cheers
Gunnar
-
Not a Musician... But I would like to have some way of implementing Surround easily...
-
biggun wrote:
3) 8-bit pan register (-127 full left, 127 full right)
I agree, that panning is useful.
Its certainly good to be able to put some voices in the center. But I feel that 8 bit panning volume is overkill and not needed for most cases. I would prefer have simpler HW panning support for the majority of cases.
What is your opinion as musician:
Cheers
Gunnar
I am not a musician, but I have several pieces of music where sound pans from one speaker to the other, the effect could not be achieved with only 4bit or less panning, so a musician who wants to move sound between speakers needs 8bit panning.
It would also be useful in games where the sound can come from the sound source on screen rather than from off screen.
Something that is far beyond your goal, would be the ability to positions sounds anywhere in 3d space using panning between 8 speakers.
-
@BigGun
How about adding an DSP? Like the one used on DelfinaDSP? Other than that, I wonder what sort of audio output do you have? Will it be minijack or phono?
Take Care
-
I am not a musician, but ...
Only a musician should make statements like "xyz is needed for this and that in music".
We have discussed this before: On AMIGA it was always possible to make these panning effect using two channels (one left one right) and use the 6-bit volume to create panning effect.
It was mentioned before that AMIGA games used to use these effects. 6-bit volume was good enough for this effects on classic Amigas. Natami has 8-bit volume, so really enough bits for high quality panning.
We stated before that certain PC cards that provide panning use 4-bit resolution for this.
I think a panning for new channels is a useful addition to have sounds coming from center or middle-right center etc.
For "placing the instruments" on the stage 2-4 bits is more than enough. For high quality effects you can always allocate two channels getting 8-bit resolution.
My 2c
-
All of my musical equipment has at least 7-bit resolution (often a lot higher) for volume and pan since that's the basic minimum standard required for General MIDI conformitiy.
FWIW, I agree with Piru that you should separate the traditional Paula model from the new one, providing the former as a wrapped interface to the latter.
When designing the 'Super' features, consider implementing features from the perspective of an API such as AHI as well as thinking about current and future module formats.
I seem to recall, AHI uses 16:16 fixed format for volume and pan, which is pretty high resolution indeed. Suddenly hardware 8-bit panning resolution doesn't sound that excessive any more. Ideally, SuperPaula would be able to accelerate a decent chunk of AHI functionality.
Going back to a purely musical view, if you could add tuneable low pass filters to each channel, I'd be very happy indeed :-)
-
Well, I might not be talented at creating music. But for coding games etc, it could be nice to have 5.1 sound. That is real 5.1 sound, not emulated. That was what I meant :)
So instead of "just" panning from left/right, you could also have the option of panning rear/front and left/right.
-
very interesting thread!
i make music on amiga since 1994. i've started with protarcker (4ch, 8bit), later with prot.'s sceneversion, melontracker.
then i've got an a1200 and digibooster pro has came with real multichannel capatibilities. with a 68030/50 i was able to play and edit 8-10 channels in 14 bit modes, then 12-14 chs. with my later 68040/40. then i've bought a VSS soundcard with built in mp3 decoder, 24 bit sound - man, that was awesome after paula's fake-14bit modes... full 16 bit replay with 16-20 channels (well, 20 channel was a bit much for the 68040...).
you can hear some of my music made on the amiga1200 and VSS here:
http://pollen-records.uw.hu/tizev.html. point your browser to the "letoltes" link below the cover. 80% of this album has made on amiga.
im sure that for musicians the more channels are the better.
if you want to use some effects (digibooster pro has some basic dsp echo and delay effects fe.) in your song, a 060 surely not enuff for sw mixing 16< channels.... use as much hw channels as you can!
make it ahi compatible for digibooster and for the other audio softwares using ahi. maybe add a nice dsp for real time effects:) panning is important i guess, i know you can do it with 2 channels with volume, but still...
anyway, this project is great, too bad it's not 1998/99 anymore.....:) keep up the good work!
-
Karlos wrote:
All of my musical equipment has at least 7-bit resolution (often a lot higher) for volume and pan since that's the basic minimum standard required for General MIDI conformitiy.
Just checked all my Audio software and hardware, and everything is 7 bit... -63 to 63... I guess that's the legacy of MIDI...
Going back to a purely musical view, if you could add tuneable low pass filters to each channel, I'd be very happy indeed :-)
12pole resonant (with Adjustable Q) low pass filters please :-) Some distortion effects might be easy to implement too...
While we're at it why not add a filter and amp envelope?
-
What about if instead of just one volume register for each channel, use two registes? One for left and other for right.
This would satisfy panning and volume with a good resolution without complicating the hardware, and would eliminate the need for two channels to do the "helicopter" effect
-
I agree that 7 bit resolution for panning and 7 bit resolution for volume should be a minimum requirement. Dynamic panning is very good to have and gives the musician more freedom.
If you say that dynamic panning is not needed, you're in effect imposing a limit on the type of music that you think should be made using your device. Electronic music in particular will use panning in more complex ways and it's very common to have a synth sweep panning from left to right. Listen to Jean Michel Jarre's Oxygene IV for instance. Dynamic panning is important :)
As far as polyphony goes, 8 voices is probably the lowest that any modern musician is going to feel comfortable with although 16 voices would arguably be even better.
The Paula has a seldom used "oscillator sync" feature where you sacrifice one voice to control the sample index pointer or amplitude of another voice. This could be used for vibrato or tremolo and possibly even a few simple synthesizer functions like phase modulation and ring modulation. Any chance of implementing this in the SuperPAULA?
-
AmiDelf wrote:
How about adding an DSP? Like the one used on DelfinaDSP? Other than that, I wonder what sort of audio output do you have? Will it be minijack or phono?
Take Care
A good example of a System using a DSP was the ATARI Falcon.
At the time of the Falcon, adding a DSP made sense.
The Falcon main CPU was quite slow, the 030 of the Falcon was just slightly bit faster than a stock Amiga 1200.
The situation is now different.
The NATAMI 060 is at least 10 times faster than the Falcon. The Natami can do those effects with its 68k, which at the time of the Falcon were only possible because of the DSP.
There is not that much value of adding a DSP just for Audio effects to the AMIGA.
But having a general purpose DSP with like ALTIVEC features could make sense. Such a general DSP could be used to various tasks ranging from MP3 audio decoding, to DVD playback, or acting as Texturemap shader.
We are evaluating these options.
Cheers
Gunnar
-
bloodline wrote:
Karlos wrote:
All of my musical equipment has at least 7-bit resolution (often a lot higher) for volume and pan since that's the basic minimum standard required for General MIDI conformitiy.
Just checked all my Audio software and hardware, and everything is 7 bit... -63 to 63... I guess that's the legacy of MIDI...
[/quote]
You'll probably find there are ways to send 14-bit data as MSB/LSB pairs. The GM requirement is that you can send a 7-bit value which depending on the parameter is treat as signed or not. On some of my kit, these 7-bit parameters are regarded as 'course' controls and have separate RPN messages to set the 7-bit fraction LSB 'fine' control.
Some controllers are capable of directly interpreting a 14-bit successive byte-pair value. IIRC, pitch bend is one of them.
Going back to a purely musical view, if you could add tuneable low pass filters to each channel, I'd be very happy indeed :-)
12pole resonant (with Adjustable Q) low pass filters please :-) Some distortion effects might be easy to implement too...
While we're at it why not add a filter and amp envelope?
Well, provided you have registers for the basic controllers I don't think there's much harm in letting the CPU do envelope control :-)
-
AeroMan wrote:
What about if instead of just one volume register for each channel, use two registes? One for left and other for right.
That isn't really any different to having an equal resolution volume/pan pair. The advantage of volume and pan is that it's a friendlier interface.
As a musician you usually want to adjust a given part's volume or stereo location. Having separate left and right volume controls implies that you always need to modify both in order to adjust either property.
You might as well make the hardware support it rather than force the software layer to translate pan/volume into a pair of left/right volume values.
-
But having a general purpose DSP with like ALTIVEC features could make sense. Such a general DSP could be used to various tasks ranging from MP3 audio decoding, to DVD playback, or acting as Texturemap shader.We are evaluating these options.
Hardware assisted audio/video would certainly be a nice feature for those wanting only to run an Amiga system.
-
Karlos wrote:
Well, provided you have registers for the basic controllers I don't think there's much harm in letting the CPU do envelope control :-)
Yeah, I was joking about Envelope control :-)
But that does raise the important issue of Buffers and latency... I don't really care about features sicne the CPU can worry about that... What I do need is a latency under 6ms!
-
biggun wrote:
3) 8-bit pan register (-127 full left, 127 full right)
I agree, that panning is useful.
Its certainly good to be able to put some voices in the center. But I feel that 8 bit panning volume is overkill and not needed for most cases. I would prefer have simpler HW panning support for the majority of cases.
As every channel has already a volume register you could also use another approach: you could stay with left and right channel but offer the possibility that a left and a right channel play the same data but thus with a different volume.
From the other side I would also like to see 5.1 and 7.1 support and this is possibly not compatible with just left and right channels ...
greets,
Staf.
-
I don't know if this has been mentioned before, but the period registers can be improved by making them "phase" registers that are added to a phase-accumulator. This is how a DDS works and (I believe) the 6581 SID works. This way you'll have far better resolution without having to use exotic clock frequencies. You do have to make a provision in the hardware to skip some samples though....
Dennis
-
bloodline wrote:
What I do need is a latency under 6ms!
Hence the reason my hardware synth hasn't been replaced by some jumped up bit of software ;-)
-
Karlos wrote:
bloodline wrote:
What I do need is a latency under 6ms!
Hence the reason my hardware synth hasn't been replaced by some jumped up bit of software ;-)
Hahahaha, I still stand by my MBP and an Edirol FA-101 :-)
in Ableton Live 5 and Logic Pro 8; I get about 3ms latency each way (3 in and then 3 out), hence my demand for 6ms latency :-)
-
So, from a musicians point of view, would it be better to have MIDI than a superpaula?
-
A6000 wrote:
So, from a musicians point of view, would it be better to have MIDI than a superpaula?
NO!!!! :-)
I only have one MIDI device left now (all the rest are USB)... and that is connected to my Mac via a USB-MIDI interface :-)
-
Karlos wrote:
That isn't really any different to having an equal resolution volume/pan pair. The advantage of volume and pan is that it's a friendlier interface.
Pan is easier to work with, but depending on the way the audio circutry was done, having one volume for each output might be easier to implement in hardware than a true pan.
The final result is pretty much the same, I agree. I was just trying to suggest another approach that could simplify the solution in some cases.
-
>And thus you have it, you can't possibly beat today's PC or Mac but you can come close to a 1999 PC without destroying compatibility. Given that this is retro-computing some might complain that that's not retro enough!
That wasn't what was being attempted. If you do want to compare PC sound to Amiga sound, you would have to compare the standard hardware not some specialized card in either machine. Taking the Sound Blaster standard in the PC and the Amiga hardware, you can easily see that the Sound Blaster cannot play 4 waveforms at the same time and uses a 1 Megahertz crystal to calculate frequencies whereas the Amiga can play 4 waveforms and uses a 3.57Mhz crystal to calculate frequencies.
While you could emulate the more channels in software, it's not comparing hardware and it's not real-time anymore.
-
by FrenchShark on 2008/3/17 21:33:16
>- 16 16-bit channels.
>- 2 volume control registers (one for left, one for right).
>- Better precision for the period register. I guess your SuperPaula clock will be 28 MHz at least. Even at 28 MHz, you need to have a "fractional" part for the period register so you can generate 32 kHz, 44.1 kHz or 48 kHz sampling rate.
How does the SoundBlaster get away with it using just a 1Mhz crystal? I guess they are rounding off to rate closest to the 22.05Khz, 44.1Khz or 48Khz. I just thought that it would be more useful if the FPGA was in a plug-in module for the Paula socket so it's backward compatible with existing Amigas. (i.e., pin-compatible).
-
amigaksi wrote:
How does the SoundBlaster get away with it using just a 1Mhz crystal? I guess they are rounding off to rate closest to the 22.05Khz, 44.1Khz or 48Khz. I just thought that it would be more useful if the FPGA was in a plug-in module for the Paula socket so it's backward compatible with existing Amigas. (i.e., pin-compatible).
They might use a PLL along with it.
I do not see the interest of making a plug-in.
The Chip RAM is too slow to handle these extra high resolution channels.
You need a brand new architecture to make it possible.
Regards,
Frederic
-
Dennis wrote:
I don't know if this has been mentioned before, but the period registers can be improved by making them "phase" registers that are added to a phase-accumulator.
Phase accumulators will decrease sound quality and introduce aliasing into the sound. On the SID you get away with this because the sample rate is very high (around 1 MHz?). In this case the sample rate mentioned is 96 KHz which doesn't seem enough.
-
in the SID you get away with this because the sample rate is very high (around 1 MHz?).
The sample rate of the ADA is 192 KHz
The goal for the internal clock rate of Pamela is double of the CPU clock, thats 180 MHz in the case of the NATAMI60.
-
@BigGun
I`ve been an DelfinaDSP DelfMpeg betatester. Its one of the best soundcards out there. I am not a hardware person, but for me it seems that it is the Motorola DSP cpu which is inside DelfinaDSP.
Either its 68030 or 68060. Its really nice to have a DSP that handles the sound. Ive never in my whole life heard such great musicquality as from my sold Amiga 4000 with DelfinaDSPz2 that Ive overclocked from 40MHz to 66MHz.
The sound quality of that board is one of the best I`ve ever heard! Ive listened to several Soundblaster cards and other more expensive PCI cards. But they havent beaten my old DelfinaDSP card at all. Even with my bad Creative speakers. The sound quality of Delfina showed it strength. And my ears are made for music and sound.
I am not saying this because I love Amiga, but because it is how I have captured the sound quality of DelfinaDSP which I have tested from A to Z practically. With delfinampeg.device you can listen to the music thru AmigaAMP etc.
Good luck with your NatAmi.
And have a great Easter time :)
Regards,
Mike
-
AmiDelf wrote:
@BigGun
I`ve been an DelfinaDSP DelfMpeg betatester. Its one of the best soundcards out there. I am not a hardware person, but for me it seems that it is the Motorola DSP cpu which is inside DelfinaDSP.
Either its 68030 or 68060.
it's the Motorola 56002...
Its really nice to have a DSP that handles the sound.
As opposed to?
Ive never in my whole life heard such great musicquality as from my sold Amiga 4000 with DelfinaDSPz2 that Ive overclocked from 40MHz to 66MHz.
What did you overclock?
The sound quality of that board is one of the best I`ve ever heard! Ive listened to several Soundblaster cards and other more expensive PCI cards. But they havent beaten my old DelfinaDSP card at all.
Sound blaster is hardly the gold standard of audio quaility... but the Delgina uses the same CS4215 codec... as best I could suggest that the SB had poor gound sheilding or badly written drivers... But the Delfina is hardly top quality audio.
Even with my bad Creative speakers. The sound quality of Delfina showed it strength. And my ears are made for music and sound.
You use Creative Speakers... yet you say your ears are "made for Sound and Music"... Get some Mordaunt-Short's or Celestion's if you want to hear good quality at a resonable price...
I am not saying this because I love Amiga,
Yes you are.
but because it is how I have captured the sound quality of DelfinaDSP which I have tested from A to Z practically.
Um... good?
With delfinampeg.device you can listen to the music thru AmigaAMP etc.
How nice!
-
Going back to point 4 (I think it was) on my suggestion list, the ability to turn off interpolation all together should definately be an option.
As a musician, one of the things I use paula for is her dirty, heavily-aliased sound when playing back samples. Additionally, the non-linear sample value->amplitude is rather nice.
I suggest, in addition to the ability to turn off interpolation, perhaps that 8-bit sample playback should have an optional 8->16-bit lookup table that emulates the response curve of the original Paula.
-
Karlos wrote:
As a musician, one of the things I use paula for is her dirty, heavily-aliased sound when playing back samples. Additionally, the non-linear sample value->amplitude is rather nice.
The Amiga doesn't alias. It does have frequency mirroring though, which is a much more pleasant and harmonic and can still sound very raw. A lot of Amiga musicians took this into account and sampled their sounds at a note frequency relative to the sampling frequency to minimize non-harmonic distortion.
With 192 KHz sampling frequency (which, i guess, could be thought of as 4x oversampling) you won't have much audible aliasing even without interpolation.
I agree that being able to select between an interpolated and a non-interpolated sample playback mode for each channel would be very useful.
-
Karlos wrote:
I suggest, in addition to the ability to turn off interpolation, perhaps that 8-bit sample playback should have an optional 8->16-bit lookup table that emulates the response curve of the original Paula.
Can anyone here publish the original Paula response curve? I'd love to write a paula effect processor! :-)
Actually... I probably have all the equipment needed to find it out myself... does anyone know a decent menthod?
-
Remember the cybersound 14-bit driver calibration tool?
One could probably create something similar to estimate the response curve.
-
My plan was to build an 8bit audio sample at 44100Hz which gradually steps down through the dynamic range (with some stupidly low period)... play that back on one of my Amiga's and sample it at 24bit 192Khz on my Mac... I should be able to examine the sampled sound and compare it with the original to find out the actual repsonse...
This is my first thought, If I think about it a little more... I should be able to optimise the procedure a little!
-
The problem I have with that approach is that a very low frequency output of that nature is not likely to make it through the analogue amplification stage.
The calibration file produced by cybersounds 14-bit calibration tool probably already contains the information you need, albeit in the inverse.
-
Karlos wrote:
The problem I have with that approach is that a very low frequency output of that nature is not likely to make it through the analogue amplification stage.
Hmmm... I was hoping that since the frequency would be fractional (I would hope to hold the sample at each voltage level for 10s of thousands of samples) it would pass through the electronics totally unaffected... I would run it all at line level, so no preamps filtering out sub 10Hz...
I am open to suggestions!! If someone has an Oscope then perhaps they could do this for us?
-
I was thinking the onboard amplifiers on the motherboard would basically filter out your very low frequencies as they look too much like DC when coming up against a capacitor.
You'd have the same problem on your sampler input too, I'd expect.
-
Karlos wrote:
I was thinking the onboard amplifiers on the motherboard would basically filter out your very low frequencies as they look too much like DC when coming up against a capacitor.
You'd have the same problem on your sampler input too, I'd expect.
Yes... I was relying on it looking like DC... ok... Then perhaps I can do the same with a 1Khz tone playing on the Amiga... Yes I think I can...
I'm loathed to use the 14bit calibration, since I know nothing about how that works!!
-
bloodline wrote:
I'm loathed to use the 14bit calibration, since I know nothing about how that works!!
Me neither. I planned to simply compare a fresh uncalibrated file with the calibrated and see if I could intuit the relationship from the differences ;-)
-
Karlos wrote:
bloodline wrote:
I'm loathed to use the 14bit calibration, since I know nothing about how that works!!
Me neither. I planned to simply compare a fresh uncalibrated file with the calibrated and see if I could intuit the relationship from the differences ;-)
That's rather clever and almost certain to take a million years...
I should be able to do it with a 1Khz tone, sampled at 192Khz... as that will hold the voltage, for 192 samples... hopefully long enough for me to identify it...
What type of Audio DAC does the Amiga use anyway? Perhaps a simpler solution would be to simulate it?
-
SuperPaula!? What! Crazy talk. I need to find some different street drugs. Anyway, mix modes sucked, period. Even though lots a people seemed to use them in the mod world. Sound was terrible.
Keep your octamed a quadraped if you know what i mean.
-
bloodline wrote:
That's rather clever and almost certain to take a million years...
It's seemingly just a lookup table. I wasn't going to do it by manual inspection. I was going to graph the differences ;-)
-
Karlos wrote:
...
It's seemingly just a lookup table. I wasn't going to do it by manual inspection. I was going to graph the differences ;-)
Wavelab has a nice tool for that :-D
-
8 channel mode on octamed is VERY unstable :-P
ummm .. doesnt octamed support 16bit samples..? im sure ive imported 16bit samples intooctamed v6 ..?
-
Karlos wrote:
bloodline wrote:
That's rather clever and almost certain to take a million years...
It's seemingly just a lookup table. I wasn't going to do it by manual inspection. I was going to graph the differences ;-)
Well get on and do it... if not let me know, and I'll build a look up table based on my idea...
-
@all
Many thanks for your good contributions!
I feel that this brainstorming was very good and really productive. I think the feedback from the musicians was very valuable.
At riftcon:
riftcon wrote:
So I've had a look at the various AHI documents, the device interface in particular and some device source code.
As I suspected the AHI mixing routines output interleaved stereo sound in signed 16 (or 32) bit. So if the audio device doesn't support interleaved samples, the CPU will have to do some work. The Paula driver splits the stream itself.
Thanks for looking this up.
This is very valuable information.
I was looking at the AHI source briefly.
I'm not sure if I understood how/if AHI supports more HW channels.
Can you or anyone help me to understand this?
The question is:
If the HW for example supports 8 independent Channels, each with 8 or 16 bit samples, independent frequency and independent volume.
Will AHI make 100% use of this. I.E. will a 8 voice audio piece run fully on HW or will AHI still do some software mixing or upsampling of the channels?
Many thanks in advance
-
I was looking at the AHI source briefly.
I'm not sure if I understood how/if AHI supports more HW channels.
Can you or anyone help me to understand this?
AHI supports Mono, Stereo and 7.1 (aka 8) output channels, no other number of channels (so if you really want to have 5.1 channel output, you would need to use the 7.1 mode).
Changing the number of supported output channels is a PITA, because there are dozens of optimized mixing routines for each sample type combination (see SelectAddRoutine in mixer.c) and addroutines#?.[c|s].
However, AFAIK it supports any number (<256?) of "voices" (again with the given width Mono, Stereo and 7.1) that may be mixed together to that output HW channels mentioned above.
The question is:
If the HW for example supports 8 independent Channels, each with 8 or 16 bit samples, independent frequency and independent volume.
Will AHI make 100% use of this. I.E. will a 8 voice audio piece run fully on HW or will AHI still do some software mixing or upsampling of the channels?
There is a mode where the driver may take over the mixing completely (makes it possible to do this in hardware or via DSP). I just looked it up, you can actually mix different sample types of a "voice" to the output channels.
AFAIR the Paula DMA drivers use this mode (no mixing is done, but limited to <4 "voices").
Martin Blom is still around these days and is very helpful ;)
-
platon42 wrote:
Will AHI make 100% use of this. I.E. will a 8 voice audio piece run fully on HW or will AHI still do some software mixing or upsampling of the channels?
There is a mode where the driver may take over the mixing completely (makes it possible to do this in hardware or via DSP). I just looked it up, you can actually mix different sample types of a "voice" to the output channels.
It sounds like you have done a lot more AHI programming than me :) From reading the programmer API docs I think this mode requires you to allocate the HW channels from the driver and control them yourself with pitch, volume, pan etc? Which is fine I guess, but it doesn't look like AHI will use the HW channels automatically even if they're adequate for the job?
In this mode it also looks like you query the driver for its supported pan, volume etc resolutions and you have make sure you set them within the defined range. There's no mapping of values, which I like. It just exposes the hardware at a low level.
-
Can anyone here publish the original Paula response curve? I'd love to write a paula effect processor!
Actually... I probably have all the equipment needed to find it out myself... does anyone know a decent menthod?
I would imagine the best way to *generate* the Paula response curve would first require you to know what kind of D/A converter Paula used. I *vaguely* recall it used a series of (9?) resistors to get the voltage drops required for each of the 8 bits, which is not very accurate due to the resistor tolerances, and therefore tends to produce a non-linear response curve.
Assuming my recollection is correct, then you need some method to find the relative values of each of those (9?) resistors. That should be MUCH more accurate & less error prone, especially compared to trying to sample the output of Paula across her entire dynamic range.
I imagine that the 14-bit audio calibration tool used some clever method to accurately find out the relative resistor values, so that it could then compensation for them.
-
ChrisH wrote:
Can anyone here publish the original Paula response curve? I'd love to write a paula effect processor!
Actually... I probably have all the equipment needed to find it out myself... does anyone know a decent menthod?
I would imagine the best way to *generate* the Paula response curve would first require you to know what kind of D/A converter Paula used. I *vaguely* recall it used a series of (9?) resistors to get the voltage drops required for each of the 8 bits, which is not very accurate due to the resistor tolerances, and therefore tends to produce a non-linear response curve.
An R-2R Ladder DAC eh? I guess that would work for something as simple as 8 bits... Ok... are these integrated on the Paula IC or on the Board? I need to find a Paula pinout..
Assuming my recollection is correct, then you need some method to find the relative values of each of those (9?) resistors. That should be MUCH more accurate & less error prone, especially compared to trying to sample the output of Paula across her entire dynamic range.
It would be easy to work out... but that's not going to give me real word performance.
I imagine that the 14-bit audio calibration tool used some clever method to accurately find out the relative resistor values, so that it could then compensation for them.
IIRC the calibration tool was rather subjective... which required you to decide when the response was linear... it was a long time ago...
-
Looking at an A500 schematic it seems the Audio DACs are actually in Paula herself... pretty cool...
-
That answer lies not in what can you make the hardware do, but what the blend of software and hardware can do.
basically for the pro/semi-pro it is PCI Cards and AHI drivers, USB Midi should definitily have drivers written but this is all out of the scope of your question. Yet in pure digital the line between what is pro and what is not is blurred...
My Personal preference:
sp/dif or optical out should be a serious consideration.
basic upgrade for paula standard should be:
8 channels
left right assignable
8/16/24 modes
forget the centring - anything like that is stereo and played at different volumes - I think people are getting confused by dolby surround - yes it has a centre channel, but this has an independent output and requires a compatible amplifier system.
How may outputs are you thinking of putting on the board (could we have 6 mono outputs - assignable?) **
What I would really like to see is a paula mode + toccata emulation mode for 6 channel output with existing software, but this requires writing a toccata emulation library - a stable one!
** extra upgrade mode would definaltly be 32 channel mode set up as above but there needs to be an AHI driver created for this to work with existing software (I still want a working toccata library also :-) ).
So, without a toccata library or AHI driver the thing is pretty much useless to use with existing software - if these can't be written then stick with 4 channels but with the upgrades that you have already specified and see what happens with 3rd parties... We can plug in PCI cards.
on a side note - I have considered DSP stuff (my Flipper is great), but once again a serious lack of software in this department will hold this back and may be a wasted feature addition - Personally I would serious consider the ability to add Cell Clusters (oh yes!) to the system.
-
Cheeeky wrote:
sp/dif or optical out should be a serious consideration.
S/PDIF might reduce the sound quality since the most common implementations are not capable of 192 kHz sample rate. One option might be hardware resampling although this would most likely increase the hardware complexity and/or quality.
If professional musical use is a goal then ADAT Lightpipe is a more sensible direction to go in than S/PDIF since it supports many channels and/or sample rates up to 192 kHz. Then again, considering the limitations compared to modern electronic music equipment on the market, there are no reasons to use the SuperPAULA for professional audio unless it ends up having something very unique to offer.
Either way, personally i see few reasons to justify implementing S/PDIF.
-
Karlos wrote:
bloodline wrote:
That's rather clever and almost certain to take a million years...
It's seemingly just a lookup table. I wasn't going to do it by manual inspection. I was going to graph the differences ;-)
The CyberSound preset calibration file is a table of 256 1byte values (I assume they are signed, since Paula is...)... I wrote a quick program to examine it... I'm not sure exactly how these numbers are used to transform the audio?
I'm going to build a few graphs until I get something meaningful...
-
Ok... I think I've figured it out...
Each byte in the the calibration file seems to correspond to the difference between what one would expect the 8bit->16bit value to be (using simple LSL scaling) and what the Amiga actually produces... This is the only way I can make sense of the file... anyone have any other ideas?
-
One thing nobody has mentioned yet is the difference how the Amiga played audio and how modern systems do it. Modern systems interpolate samples to get different notes then play this at a fixed rate (44, 48, 96KHz etc).
The Amiga didn't do this, it played the samples at different rates.
This is an important thing to consider because the low sample rates Amiga apps used generated a lot of quantisation noise and this was of course part of the Amiga's sound.
If you try and interpolate samples up to a higher fixed rate you'll lose this sound. If you are upsampling (as seems to be the case) the number of sample you add per sample will be different for each rate, this means you'll be adding quantisation noise but in a different way. Many of these frequencies will above human hearing range but not all.
So, in short if you're not careful you could end up with 8 bit Amiga audio sounding very strange. I guess it depends on how accurate you want it but if you want high accuracy you'll need 2 different systems.
--
BTW why are you using a 68K processor? Wouldn't it be better to use a PPC, that way you can emulate the 68K and you'd have a faster processor. It also gives you at least the possibility of running the likes of MorphOS* (assuming you could talk them into supporting it).
*I'm not saying OS4 because it's in legal limbo and will probably remain there.
-
As the sample rate can be any value I understand that Digital-Out would be complicated as it won't sync - but would it not be possible for the hardware to enable the digital out when a syncronizable play rate is chosen? such as :
8,000
9,600
11,025
12,000
16,000
22,050
24,000
32,000
44,100
48,000
88,200
176,400
192,000
I've never heard of ADAT Lightpipe and don't have any equipment that would support it... thing is, it doesn't make the music any better ;-)
-
@anyone who knows
The talk about panning register, and using 2 channels with volume to create your own panning solution is an interesting one.
Is it always true that a voice/channel is hardwired to output to just one speaker? Classic Amiga hardware was this way. Is new hardware this way? Is the FPGA board used for NatAmi this way? Imagine if you had 16 voices, but what speaker they came out on (literally, which RCA connector on the back of your Amiga) depended on this panning register. Thus you would only need 1 voice to be generated or played, but this output is sent to potentially both channels, but with various resistance on each channel to effect a reduction in volume, to effect panning effects.
ie
100% left 0% right (register = 1000)
75% left 25% right (register = 0100)
50% left 50% right (register = 0000)
25% left 75% right (register = 0010)
0% left 100% right (register = 0001)
Only with more resolution than that. (say the 7 or 8 bits suggested in previous posts)
tiffers