Sanitising Sound_Control

One of the things that annoys me about sound on RISC OS is the way that changing the system sample rate results in the system beep and other sounds (e.g. Maestro) changing in pitch/duration.

After investigating the issue today it looks like this is all down to the behaviour of Sound_Control, the SWI which ultimately gets used whenever something wants to play an 8-bit sound. Sound_Control is meant to play a sound at a given frequency (typically specified in octaves) and for a specified duration (specified in 5cs units). But the calculations it performs when converting those values to internal units are designed around the standard VIDC sample rate of 20833Hz and buffer period of 1cs. So if you’re using anything other than the default sound settings, chances are any standard 8-bit sounds will be wrong.

As far as I know Sound_Control has been like this since the dawn of time, so it’s possible there’s some software out there which already contains workarounds for its quirks. But that shouldn’t be any reason for us not to fix it. So I’m proposing the following solution:

• Make the *Tuning value get adjusted automatically whenever the sample rate changes (*Tuning is capable of correcting the pitch, but currently must be set manually, making it rather useless)
• Fix Sound_Control to correctly calculate the buffer fill count (i.e. sound duration) instead of just multiplying the input value by 5
• This new behaviour will be on by default, but I’ll probably add a new option (‘*Tuning auto <on|off>’?) which people can use to turn it off if required.

Any thoughts?

Sounds like this will be another brilliant improvement. Will the proposed buffer fill count calcs carry with them any significant FP implications? Does Sound_Control need to calculate this each time or can it use a value only recalculated (and stored elsewhere) whenever the settings are changed?

Calculating the right buffer fill count is easily done in fixed point math; there shouldn’t be any performance penalty.

I presume that the module “PlayIt” converts the various samples and the data code like SSound drive the various hardware.
Is there a copy of the “PlayIt” source available to download?

Yes, we have it. We’ve made it open source, so please get in touch. I’m awaiting the latest changes from Willi and then it’ll be publicly downloadable somewhere.

Future versions of !PlayIt should ship with source.

Future versions of !PlayIt should ship with source.

Is it possible this’ll be included in a future ROOL disc image?

So that is why the sysem beep goes funny after using something like !DigitalCD or !MusicMan to play 44.1/16 tracks.

Once the source is available !PlayIt needs to be permanently modified so that it talks straight to SharedSound so that Jeffrey’s program to do this isn’t required.

!PlayIt does not access any sound hardware by itself; this is solely done by the loaded driver. And therefore Jeffrey’s SharedSound driver should be part of !PlayIt distribution.

I am just awaiting Jeffrey’s approval on that point, Willi. I have sent him a proposed !PlayIt distribution with application and source. I also need to sanitise some of the docs, as Rick has asked that we (collectively) be the point of contact, rather than him in future.

I am just awaiting Jeffrey’s approval on that point, Willi. I have sent him a proposed !PlayIt distribution with application and source.

Yep – I saw your email last night but didn’t get round to replying to it.

Getting back to Sound_Control: For this automatic tuning to work cleanly, I think we could do with extending Service_Sound with a few new reason codes:

• Reason 8 – Sample rate/buffer size changed
  • R0 = 8
  • R1 = &54
  • R2 = Samples per buffer
  • R3 = Sample rate, in 1/1024Hz (same as Sound_SampleRate)
  • This call will be generated by SoundDMA when the sound sample rate/buffer size changes. The call will be made with interrupts disabled to ensure software is notified of the change before the next buffer fill is triggered.
• Reason 9 – Audio enabled
  • R0 = 9
  • R1 = &54
  • This call will be generated by SoundDMA when sound is about to be enabled. Interrupt status undefined.
• Reason 10 – Audio disabled
  • R0 = 10
  • R1 = &54
  • This call will be generated by SoundDMA just after sound output has just been disabled. Interrupt status undefined.

The automatic *Tuning only needs reason 8, but since there’s currently no notification for when audio starts/stops I figured it would be a good idea to add some reason codes for those as well.

The only problem is that I can’t think of an easy way for software to check if the version of SoundDMA in use provides the above service calls. They can’t just check the version number since we’ve got three different branches of SoundDMA in use (ick!), and we’d still end up with conflicts with ROL’s version(s) as well. There are plenty of SWIs spare, so we could add a new one for checking module features, or we could just tack an extra reason code onto Sound_Mode.

The only problem is that I can’t think of an easy way for software to check if the version of SoundDMA in use provides the above service calls. They can’t just check the version number since we’ve got three different branches of SoundDMA in use (ick!), and we’d still end up with conflicts with ROL’s version(s) as well. There are plenty of SWIs spare, so we could add a new one for checking module features, or we could just tack an extra reason code onto Sound_Mode.

Sound_ReadSysInfo ? We have OS_ReadSysInfo and Wimp_ReadSysInfo after all…

Sound_ReadSysInfo ?

Makes sense to me. I guess adding an extra SWI was always going to be the best solution. There’s other information it might need to return in future, e.g. when we get the sound recording API sorted out we need a way of indicating whether the input and output sample rates must match (OMAP) or whether they can be different (Iyonix).

As I’ve failed to locate a more appropriate thread, I’m posting this here in case it’s of some interest to someone who’s not seen it before. If not, please ignore.

• Psychoacoustic audio coding on small ARM CPUs (2005/06 uni thesis)

As I’ve failed to locate a more appropriate thread

If you can’t find an appropriate thread, you can always create a new one.

Back on topic – the auto tuning code is now mostly working, but there are a few issues remaining:

• Tempo seems to be related to the number of buffer fills per second. So if you double the sample rate without doubling the buffer size then Maestro will tunes twice as quickly. I haven’t yet checked whether this is by design (i.e. buffer fills are supposed to occur at roughly 100Hz, and anything which adjusts the sample rate without adjusting the buffer size is broken) or whether it’s another bug.
• The string lib voices don’t seem to be scaling their duration correctly. I haven’t checked the exact cause, but it doesn’t seem to be down to the buffer fill rate.
• WaveSynth-Beep sounds OK for rates between 20kHz and 44kHz, but when I put the sample rate up to the BB’s max of 96kHz it sounded rather different. I think the amplitude attack/delay rates aren’t being adjusted properly, so the sound starts/stops abruptly at higher sample rates. It’s possible this is down to the buffer fill rate being wrong (I didn’t check), but at rates above 51.2kHz there’s no guarantee you’d be able to get a 100Hz buffer fill rate anyway (4K max DMA buffer size → 512 samples per buffer with 8 channels → max 51.2kHz audio for 100Hz buffer fill rate)
• If you set the sample rate to below 10kHz (IIRC) then the auto tuning won’t work properly, due to limits in the range of values that *Tuning accepts.

I managed to get this code checked in over the weekend. I haven’t tackled the remaining WaveSynth/string lib problems (deciphering how the voice generators work is a bit tricky), but I did have a quick look at the tempo problem. After checking the PRMs it looks like the tempo value is specified relative to a 100Hz base rate, so the problem is that SoundScheduler is assuming that a 100Hz buffer fill rate is in use. So when I get a chance I’ll probably update SoundScheduler to adapt its tempo rate if automatic tuning is enabled (I don’t think there’s much point having a seperate option for automatic tempo).

Documentation for the new service calls here (pretty much the same as listed in this thread, except I inadvertently swapped R2 & R3 during implementation), Sound_ReadSysInfo SWI here, and updated Sound_Tuning SWI here (Not entirely sure why I chose to use a magic parameter instead of adding a new SWI. The fact that the sound modules don’t generate an error when you call unknown SWIs probably had something to do with it.)