Sound on RISC OS 5.21

A game I have written has worked satisfactorily since 1994 using a sound module to simulate bell sounds (generated by something called ‘KeySound’ – a BASIC programme featured in ‘BBC Micro User’ in August 1990 that allows voices to be designed and generates a sound module with those defined voices for bells, harpsichords, etc.). It still works on all but recent roms for the Pandaboard ES, where it is (i) too high-pitched [see other forum posts] and (ii) not correctly timed [see bug ticket 347]. Any suggestions please? The relevant lines are:

VOICE 1,"UserLib_Harpsicord"
VOICE 2,"UserLib_Bell"
VOICE 3,"UserLib_Vibraphone"
VOICE 4,"Percussion-Soft"

followed by SOUND commands from BASIC.

Repeated such sounds are generated by SoundTest – is this ‘helium behaviour’ easy to fix please (SoundTest itself is not the culprit here)?

Alternatively can someone suggest a tweak to ‘KeySound’ to make it work on modern hardware that cannot emulate earlier behaviour (although it seems this was a deliberate decision by the programmers rather than a change forced by the hardware!).

For the OMAP4 port a HAL change in April 2013 (version 1.14) is probably to blame for this bug:

s/Audio:

    changed recovering from error conditions

    disabled kludge for supporting non native samplerates (44.1 + 48k)

I am pleased to say that the stable build of 5.20 (10-Jun-2013) for the ARMini works correctly and does not suffer from this behaviour. I assume that the 5.20 builds for Risc PC and Iyonix will also be OK.

Meanwhile I recommend that users on the Pi and on the Pandaboard stay with RC8 and RISC OS 5.19 as this needs to be fixed in RISC OS 5.21.

A work around the problem where BASIC expects a sample period of 1cs but where the hardware behaves differently is as follows:

snd%=TRUE
ON ERROR snd%=FALSE
IF snd% THEN SYS “Sound_Configure”,0,0,0,0,0 TO ,r1%,r2% 
IF snd% THEN fsrf=9968/r1%/r2%:REM Fast sample rate fudge 
ON ERROR OFF

IF snd% THEN SOUND a%,b%,c%,d%,e%

IF snd% THEN SOUND a%,b%,c%,d%*fsrf,e%*fsrf

In voice handlers:
PRM 4-74 add after SWI “XSound_Configure”

MOV R2,R2,ASL #8
STR R2,ssrate

For envelope control where tremelo and/or envelope control is applied
once each sample period (previously based on 48us) use actual sample
period, adding each time until 48us is reached:

.GateOn
add after LDMIA R9,{R1-R8}
LDR R8,ssrate ; an unused register between R4 and R8
…
then add some 'GE' conditions to the code below:

B FillGate
.Fill
LDMIA R9,{R1-R8}
.FillGate
ADD R8,R8,R8,LSL #16
CMP R8,#&300000
SUBGE R0,R0,#&300000 ; reset R8 to zero and flag tremelo/env
LDRGEB R0,[R7],#1 ;faster sample rates – only do tremelo
ADDGE R2,R2,R0,ASR #24 ; when was donbe before every 1cs
…
LDRB R0,[R3] ;get amp envelop but only increment pointer
LDRGEB R0,[R3],#1 ;to table every 1cs not every sample period

Hope this helps.

The updated ‘KEYSOUND’ voice generator provides a Bell, Harpsicord and other effects, allowing the haronic content, amplitude envelope and tremelo to be edited and played at 90kHz

Edit correction:
88.2kHz (or, if you select the alternative 96kHz sample rate, 96kHz) on the Pandaboard.

…to be edited and played at 90kHz on the Pandaboard.

Can I suggest that people explictly say either ‘96k’ or ‘’88.2k’ in such cases? It does make a difference to various related issues. And because most audio CD derived and mp3 material tends to be 44.1k, having a system rate of 88.2k has some practical advantages over 96k.

Jim

I would do, but the Pandaboard explicitly reports 90.9090909 kHz.

SYS “Sound_Configure”,0,0,0,0,0 TO ,r1%,r2%
PRINT "Buffer period=";r1%*r2%;"us"
PRINT "Sample rate=";1000/r2%;"kHz"

Buffer period=2288us
Sample rate=90.9090kHz

Edited:
unless you use the more accurate SYS “Sound_SampleRate” which returns the default 88.2kHz (96kHz is also available).

Sound_Configure is a bad choice to use for reading the sample rate on anything above RISC OS 3.1, due to Acorn’s short-sightedness in making it return a sample period measured in microseconds. In fact, in some cases it was even a bad choice to use on RISC OS 3.1 (e.g. if you’re using a monitor type that uses a different VIDC clock rate to the default. Sound_Configure doesn’t return an adjusted value, and even if it did return an adjusted value it would probably have been inaccurate still).

Instead, you should be using Sound_SampleRate, which returns the sample rate in units of 1/1024Hz:

