Ticket #347 (Fixed)Tue Jul 23 07:32:06 UTC 2013
SOUND tempo misbehaves on OMAP4
| Reported by: | Chris Hall (132) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Chris Hall (132):
The SOUND command fifth parameter is the delay before the sound is produced. On the OMAP4 the sound is produced more quickly (by a factor of two?) than the specified value. The default TEMPO is one beat per centisecond. A (grubby) test programme displays what sound should be being produced (via !Help) for comparison with what you can hear. On OMAP4 these quickly get well out of step but keep in step on other platforms. Test programme here
Changelog:
Modified by Chris Hall (132) Wed, July 24 2013 - 07:50:55 GMT
A simpler test is as follows:
TIME=0:PRINT TEMPO:SOUND 1,-15,100,100,1000:REPEAT:PRINT TIME;" ";:VDU 13:UN.0
The beep should sound after 10s when the displayed count reaches 1000 but it sounds at about 500.
Modified by Jeffrey Lee (213) Sat, July 27 2013 - 15:37:49 GMT
Yes, this is a bug in the sound system (most likely SoundScheduler, which assumes that one buffer = one centisecond). I found this myself when I was working on the *TUNING AUTO code. See here for a little more context:
https://www.riscosopen.org/forum/forums/3/topic…
The built in voice generators (stringlib, wavesynth, etc.) have similar problems where they assume one buffer = one centisecond.
Modified by Chris Hall (132) Tue, September 10 2013 - 15:23:36 GMT
A work around 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 … replace SOUND a%,b%,c%,d%,e% with SOUND a%,b%,c%,d%fsrf,e%fsrf to get duration and delay timing rightIn 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
…
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
LDRB 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.
Modified by Sprow (202) Mon, May 26 2014 - 13:18:14 GMT
- Summary changed from SOUND command misbehaves on OMAP4 to SOUND tempo misbehaves on OMAP4
- Part changed from Unspecified to RISC OS: Module
Noting here for the Pi, the tempo in !Maestro has the opposite problem: too slow.
HandlMes1a 108s (Pi) 90s (Risc PC) HandlMes1b 140s (Pi) 120s (Risc PC)may also be the sound scheduler, or that the internal voices (that !Maestro uses) aren’t honouring the system sampling rate.
Modified by Jeffrey Lee (213) Sat, June 28 2014 - 13:10:49 GMT
- Status changed from Open to Fixed
Tempo calculation and the builtin voice generators should now all be fixed to take into account the current sample rate and buffer size. Due to the accuracy of the math that a lot of the existing code uses things are unlikely to be 100% accurate at any given sample rate, but it should be close enough for most purposes.
For compatibility, tempo calculation can be reverted to the old logic by disabling automatic tuning. However there’s currently no way of reverting the behaviour of the voice generators.
SoundDMA (IOMD) 1.71: https://www.riscosopen.org/viewer/revisions/log…
SoundDMA (HAL) 1.77: https://www.riscosopen.org/viewer/revisions/log…
SoundDMA (Tungsten) 1.68: https://www.riscosopen.org/viewer/revisions/log…
SoundChannels 1.39: https://www.riscosopen.org/viewer/revisions/log…
SoundScheduler 1.31: https://www.riscosopen.org/viewer/revisions/log…
Percussion 1.16: https://www.riscosopen.org/viewer/revisions/log…
StringLib 1.17: https://www.riscosopen.org/viewer/revisions/log…
WaveSynth 1.22: https://www.riscosopen.org/viewer/revisions/log…
