Sound frequencies on Falcon

[mikro]

Unfortunately, even in the compatible clock mode the 6.25 kHz frequency is not available (results in mute). This is purely Falcon specific.

Btw, there seems to be a typo (at two places), neither STE/TT nor Falcon has a 6.125 kHz frequency available.

[ThorstenOtto]

Yes, see devconnect:

Code: Select all

If 0 is passed to the prescaler, then the
  	mode will be switched to STE compatibility

If you then use Soundcmd(6), you get STE/TT compatible rates:

Code: Select all

 	Compatibility to the STE sound system. data is taken as a prescaler if the prescaler set via devconnect has the value zero:
 

0 	Prescaler divides by 1280 (6.25 MHz)
1 	Prescaler divides by 640 (12.5 MHz)
2 	Prescaler divides by 320 (25 MHz)
3 	Prescaler divides by 160 (50 MHz)

Those are the first four frequencies listed above.

[mikro]

I'm on not sure why do you insist on things which you couldn't test and others could (proving you wrong).

Even Atari Compendium is very clear about this: Soundcmd() returns the prior value of the specified command if data is SND_INQUIRE (-1). Using the SETPRESCALE mode to set a frequency of 6.25 MHz (CCLK_6K) will cause the sound system to mute on a Falcon030 as it does not support this sample rate.

[czietz]

Screenshot_20240331_160250_Samsung Notes.png

Confirms that 6.25 kHz is not possible

[ThorstenOtto]

Ok, sorry. But:
- The Compendium is also not always right
- If that is real the case on falcon, we should note it in tos.hyp
- As noted above, my routine is just doing the same as your atari_sound_setup.h. If that rate is not actually supported, that routine should be fixed, too.
- Fixing it may be difficult though, since there might be other hardware and/or drivers that actually support that rate

I guess the reason why that rate is muted because of these settings (from hardware.txt)

Code: Select all

$FF8921|byte |Sound mode control                BIT 7 6 . . . . 1 0|R/W  (STe, TT, F030)

       |     |Frequency control bits                            | ||
       |     |00 - Off (F030 only) -----------------------------+-+|    (F030)
       |     |00 - 6258hz frequency (STe only) -----------------+-+|

But i doubt that this is important in practise.

[Cyprian]

btw.
interesting note, I wonder if that 32Mhz clock would allow to transfer 1MB/s between the RAM and the DSP

[mikro]

I wonder if that 32Mhz clock would allow to transfer 1MB/s between the RAM and the DSP

Of course. It's just the DAC which doesn't work at 32 MHz rates. I have done many nice tests with this but so far I haven't found something worthwhile to use it for.

[Cyprian]

I wonder if that 32Mhz clock would allow to transfer 1MB/s between the RAM and the DSP

Of course. It's just the DAC which doesn't work at 32 MHz rates. I have done many nice tests with this but so far I haven't found something worthwhile to use it for.

Great

[medmed]

While trying to get sound working in C&C, i just realized that the Falcon does not seem to be able to play sound at some rather common frequencies like 22050, 44100 or 48k Hz. For example the frequencies that are calculated by the xbios routines in SDL turn out to be:

Code: Select all

audio:xbios: freq 0: 49169 Hz, clock 25175000, prediv 1
audio:xbios: freq 1: 32779 Hz, clock 25175000, prediv 2
audio:xbios: freq 2: 24584 Hz, clock 25175000, prediv 3
audio:xbios: freq 3: 19667 Hz, clock 25175000, prediv 4
audio:xbios: freq 4: 16389 Hz, clock 25175000, prediv 5
audio:xbios: freq 5: 12292 Hz, clock 25175000, prediv 7
audio:xbios: freq 6: 9833 Hz, clock 25175000, prediv 9
audio:xbios: freq 7: 8194 Hz, clock 25175000, prediv 11

Some of the prediv values are skipped (6, 8, and 10, not that these would result in anything common, but i also wonder why this is the case)

So did i miss anything, or is there really no way to get those rates without additional hardware? The result is that in a lot of cases, rather CPU intensive conversion routines have to be used (only to convert them back to what the sound-card supports in emulators)

Hi,

Is there an already existing xbios call to use 44.1/48 kHz if available?
As I know today there are Falcon, Milan/Hades, Firebee and V4sa which can play at these frequencies using HW.
I guess it will save a lot of CPU if a direct call to these frequencies was implemented and it will make video/sound players and game ports more reliable.
Otherwise, maybe it would be better to implement them directly in mintlib (using mch & snd cookies)?

[ThorstenOtto]

Is there an already existing xbios call to use 44.1/48 kHz if available?