SYS "Sound_SampleRate",1 TO ,,r2%
PRINT "Sample rate=";r2%/1024;"Hz"

Of course, Sound_SampleRate isn’t perfect either, as some VIDC rates aren’t integer values (e.g. 48us is 20833.3Hz recurring). But for modern hardware it’s a lot more accurate than Sound_Configure will be.

Which one does BASIC use to decide the value of the phase accumulator increment (R9+4 in the SCCB) to send to voice handlers to get the desired pitch correct please (which I am glad to say it does)?

For example SOUND 1,-15,pitch,duration,delay for middle C (pitch=53, freq=261.6Hz) sends &C2 on the Pandaboard where I worked out &BC would be correct, using 90.9kHz

Edited:
, but in fact &C2 is correct using the more accurate sound sample rate from SYS “Sound_SampleRate” which is the default 88.2kHz.

FWIW in !SoundCheck I use the following to get rate details

(Sorry the above is a mess. Struggling with ‘textile’. How the devil do you get a block of code to come out right?)

which supports what Jeffrey says. So I’d echo his suggestion.

Occurs to me to try and remember to add a ‘deprecated’ warning to the ROSS document about this and advising people to avoid the unreliable swi.

Jim

How the devil do you get a block of code to come out right?

Surround it with pre and /pre tags inside angle brackets.

Surround it with pre and /pre tags inside angle brackets.

Ok, I’ll try that. I’d tried ‘code’ and ‘notextile’ in angle brackets because I’d read that should work, but nope… Was wondering about trying TT…. However:

 rin.r[0]=1;
 _kernel_swi(mumble,&rin,&rout);
 index=rout.r[1];

Let’s see… Yes! :-)

Thanks,

Jim

BTW Now seen the “90kHz sound” description appear on c.s.a.announce. Hope it doesn’t spread as confusion may result. :-/

Default sound on the Pandaboard is 88.2kHz using the SYS “Sound_SampleRate” to get the accurate figure. 96kHz is also available. Some earlier posts edited.

For a bit more accuracy replace

In voice handlers:
PRM 4-74 add after SWI “XSound_Configure”
...
MOV R2,R2,ASL #8
STR R2,ssrate
LDMFD R13!,{R0-R4,PC}

In voice handlers:
PRM 4-74 add after SWI “XSound_Configure”
...
MOV R2,R2,ASL #8
MOV R0,#0
SWI "Sound_Mode"
CMP R1,#1
MOV R0,R2
MOVEQ R0,#1
SWIEQ "Sound_SampleRate"
LDR R1,ss882
CMP R2,R1
LDREQ R0,ss882+4
LDR R1,ss96
CMP R2,R1
LDREQ R0,ss96+4
STR R0,ssrate
LDMFD R13!,{R0-R4,PC}
.ss882 EQUD 88200*1024
 EQUD 2902 ;11.337us * 256
ss96 96000*1024
 EQUD 2667 ;10.416us*256

When BASIC uses the SOUND command in the form SOUND 1,-15,pitch,duration it should send a pitch increment value in the SCCB to the voice handler that specifies 256 times the number of 1/256ths of a cycle that would correspond to the intended pitch at the prevailing sample rate. On the Pandaboard it gets it right.

For example to sound middle C (261.6Hz) at a sample rate of 96kHz then you need to skip &B2/&100 of the 1/256 of a 261Hz cycle samples (because 261.6*256*256/96000 = &B2) whereas the corresponding value at 88.2kHz is &C2.

On some other platforms (e.g. Iyonix running RISC OS 5.16 and VRPC Adjust) BASIC seems to assume a 20.8kHz sample rate.

A simple test utility can be downloaded here which provides a keyboard simulating several different instruments and offering the user the choice of all the available sample rates to try it at. Sounds quite good on the Pandaboard at 88.2kHz.

BASIC’s SOUND command is just a wrapper for the Sound_Control SWI, which was indeed ‘broken’ ever since its inception as it was (a) assuming sound interrupts/buffer fills occur every centisecond (if a different buffer fill rate was used the sounds would have the wrong duration), and (b) relying on the user to manually adjust the *TUNING value in order to get the correct pitch for the current system sample rate (the default TUNING value assumed 48us sample period, i.e. 20.8kHz). I fixed both of these issues by adding support for the ‘*TUNING AUTO’ option, which defaults to on. However as you’ve already noted there are still problems in other areas of the sound system where a 1cs buffer fill rate is assumed.

I fixed both of these issues by adding support for the ‘*TUNING AUTO’ option, which defaults to on.

Ah-ha! Hadn’t known about that. I must add it to the ROSS document! :-)

Yup. *help tun. shows it.

FWIW I’m currently struggling with all the different documents on SharedSound. These conflict (mainly due to age, etc) and sometimes contain gems that would alarm the Plain English Campaign people. ;→

Jim