Valid sample rates for XSharedSound_SampleRate

While playing with some byte beats on my RPi I use XSharedSound_SampleRate to set the sample rate. I used e.g. 8000 Hz oder 44100 Hz. Those work. But then I used a slightly different value and the system crashed.

Is there a list which sample rates are valid ?

Hey Kuemmel,
not sure I understand the question correctly, however when you say:

But then I used a slightly different value and the system crashed.

What do you mean exactly? 48 kHz, 88.2 kHz, 96 kHz, etc.? Still in-line with Nyquist rate etc. or just arbitrary numbers?

Yes, arbitrary. I don’t know anything about Nyquist rate. In my case I used 44032, what will end up as 44032*1024 for the SWI. So does it have to be e.g. shift of 48000 or 44100 ?

XSharedSound_SampleRate lets you propose the sample rate that you would prefer but you must not expect it to match the samplerate that will be used, nor that the samplerate will not change while playing. There are 2 reasons for this: first is that it will try to set that sample rate for the real hardware is restricted by the capabilities of the hardware, second is that different applications may propose different samplerates but the sound buffer is shared so only one of them will get the demanded samplerate.

Thanks André, so in other words e.g. in your !DigitalCD application your are doing more steps than that to make sure that e.g. the mp3/wav is played at the desired Sample Rate or may be not using that SWI at all ?

In my scenario (demo coding) we would usually have a freshly booted system like and the most common hardware (Raspberry Pi 2,3,4…) and also per compo rules defined that basically no other applications are running, especially not any apps that would use/play sound.

So in other words, for e.g. the Raspberry Pi series…are there known limitiations on what sample rate would usually work/don’t work when I use XSharedSound_SampleRate to set it ? Or would there be a better way (be aware I’m looking for minimum code size ;-).

Due to lack of an API I have to assume that SoundDMA is the driver used by SharedSound and use the SoundDMA’s Sound_SampleRate API to find from the list of available frequencies, the most appropriate one. Anyway I don’t rely on the value but use the frequency passed in R4 on entry of the buffer filling routine to define a fixed point step to use while copying the samples into the sound buffer.

I hope Jason’s work on the new Sound API will fix that problem.

Note that if you want to minimize code size, I have never used it but SharedSound provides some buffer filling routines that can do the job for you. See SharedSound_InstallHandler (look for R8 on entry of the sound buffer filling routine).

@ Kummel

If you want to be safe you probably want to look at:

https://www.riscosopen.org/wiki/documentation/show/Sound_SampleRate%200

And

https://www.riscosopen.org/wiki/documentation/show/Sound_SampleRate%202

Hope this helps

Thanks all together for the hints. I think I’ll write some code with that SWI’s to dectect and list what sample rates are available on my RPI’s and come back in time with my findings.

So, here’s some code to read it:

ON ERROR PRINT REPORT$ERL:END
SYS "Sound_SampleRate",0 TO,n%
PRINT "Number of available sample rates: ";n%:PRINT
FOR i%=1 TO n%
  SYS "Sound_SampleRate",2,i%TO,,f%
  PRINT "No.";i%;" Sample rate frequency: ";f%>>10
NEXT:A$=GET$

Number of available sample rates: 9
No.1 Sample rate frequency: 8000
No.2 Sample rate frequency: 11025
No.3 Sample rate frequency: 12000
No.4 Sample rate frequency: 16000
No.5 Sample rate frequency: 22050
No.6 Sample rate frequency: 24000
No.7 Sample rate frequency: 32000
No.8 Sample rate frequency: 44100
No.9 Sample rate frequency: 48000

@ Kuemmel

Short explanation: X SWI’s are allowed to generate serious errors, non-X will return.

I think the point is more that both types of SWI can generate serious errors, however the X form will return back to you with V set and R0 (usually) pointing to an error block, whilst non-X SWIs will invoke the error handler, which may have the side effect of tossing your program away! (depends on the environment that is set up)

This is why errors during boot are difficult; if a command gives an error, the command line error handler is raised, the Obey file and all it was doing is discarded, and the boot is pretty much abandoned at that point. What my Harinezumi program does is basically what the boot script does, only it traps errors and reports them and then carries on.

Note that in some situations, using X SWIs is mandatory. Off the top of my head, utilities (as in the RISC OS equivalent of . COM files), ServiceCall handlers, and other places where having errors appear unexpectedly would cause stuff to blow up.