Yes, provided that you check first whether an external clock is available (see miro' sound routines)

Basically you have to call

Code: Select all

Gpio(GPIO_WRITE, 0x02) or Gpio(GPIO_WRITE, 0x03)

, depending on which clock source provides the needed frequency. Then for 44.1 for example you call

Code: Select all

Devconnect(DMAPLAY, DAC, CLKEXT, CLK50K, NO_SHAKE)

[medmed]

Is there an already existing xbios call to use 44.1/48 kHz if available?

Yes, provided that you check first whether an external clock is available (see miro' sound routines)

Basically you have to call

Code: Select all

Gpio(GPIO_WRITE, 0x02) or Gpio(GPIO_WRITE, 0x03)

, depending on which clock source provides the needed frequency. Then for 44.1 for example you call

Code: Select all

Devconnect(DMAPLAY, DAC, CLKEXT, CLK50K, NO_SHAKE)

Many thanks Thorsten.

Then if I understand well the way to do it is to use gpio + external clock for falcon and milan blaster.
gpio on milan seems to be readonly? I don't know if gpio write will work.

Code: Select all

 	1 External clock
 	   For MilanBlaster the external clock is
 	   24.576 MHz when gpio(1,0) & 0x1l == 1l
 	   and 22.5792 MHz when gpio(1,0) &
 	   0x1l == 0l

So in order to use 44.1khz on the firebee or v4sa and in the hypothesis where an implementation would be made do you think use gpio write + clk_ext would be the better way? I am having trouble finding information or code regarding the use of these frequencies on the firebee or hades.

[ThorstenOtto]

gpio on milan seems to be readonly? I don't know if gpio write will work.

Good question. Maybe you can use gpio(GPIO_READ) afterwards to double-check that the value has really been set.

[mikro]

gpio on milan seems to be readonly? I don't know if gpio write will work.

Good question. Maybe you can use gpio(GPIO_READ) afterwards to double-check that the value has really been set.

It doesn't matter. The detection routine will always return the true value. So if the GPIO is read only, writing to it will do nothing, you run the detection routine and get the same result for both clocks (i.e. 48000 or 44100).

[ThorstenOtto]

Yes, but you could save the time needed for doing one of the two tests. Question is only which one to skip...

[ThorstenOtto]

Time for some new test programs

The attachments have programs for Falcon & firebee respective. The programs are the Led Blur demo from Miro, in two flavours: once compiled with his sound routines (SDL is still used for video display), and once compiled using a new version of SDL audio. The other two programs are just compiled examples from libxmp (the player also uses SDL, the xmpinfo tool just prints info about the modules)

I would be very interested in reports whether they work as expected, especially on the firebee. Milan and Hades would also be nice.

[evil]

I would be very interested in reports whether they work as expected, especially on the firebee. Milan and Hades would also be nice.

Falcon test (060/93):
Music sound the same between both during the first Red Bull can screen, but there is bad graphics stuttering in the SDL version.
Going further to more demanding screens the audio starts to stutter too.

The Mikro version is OK from start to end.

[ThorstenOtto]

Thanks for testing. Does the stuttering also happen when you turn music off (option -m)?

And what machine/OS and possible sound drivers you are using?

Edit: ok, i can reproduce it in Hatari, even when emulating a 32Mhz Falcon & with fast-forward.. Seems to be caused by the way SDL handles audio updates (because of missing threads, it is done during timer callbacks). There also seems to be some unneeded work done. Will try to fix that, too.

[evil]

Thanks for testing. Does the stuttering also happen when you turn music off (option -m)?

And what machine/OS and possible sound drivers you are using?

Edit: ok, i can reproduce it in Hatari, even when emulating a 32Mhz Falcon & with fast-forward.. Seems to be caused by the way SDL handles audio updates (because of missing threads, it is done during timer callbacks). There also seems to be some unneeded work done. Will try to fix that, too.

Well I tested anyway, the video stuttering is gone using -m with the SDL version.

The machine is a Falcon with 68060 (full fpu) at 93 MHz. CT60 TOS 1.05, NVDI but no audio driver.
It has a 44100 Hz DSP clock, but I've tested with and without that with the same result.

[ThorstenOtto]

Hm, maybe that demo was not the best choice to test just sound. Without fast-forward on Hatari, even when emulating a 32Mhz Falcon and without music, i get around 2-3 FPS at the start, and 1-2 later. WIth music, even Miro's version stutters.

But there are still differences. I will try to compensate for them.

[mikro]

Btw I'd either contact FireBee guys directly or at least repost the request in the FireBee section. "Sound frequencies on Falcon" aren't exactly eye catching for FireBee users. ;)

[ThorstenOtto]

Yes, i will do that when i'm convinced that all the quirks in SDL are fixed, and that the routines behave at least as good as yours

[marss]

Falcon060+CTPCI+Radeon, the SDL version shows slowdowns sometimes.

[Patrice Mandin]

Just a reminder, for people using Aranym, it's an emulator. IIRC I wrote the codec or sound matrix emulation, and did not bother muting the audio for frequencies that were wrong on a real Falcon. Maybe it should be fixed then.

[Eero Tamminen]

Hm, maybe that demo was not the best choice to test just sound. Without fast-forward on Hatari, even when emulating a 32Mhz Falcon and without music, i get around 2-3 FPS at the start, and 1-2 later. WIth music, even Miro's version stutters.

Be sure to use latest git version of Hatari, there were some bugs in Falcon sound interrupt handling that were only recently discovered & fixed (differences to how DMA works compared e.g. to STE).

[ThorstenOtto]

did not bother muting the audio for frequencies that were wrong on a real Falcon. Maybe it should be fixed then.

That shouldn't be a problem, because such frequencies are simply not used by SDL.

Be sure to use latest git version of Hatari, there were some bugs in Falcon sound interrupt handling that were only recently discovered & fixed (differences to how DMA works compared e.g. to STE).

I am already using the latest git version. Problems here seems to be that the sound buffer is setup for ~83ms of data, which is simply too small when you get only 3 fps. However making it larger would also mean more CPU time to fill it, maybe making the overall performance even worse.