Welcome, Guest. Please login or register.

Author Topic: SuperPAULA - if you have experinece in amiga music please give feedback  (Read 16081 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
Quote

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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
Quote

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 :)
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
Quote

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, 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 ;)

Quote

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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...
 

Offline riftcon

  • Newbie
  • *
  • Join Date: Feb 2008
  • Posts: 33
    • Show all replies
    • http://www.rift.dk
Quote

platon42 wrote:
Quote

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.
A1200 desktop w/Blizzard 1260, 64 MB fast, Graffiti and 40 gig HD.
...and an NTSC A1000 w/256k expansion, C-One, Mac Mini PPC, MacBook, Motorola StarMax 3000 and some PC\\\'s...