bypassing paula output

[meynaf]

I looked for a way to directly send sounds to the host. Might be interesting for an audio player to use that when available (true 16 bit, >28khz).

By looking at uae.audio.asm (ahi driver source ?) i got a few pointers but not enough to make something that works. I can get the call address from uae.resource, however attempts to use it failed.
And no, I don't want to just use ahi.

Is there a doc somewhere about that $(f0)ffc0 call ?
Or can I just ask my questions here and get meaningful replies ?

[Toni Wilen]

You could enable Toccata sound card emulation and program it directly...

uaeahi interface is undocumented and unsupported but you can use if you really want. I don't help with, it isn't done by me. (but there is no guarantees it won't change suddenly)

[meynaf]

That's still some kind of emulation...
And it does not solve the problem, as i don't know how to program it either.

Such an interface can have a great value so perhaps better support could be a good idea... if, of course, it's enough in regard to supported features (just regular dbl buff stuff should be enough).

[Toni Wilen]

I only implement real existing expansion emulation.

Toccata is very simple in hardware level, doublebuffered 512 byte sample buffer, set samplerate and 8/16 mode, CPU fill the buffer, then device interrupts when buffer was swapped. It is really lightweight. Practically works the same as uaeahi.

Perhaps there is even easier to program sound card. Just find one

[meynaf]

Any pointer on where to find the docs ?

[Toni Wilen]

Unfortunately Toccata probably is the worst card for documentation, for some weird reason they created library that talks to the hardware, they didn't release any hardware programming information.. Even AHI needs that library.

NetBSD has Toccata support (probably reverse-engineered so it does not really document anything)

Some other more hardware programming friendly sound card would be better choice. I don't know which one (but it MUST NOT have any DSP chip, I am not going to emulate those)

[meynaf]

And as docs aren't your cup of tea, you don't have any in spite the card is supposed to be emulated in winuae, huh ?
I don't have the toccata library anyway.

But perhaps the winuae sources can give me hints... if i can find where this stuff is done.

[Toni Wilen]

WinUAE and NetBSD sources probably help. Find AD1848 documentation too.

[meynaf]

By looking into winuae sources i've found something called ahi_winuae_v2 (uae rom + $FFC8).
Is it better documented ?
Can it be used by me or is it just another experimental, private thingy ?

[Toni Wilen]

Originally Posted by meynaf

By looking into winuae sources i've found something called ahi_winuae_v2 (uae rom + $FFC8).
Is it better documented ?
Can it be used by me or is it just another experimental, private thingy ?

It was supposed to be uaeahi update, years and years ago, it was not finished.

[meynaf]

I think i'll stick to 14bit

[Toni Wilen]

I may be able to do tiny toccata direct to hardware routine after cd32load audio stuff is done.

It is always nice to automatically get real hardware support

[Toni Wilen]

After some thinking: forget what I said..

It would be really easy to make "hardware" emulation of perfect sound card that does not exist in real world. (All needed framework already exists).

- Full DMA capable. Just write Amiga address and length (like Paula without chip ram restrictions) to IO register. The rest would be automatic. (AFAIK none of real Amiga audio cards are DMA capable)
- Automatic buffer chaining.
- >2 channel support

There could be simple data structure that describes the sound buffer, one for each buffer:

- Type of buffer (8/16/24bit samples, number of channels)
- Length of buffer
- Address of buffer
- Volume of buffer (or "don't change")
- Playback frequency of buffer (or "don't change")
- Address of next description structure (or 0 = end)
- Other misc bits (For example generate interrupt when buffer has started/ended)

Usage would be very simple:

- Write address of first data descriptor (can be anywhere in RAM) to IO register
- Enable playback

- Register for reading current active descriptor, play position, volume, frequency etc..
- Write registers to change volume or frequency anytime you want.

Not going to happen:
- any kind of DSP stuff or similar.
- different playback frequencies at the same time.


What do you think of this?

[meynaf]

Originally Posted by Toni Wilen

After some thinking: forget what I said..

What must I forget ? I don't remember

Originally Posted by Toni Wilen

It would be really easy to make "hardware" emulation of perfect sound card that does not exist in real world. (All needed framework already exists).

If you say it's easy, i sure take it.

Originally Posted by Toni Wilen

There could be simple data structure that describes the sound buffer, one for each buffer:

- Type of buffer (8/16/24bit samples, number of channels)
- Length of buffer
- Address of buffer
- Volume of buffer (or "don't change")
- Playback frequency of buffer (or "don't change")
- Address of next description structure (or 0 = end)
- Other misc bits (For example generate interrupt when buffer has started/ended)

Usage would be very simple:

- Write address of first data descriptor (can be anywhere in RAM) to IO register
- Enable playback

- Register for reading current active descriptor, play position, volume, frequency etc..
- Write registers to change volume or frequency anytime you want.

That's not exactly my need, but it's a lot closer

It looks more like a DT/EP noteplayer interface, which i kinda like to use.


Here's how I see things (actually it's done like that in my programs, even though only Paula-compatible settings are currently supported by my code).

We have three functions.


1. Allocate audio. Two structure addresses are passed in. First says info such as :
- base frequency (like 3546895 if we want to later use Amiga period, or 44100, or whatever - sound pitch will be freq/per afterwards)
- maximum sound size to be played (is $20000 for Paula)
- min, max period values that'll be used (16-bit values are enough here)
- number of channels (up to 32 if possible)
- needed sample data alignment in memory (is 2 for Paula)
- volume range (64 for Paula, but could be 100 for volumes in %, or anything)
- various flags (like filter on/off, must use chipmem, sample sync needed or not, 8/16/24 bits, etc)
- stereo data array saying where each channel would go : $80 don't care, $81 left, $7f right, $00 center, other values being intermediate

Second structure remains blank here. Its address is just noted.


2. Play audio. No parameter : the structure is known from previous step. So the user just fills in the second structure mentioned above then calls this function : the effect is immediate.

The structure says (the user can write or read these) :
0.l sample address (write)
4.l sample length (write)
8.w period (write)
$a.b volume (write)
$b.b sync (read)
$c.l repeat (write)
$10.l replen (write)
Of course this is an array ; one such struct exists for each channel. No need to use a linked list for that, an array is more practical to me.

First the data is played with "sample address" and "sample length" (length is in number of samples, obviously).
Once finished, the "sync" byte is set as true, then the "repeat" and "replen" values are used to continue seamless playing (and when its end is reached, the values set here are used again and the flag set again, and so on).

Writing new address/length pair implies previous sound is immediately stopped and the new one starts to play.

A length of zero immediately stops the sound. Using a replen of zero indicates the sound should automatically stop at the end.

Setting repeat/replen without prior sample is valid and indicates the sample should simply loop until something is changed.

The writes are detected by setting sample length to -1L (which indicates no-op later on).


3. Exit audio. Frees all resources.


A 4th function might eventually set the master volume, if available.


What do you think of this ?
(and was I clear enough ?)

Originally Posted by Toni Wilen

Not going to happen:
- any kind of DSP stuff or similar.

I don't need that anyway.
Oh, well. Bass and treble would be nice to have, but it's clearly not mandatory.

Originally Posted by Toni Wilen

- different playback frequencies at the same time.

If you mean playback frequencies at the host level, then it's really no big deal.

Originally Posted by Toni Wilen

What do you think of this?

Sounds good.

[strim]

Originally Posted by Toni Wilen

After some thinking: forget what I said..

It would be really easy to make "hardware" emulation of perfect sound card that does not exist in real world. (All needed framework already exists).

If you do it in a way that allows writing a driver for any OS (i.e. does not depend on AmigaOS structures like uaertg), then I might be tempted to write the NetBSD driver for it .

[Toni Wilen]

I prefer buffer linking because it allows extremely easy double buffered (or longer) playing mode.

Repeat can be added.

Complete "channel set" (1 channel if mono, 2 channels if stereo and so on) will only have single length, playback and volume value. (Not like Paula). Samples will be interleaved if more than 1 channel. (Just like most modern sound APIs work)

Current "sound card" sound interface only allows single "channel set" (=multiple sound cards at the same time are not supported), but in the future there may be multiple channel sets, each having separate volume, length and frequency.

Originally Posted by strim

If you do it in a way that allows writing a driver for any OS (i.e. does not depend on AmigaOS structures like uaertg), then I might be tempted to write the NetBSD driver for it .

Thats the point. Keep Amiga-side interface as simple as possible and low level.

Perhaps similar "hardware UAE interface" can be done with other devices too...

[meynaf]

Originally Posted by Toni Wilen

I prefer buffer linking because it allows extremely easy double buffered (or longer) playing mode.

Complete "channel set" (1 channel if mono, 2 channels if stereo and so on) will only have single length, playback and volume value. (Not like Paula). Samples will be interleaved if more than 1 channel. (Just like most modern sound APIs work)

Then it's not "perfect sound card that does not exist in real world", but "same thing as everyone else".
Paula can play sound tracker directly. So-called modern sound APIs can't.

[Toni Wilen]

Sound card's most important feature is to play 1-n channel audio as a single stream as easily as possible.

I already said future updates can enable multiple streams. (This is not technical issue, just boring to do issue and no one would use it anyway, I am quite sure of it..) This is exactly how it works with most APIs, you can allocate and play as many streams as you need, each stream has 1+ channels, frequency, volume, panning/3d position and so on.

IMHO today it makes more sense to think Paula as having 4 audio streams and each stream being capable of single channel only, than Paula having 4 channels

[meynaf]

Originally Posted by Toni Wilen

IMHO today it makes more sense to think Paula as having 4 audio streams and each stream being capable of single channel only, than Paula having 4 channels

But Paula can start channels synchronous. If streams are really separate, then they can't be started with a single command, can they ?

[Nut]

Toni or anyone, could you please write small example code of how to use Toccata in assembly. I want to support this to get perfect audio out of WinUAE. I'm doing software mixing 32bit and getting it out 14bit now using interrupts or copper but this has many problems on the emulator. All kinds of noises appear do to multiple reasons.

Play/stop, buffer address, sample format, rate, volume and all that stuff visible so we can understand how to use it. How to detect a Toccata is in the system? And can I just force a new start if I need to sync the card with the screen / my mixing routine ?

I'm only interested in direct access. So no libraries please, if possible.