@Karlos

Quote:

Assuming it is that, or something pretty similar, I've often wondered if it would be better to use a companded format in which a 16-bit sample is tramsformed into a format that allows one Paula channel to be used as a volume modulation for another. I am not sure how much latency there is in such an approach, although even if volume changes take tens of times longer than instantaneous sample value changes, one could still use the technique as a form of dynamic gain control. This seems to be more or less the same thing Hypex is suggesting.

It is because in my mind, knowing what Paula can do, when I thought how to do 14-bit that came to mind first. Using the AM features. It is lmited. Paula, like the other custom chips, is word based. It works in 16-bits at a time. So, samples are read in two at once, and when AM or FM mode is activated it too works on two bytes at once. This means AM (or FM) can only modulate the value every two samples. In effect, in this case, using AM would only be able to modulate at half the sample rate of the desination channel. So, the volume modulator would need to be averaged from two sample values, or another calculation to be as close as possible to both. In sample pairs, of two 14-bit samples, there would be one 6-bit value per two 8-bit samples.

Another option is using the CPU to program the volume register. Don't know how taxing this is on the CPU nor plausable. Or if it is possible to to do it on an audio interrupt. Or on a CIA timer interrupt. If it is this allows other possibilities. Or, hypothesis rather. The obvious is removing the sample pair AM limitation.

The next is 15-bit and 16-bit being possible. Again, emphasis on this being hypothesis. The math adds up but it has to work on real hardware. So for 15-bit, combine both channels to create a 9-bit sample value. Modify volume of channels with 6-bit value.

For 16 bit, it works just as cheap. Combine both channels as before to create a 9-bit sample value. But this time, combining volumes together, so volume of 9-bit sample is modified by 7-bit value.

The last two would also have the effect of maximising the whole analogue output volume. And thus using the full dymanic range. Where as the typical 14-bit trick or AM trick would limit this to half analogue volume.

That said, I'd really like to know­, how audio is mixed. Digital or analogue. People used to say the audio output was half the volume it should be. But, were they saying this about one sample per channel or two?

Last edited by Hypex on 27-Jul-2018 at 06:55 PM.

@Hypex

Quote:

Quote: Nope, one has to feed Paula with 6 bits data (that's the whole point). That's a shame since there is 8-bits of space. So it creates noise instead?

My guess is that the sound would be greatly distorted, with lots of noise and clicks.

Quote:

Quote: The game totally disables the OS and owns the hardware. It's all custom assembly code. No RTG support then?

No, the game targets the stock A1200 (and, besides that, I started making it precisely to have fun with the chipset, which is something I had not done for many years).

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@Hypex

Quote:

Paula, like the other custom chips, is word based. It works in 16-bits at a time. So, samples are read in two at once, and when AM or FM mode is activated it too works on two bytes at once. This means AM (or FM) can only modulate the value every two samples.

I can't remember what the Amiga Hardware Reference Manual says, but I'm pretty sure this is wrong: precisely because Paula fetches two bytes per channel at time, it has a modulating value for each sample.

EDIT: what I said above is wrong. The AHRM says that the modulating bytes are indeed treated as words as follows:
* amplitude modulation: bits 15-7 ignored, bit 6-0 volume;
* frequency modulation: all bits used as period value.
I've never used modulation, and it shows

Quote:

The next is 15-bit and 16-bit being possible. Again, emphasis on this being hypothesis. The math adds up but it has to work on real hardware. So for 15-bit, combine both channels to create a 9-bit sample value. Modify volume of channels with 6-bit value.

I don't think this works: in general, the volume shouldn't give more granularity. For a total digital amplitude of |1| it works, but think of the value 254 coming from 127 on both channels: the volume wouldn't give 65 steps beween 254 and 253, but 65 steps between 254 and 0, (nearly) matching values that can be obtained by sample values alone.

Quote:

People used to say the audio output was half the volume it should be. But, were they saying this about one sample per channel or two?

I had never heard this before, but I can tell you one thing: I have a C64 and an A1200 connected to the same monitor, and I definitely have to crank up the volume a lot (maybe even more than two times as much) for the Amiga to obtain a result similar to the C64's. I had thought that it was due to the audio input (the C64 uses the S-Video and related inputs, whereas the Amiga is connected through the audio-ins associated to the SCART), but now that I read this, I suspect that it's the Amiga original output to be weak.

Last edited by saimo on 28-Jul-2018 at 11:51 AM.
Last edited by saimo on 28-Jul-2018 at 11:50 AM.
Last edited by saimo on 28-Jul-2018 at 09:32 AM.
Last edited by saimo on 27-Jul-2018 at 08:43 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo & Hypex

Even half rate amplitude modulation opens up some interesting possibilities, especially if it can apply the volume change instantaneously for each new sample pair played in the modulated channel. I can envisage preprocessing samples into a format with volume normalised sample pairs in one buffer and the volume multiplier in another. These could be read by DMA, reducing CPU overhead compared to poking the registers directly.

Even latency in the volume modulation can be accounted for as long as it's systematic and doesn't vary.

Last edited by Karlos on 29-Jul-2018 at 12:53 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Even half rate amplitude modulation opens up some interesting possibilities, especially if it can apply the volume change instantaneously for each new sample pair played in the modulated channel. I can envisage preprocessing samples into a format with volume normalised sample pairs in one buffer and the volume multiplier in another.

Could you elaborate on this, please? I can't see how this would increase the resolution: the sample data still would range from -128 to 127 and volume modulation would only scale the amplitude from those maximums to 0.

Quote:

These could be read by DMA, reducing CPU overhead compared to poking the registers directly.

Well, that's the whole point of DMA-driven modulation

Quote:

Even latency in the volume modulation can be accounted for as long as it's systematic and doesn't vary.

I have no specific information, but it would be very strage if there were any latency at all: given that the engineers implemented modulation themselves (i.e. it is not a programming hack), they must have ensured that everything runs in sync.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

I can't remember what the Amiga Hardware Reference Manual says, but I'm pretty sure this is wrong: precisely because Paula fetches two bytes per channel at time, it has a modulating value for each sample.

I was hoping I was wrong on this but I was reminded of it in this thread I opened on this subject. Which would be a more relevant place than here now.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=40648&forum=2#771380

Quote:

I've never used modulation, and it shows

LOL. Well I started writing some routines years ago. I just found it and it was 21 years ago!

I recall I couldn't get it work, not because it wouldn't actually work aside from bug fixing, but because I didn't write the correct value into the registers to activate the sound. I may have fixed it since I was following a hardware banging guide. But I don't remember hearing about it!

Quote:

I don't think this works: in general, the volume shouldn't give more granularity. For a total digital amplitude of |1| it works, but think of the value 254 coming from 127 on both channels: the volume wouldn't give 65 steps beween 254 and 253, but 65 steps between 254 and 0, (nearly) matching values that can be obtained by sample values alone.

I think you'e right here. If we imagine the audio output being calculated as ((V0 * S0) + (V1 * S1)) with Vx and Sx being Volume and Sample for that channel, then what I am trying to do would be like ((V0 + V1) * (S0 + S1)), but the best it could do would be limited to (Vx * (S0 + S1)) or (((V0 + V1) / 2) * (S0 + S1)) if indeed possible.

So, combining two channels may be possible for full 9-bit dymanic range, but as you say, only allowing 65 steps between 254 and 0. Or 65 steps between 254 to 128 and 127 to 0, but seperately, only allowing 65 steps on the whole sample output.

Quote:

I had never heard this before, but I can tell you one thing: I have a C64 and an A1200 connected to the same monitor, and I definitely have to crank up the volume a lot (maybe even more than two times as much) for the Amiga to obtain a result similar to the C64's. I had thought that it was due to the audio input (the C64 uses the S-Video and related inputs, whereas the Amiga is connected through the audio-ins associated to the SCART), but now that I read this, I suspect that it's the Amiga original output to be weak.

Yes that is eaxctly the sort of thing I am thinking about. I once made a "poor mans mixer" with some resistors to mix the A1200 with my CDROM audio out. I may have softed the CD audio to even it out but I recall I put them there so they were electrically seperate. To an extent.

@saimo

I'm thinking of conpanding rather than trying to get better resolution per sample, i.e. extracting information from a 16 bit source to produce an 8 bit format with some dynamic gain control that enhances the quality in quieter passages. The idea is that this gain control can be encoded at say 1/16th the rate of the sample stream and be designed for interpolated reconstruction. What you end up with is something taking up a little bit more space than 8 bit, but with much better overall dynamic range.

Last edited by Karlos on 30-Jul-2018 at 02:36 AM.

_________________
Doing stupid things for fun...

@Karlos

OK, I see.
Then I'd say that there are 3 possibilities:
a. encoded gain data -> on-the-fly-reconstruction -> direct writes to AUDxVOL;
b. encoded gain data -> pre-reconstruction into CHIP RAM buffers -> DMA modulation;
c. raw gain data -> DMA modulation.

Pros and cons:
a. pros: uses the least memory of all and allows 4 channels; cons: but it requires lots of real time and timing-exact CPU work;
b. pros: doesn't require real time CPU work; cons: uses most memory of all and allows 2 channels only;
c. pros: doesn't require real time CPU work, best quality; cons: uses a lot of memory and allows 2 channels only.

IMHO 14 bit playback wins bigtime against b and c. a is the only option that makes sense, but it is not practical unless audio playback is all that the machine does.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Option A doesn't seem significantly different than what existing 14 bit replay routines have to do anyway.

However I was thinking of something that uses very little CPU on a low end machine. For that, DMA modulation using a small chip ram buffer and double buffering so that the CPU can write the sample and modulator data to one, while the other is playing. All the real work would be in initially generating the modulation channel data (let's call it the gain envelope) but that's just preprocessing that can be done elsewhere.

In my minds eye I see a simple frame format comprising of some fixed number of 8-bit samples and a gain value. The samples are normalised so that they always use the full 8-bit range and the gain sets the volume of the whole frame. It might even be cleverer than this; if we are interpolating the gain between frames, we'd normalise each sample based on the instantaneous gain that would be set at each interpolated gain point. This is all preprocessing to create a stream file, so the CPU it takes is basically irrelevant. The most work we do at runtime is transferring sample data and gain data into our chip buffer. And chip ram writes are so slow that I bet doing the interpolation of gain adds no extra time on any accelerated system. We ate dealing with 6-bit values here so lookup tables would be a trivial approach on low end CPUs.

In theory the approach still allows for overall volume control too as the volume control becomes a multiplier for the gain envelope.

_________________
Doing stupid things for fun...

@Karlos

Quick answer to just this part, as I don't have time for the rest...

Quote:

Option A doesn't seem significantly different than what existing 14 bit replay routines have to do anyway.

I have no idea of what the existing routines do, but I'd be surprised if they did any continuous fiddling with the registers: too much overhead and risk of output corruption. My method is: high 8 bits on one channel with volume set to 64, low 6 bits on the other channel with volume set to 1, and let DMA do the rest.

Quote:

However I was thinking of something that uses very little CPU on a low end machine. For that, DMA modulation using a small chip ram buffer and double buffering so that the CPU can write the sample and modulator data to one, while the other is playing.

This is similar to what I'm doing for SkillGrid (which is for unexpanded A1200):
1. the waveform is stored in a compressed format;
2. every frame (unless it is not needed), for both channels I unpack enough data for the duration of slighly more than 1 frame;
3. I use triple buffering.

Last edited by saimo on 30-Jul-2018 at 07:55 PM.
Last edited by saimo on 30-Jul-2018 at 06:37 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

I was under the impression that the existing 14 bit routines (cyber sound and ahi) rely on the CPU writing to the sample registers directly rather than DMA tricks which is why they generally require faster CPUs to be useful. Of course, they tend to be coupled with multichannel mixers which is where the extra overhead probably comes from.

Last edited by Karlos on 30-Jul-2018 at 02:56 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

In my minds eye I see a simple frame format comprising of some fixed number of 8-bit samples and a gain value. The samples are normalised so that they always use the full 8-bit range and the gain sets the volume of the whole frame. It might even be cleverer than this; if we are interpolating the gain between frames, we'd normalise each sample based on the instantaneous gain that would be set at each interpolated gain point.

That's indeed how I had imagined it when you first mentioned it, otherwise samples with wide dynamics wouldn't benefit (much) from the method.

Quote:

This is all preprocessing to create a stream file, so the CPU it takes is basically irrelevant. The most work we do at runtime is transferring sample data and gain data into our chip buffer. And chip ram writes are so slow that I bet doing the interpolation of gain adds no extra time on any accelerated system.

Could well be. Sometime in 2002 or 2003 I measured that the 68030 (clocked at 50 MHz) on my Bz1230-IV enjoys about 26 free cycles after a write to CHIP RAM. Even the 68020 on an unexpanded A1200 has 6 cycles free, provided that it doesn't make accesses to RAM (curiously, I measured this only recently for SkillGrid).

Quote:

In theory the approach still allows for overall volume control too as the volume control becomes a multiplier for the gain envelope.

I'm not sure AUDxVOL works when doing amplitude molulation, as that would require extra on-chip logic. If Paula actually does that, it would be a nice surprise.

Quote:

I was under the impression that the existing 14 bit routines (cyber sound and ahi) rely on the CPU writing to the sample registers directly rather than DMA tricks which is why they generally require faster CPUs to be useful.

I have never used Cybersound, but my guess is that AHI uses buffers because audio must not stutter / generate noise, and driving Paula directly in a non-real time multitasking system where the CPU has the lowest priority when accessing the CHIP bus just can't work - can you imagine the 680x0 handling an audio interrupt almost every rasterline? I guess it'd soon wave a white flag.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Regarding the volume statement, what I meant was that you apply the volume in software by adjusting the values you write into the gain buffer rather than Paula having to do it some other way. We can just apply the volume to the individual gain values before interpolation.

In fact what we are describing here isn't volume so much as attenuation. Full volume means the original 6 bit gain values are unchanged, half volume means we halved the two values and so on. Since we are dealing with 6-bit values here, a lookup table would allow simple volume adjustment.

_________________
Doing stupid things for fun...

@thread

Sorry, I have not kept up with the thread much.
I was wondering what else could it do.
How about Chroma Key, does it excel in this area?

_________________
John 3:16

@saimo

Quote:

I have never used Cybersound, but my guess is that AHI uses buffers because audio must not stutter / generate noise, and driving Paula directly in a non-real time multitasking system where the CPU has the lowest priority when accessing the CHIP bus just can't work - can you imagine the 680x0 handling an audio interrupt almost every rasterline? I guess it'd soon wave a white flag.

It does buffer it. Because AHI only accepts stereo samples in interleaved format or whatever is considered "normal". That is, left sample, right sample, etc. Amiga stereo samples separate the channels into different streams. Because Paula has no real notion of stereo. Each channel has its own pan on left or right. By themselves Amiga samples are mono.

So in the case of CyberSound doing a 16-bit stereo stream as an AHI audio driver, it would need to take a time sliced amount of samples, then split the data into four 8-bit buffers for playing on Paula.

As to an audio interrupt on each raster line, well, I tend to think my 15-bit routine would need to do that.

@Trekiej

Quote:

Sorry, I have not kept up with the thread much. I was wondering what else could it do. How about Chroma Key, does it excel in this area?

The palette can be set up at will, so one can decide to make any color (partially) transparent (but that sacrifices other colors - there's no short way to explain this).
But please note that the Amiga has also a built-in genlock capability.

Last edited by saimo on 01-Aug-2018 at 11:02 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@Hypex

Quote:

Quote: I have never used Cybersound, but my guess is that AHI uses buffers because audio must not stutter / generate noise, and driving Paula directly in a non-real time multitasking system where the CPU has the lowest priority when accessing the CHIP bus just can't work - can you imagine the 680x0 handling an audio interrupt almost every rasterline? I guess it'd soon wave a white flag. It does buffer it. Because AHI only accepts stereo samples in interleaved format or whatever is considered "normal". That is, left sample, right sample, etc. Amiga stereo samples separate the channels into different streams. Because Paula has no real notion of stereo. Each channel has its own pan on left or right. By themselves Amiga samples are mono.

Those are additional reasons, but the main reason why buffering is necessary is that the CPU can't sync all the time to Paula, even if it just had to write a single byte each time (unless, again, the CPU does not anything else to do).

Quote:

As to an audio interrupt on each raster line, well, I tend to think my 15-bit routine would need to do that.

Didn't we conclude already that your 15 bit idea doesn't work?

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

Quote:

saimo wrote: @Trekiej Quote: Sorry, I have not kept up with the thread much. I was wondering what else could it do. How about Chroma Key, does it excel in this area? The palette can be set up at will, so one can decide to make any color (partially) transparent (but that sacrifices other colors - there's no short way to explain this). But please note that the Amiga has also a built-in genlock capability.

AFAIK Banshee cleverly used this trick to obtain transparency effect for rain and big laser beams
Game ran on 8 bit screenmode (256 colors max) with 7 bit fixed palette (128 different colors).
The upper 128 colors (activated by the 8th bit) were the lower 128 modified as they would look if seen in trasparency through raindrops or lasers.
At this point they just had to draw raindrops and lasers as a 1 bit mask on the 8th layer of the screen to obtain the transparency effect.

(I red the article long ago and can't find it back now, so sorry if I lost something during all this time and gave wrong informations, but as I see there are plenty of programmers here that can correct me)

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

@ErikBauer

Quote:

AFAIK Banshee cleverly used this trick to obtain transparency effect for rain and big laser beams Game ran on 8 bit screenmode (256 colors max) with 7 bit fixed palette (128 different colors). The upper 128 colors (activated by the 8th bit) were the lower 128 modified as they would look if seen in trasparency through raindrops or lasers. At this point they just had to draw raindrops and lasers as a 1 bit mask on the 8th layer of the screen to obtain the transparency effect. (I red the article long ago and can't find it back now, so sorry if I lost something during all this time and gave wrong informations, but as I see there are plenty of programmers here that can correct me)

Yes, Banshee has those transparency effects. IIRC, on the first level it had 2 layers of fog, so, at least there, the graphics were on 6 bitplanes (64 colors) - but for memory and speed reasons, it's likely that the same holds true for the whole game (after all, 64 colors are a lot for a good pixeller, and Banshee's is an excellent one). I'm doing the same for SkillGrid (except that I do that on more layers).

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC