RO Sound System document

I’ve just made a ‘beta’ (rough incomplete) version of a document I’m writing on the ROSS (RO Sound System) available at

http://jcgl.orpheusweb.co.uk/temp/Rossbeta.pdf

I’d welcome (erm.. polite) feedback on errors and omissions. Please note I have also already listed some omissions I intend to cover at the end of the beta version. But if there are other areas I should consider, please let me know. The final version should also have a contents list, etc. But I won’t do that until the document is essentially complete.

The aim is a document that will be useful for users and programmers as an overview with examples as illustrations. There will be a ‘reference’ section listing all the relevant swi details, etc, but the aim is more explanatory.

Having considered the feedback I’ll do a fuller version and make that available.

Cheers,

Jim

I know very little about the sound system, but that looks to me like an excellent introduction. Afraid I don’t have any more feedback than that ;-)

I know very little about the sound system, but that looks to me like an excellent introduction. Afraid I don’t have any more feedback than that ;-)

Fairy snuff. :-) In general I’m happy to adopt the maxim: Silence may be construed as consent. ;→

The only detailed comment I’ve had so far (via email) is wrt the meanings of ‘driver’ and ‘handler’. When I’ve looked at various documents the useages I’ve found have been occasionally inconsistent, and hence potentially confusing. So FWIW I’m planning to add explicit definitions of the meanings I have adopted when I do the updated and expanded version.

Jim

Silence may be construed as consent

All seemed reasonable – the text needs to be spell and grammar checked (there’s at least one “and, and, and” element)

Mostly people probably aren’t sure how it all hangs together and what you’ve assembled is probably more documentation than ever existed anywhere.

I’ve had a chance to read through the doc now. It looks good; the only factual error I spotted was this one: “There is an excellent player‘ program written by Jeffrey Lee” – if you tried looking at the output it produces when you play lots of sounds at once (to produce clipping/overflow) or play a sound which isn’t at the system sample rate you wouldn’t describe it as excellent ;)

Also, from the DigitalRenderer section: “Note, though, that some hardware may have its left-right connections swapped over!” – SoundDMA accepts data with the standard VIDC channel ordering (right channel in low 16 bits, left channel in high 16 bits), and has support for swapping the stereo channels if the hardware requires it. So it’s worth clarifying in the doc that for situations where the stereo channels are incorrect (just OMAP4 devices and the Pandora, I think?), it’s an OS/hardware driver bug and not a permanent “feature”.

All seemed reasonable – the text needs to be spell and grammar checked (there’s at least one “and, and, and” element)

Yes. About par for my usual rough drafts. Decided it would be more useful to let the dog see the rabbit before carefully fixing the English of sections I might well end up having to change anyway! :-)

Seems a bit strange for a programmer to say that
A and B and C
isn’t allowed. 8-]

In honesty, I did take five goes before I managed to scrape a pass at English Language O level mumble decades ago. Which may seem odd for someone who has since enjoyed writing lots of articles, books, webpages, etc. However my problem has always been a form of what people have come to call ‘liz dexia’. I keep reading what I meant to write. I have to leave what I’ve written alone for a few days and do something else to ‘clear my mind’ before I can spot many errors. This is one of the reasons I tend to do a draft that seems about right for content, then leave alone for a time before looking again at it. I also find it harder to read a screen display than ink on paper. But I’ll keep trying. :-)

Jim

…if you tried looking at the output it produces when you play lots of sounds at once (to produce clipping/overflow) or play a sound which isn’t at the system sample rate you wouldn’t describe it as excellent ;)

I think you are being a bit modest here. :-) However I’d say that it is, indeed, excellent as a clear demo of how to use the module to play audio. Beyond that, I’d point to something I comment on lower down this posting wrt resampling.

FWIW I wish I had something as clear as an example for direct playing to SoundDMA 16bit! I still haven’t fathomed that, despite having twigged how to use DigitalRender.

…So it’s worth clarifying in the doc that for situations where the stereo channels are incorrect (just OMAP4 devices and the Pandora, I think?), it’s an OS/hardware driver bug and not a permanent “feature”.

Good point. Yes, noted. Although I’ll have to take care as one drawback of a forum for me is that I can’t keep and search the results using !Pluto. I keep losing / forgetting things on the forum. :-/

BTW Jeffrey, I recall reading a posting I think you made on the forum wrt clipping in OMAP3. Can you recall what that was about and what you did? I can’t now find it again.

Also, whilst drifting OT. I’ve almost finished some demo progs for improved ‘upsampling’ using TDF methods. One plays out via DR the other creates an x2 upsampled wave file that can be played more conventionally. I’m hoping people will be able to use this to assess how to include better resampling in the ROSS at some future point. As usual my programming is clumsy, but I’m hoping the programs will illustrate what can be done.

Jim

As usual my programming is clumsy, but I’m hoping the programs will illustrate what can be done.

Here’s an example of the results just to give an idea.

http://jcgl.orpheusweb.co.uk/temp/betterup.png

This was produced by starting with a white noise 44.1k wave file. Then upsampling it to 88.2k using the various methods listed. The spectra are of the contents of the resulting 88.2k files.

Ideally, they’d show a horizontal line at about -52dBFS from low frequency up to 22kHz. Then drop to nothing at frequencies above 22kHz.

Everything above 22k is unwanted ultrasonic (aliasing) distortions.

Linear interpolation is, erm, to use the technical term audio engineers would apply – crap. The treble is rolled down and there is bucketloads of aliasing garbage above 22kHz.

The TDFs give various better results. With (as predictable to people familiar with the topic) the Hamming window sinc TDF doing about best of the selection shown.

In practice this means that I and others can play out at better quality via using 88.2k system rate on an ARMiniX or similar for 44.1k source material this way than by using the standard linear interpolation. Another nice thing is the user can choose. FWIW I plan to add a asymmetric filter sometime that gives results audio fans would call ‘causal’ or ‘aperiodic’. But my main purpose here is to illustrate what should be possible and to show the code, etc, as crude examples.

Jim

Just to say, I found this document very helpful, particularly the coverage of the PlayIt module. I’d come across it before but hadn’t realised how useful it could be (even though it is documented, it’s finding out what is available and appropriate that can be tricky for someone fairly new to the platform). Well done!

FWIW I’ve now released the ‘upsampling’ demo apps I’ve been working on. Anyone interested can find them via

http://www.audiomisc.co.uk/software/ARMiniX/Upsampling.html

Tomorrow (weather permitting) will be gardening for me. After that I plan to get back to working on the ROSS document. :-)

Jim

I realise you are not so interested in the 8 bit sound but I wanted to bring to your attention that I rewrote a couple of sound modules generators. These are probably the easiest way to incorporate sound into an application.

I rewrote !wavegen earlier in the year, this creates periodic waveform voice modules. I stitched in some code from the castle source, it appears to be HAL Test code, that being the case that should mean that it has a high likelyhood of it to continue working going forward. I think though being periodic waveforms, it is only of limited value. But I used it to generate new waveforms to update a function generator program. It could be used to update other voice modules in legacy programs etc.

More widely useful is my !Voicegn32, I can’t remember the origin of this program I think its a rewrite, it only took me a few days so I can’t remember it well. !Voicegn32 which will make new voice modules, similar to the those in the game !minesweep. This could be used to create new modules for updating old programs or new voices where requirements are not too demanding.

Currently they are available at links on David Saunders website, I should make them more widely available so any suggestions on that would be appreicated

If you look in anouncements here Feb/March 2013 you should find a link to them.

…to save a couple of clicks, that’s Announcing 32-Bit Compatible Periodic Voice Module Generator.

Are there any ideas for the 8bit sound system to use 16bit samples? – ie for programs like ‘Rhapsody4’ and ‘Sibelius’.

I realise you are not so interested in the 8 bit sound but I wanted to bring to your attention that I rewrote a couple of sound modules generators. These are probably the easiest way to incorporate sound into an application.

At present I’ve re-started work on the ROSS document I’m writing and am adding info on the CD Audio side. As you say, I’m not personally that interested in ‘8 bit’. And its not an area I know beyond what is in the PRMs. However if what you’ve been doing isn’t covered in the old PRMs I’d be happy to have in included into the new documentation. That makes sense to me.

That said, I don’t know if it is something I will/can do. May prefer to leave it to someone else. For now, I’d suggest that you nudge me again once I’ve done what I think is a “final for now release candidate” of the expanded ROSS document I’m working on at present. We can then decide if I’ll try and add 8-bit “update” info, or someone else should do it.

My idea about the ROSS document I’m working on is that what I produce won’t be “full and final”, but something I and others are welcome to add to as time passes. So I’ve no objection to others either requesting I do items, or doing sections themself for addition. I’m also assuming that material which is already well covered by the old PRMs need not be included, unless useful as a basis for explaining other things.

It occurs to me, prompted by what you said:

I’ve been intending to include a ‘reference’ section listing details of the various SWIs/commands that the PRMs don’t cover. Maybe there should also be a section that just lists ‘useful items’ for the ROSS/RO audio with brief descriptions and a URL where relevant? The challenge may be to compile that and keep it up-to-date.

Jim

An area I’m currently uncertain about is wrt audio inputs and how/if to cover them in an initial ROSS document.

The problem here is that the audio input arrangements people have used for previous hardware tend to be a set of specific ‘add on’ solutions. Ranging from using the AudioIn module on an Iyonix to old cards like Lark, etc. Before that relying on IO methods inherited from the BBC B era.

Hence its hard to decide what would make sense in a situation where increasingly many people will be using something like an RPi or PandaBoard, and which may – as yet – not even have working and documentable audio inputs (apart from Audio CD which I’m covering as a seperate issue.)

I have been tempted to deal with AudioIn as still fairly ‘current’ due to the Iyonix. But I’m uncertain how much sense this will make a year or two from now. May be better for me to postpone audio inputs until the RPi/PandaBoard era has resolved itself in this direction more clearly. (Given the work on USB audio input as well as output, and hope for an extended HAL, etc.)

Comments welcome. :-)

Jim

Please don’t leave out the SharedSoundBuffer etc modules from John Duffell that enabled me to get Squeak generating its noises. I found them extremely useful, understandable and flexible. IMO they really ought to be part of the base ROS distribution. (I could have sworn that I spotted copies of the sources in the ROOL CVS tree but I can’t see anything right now)

Lots of discussion in https://www.riscosopen.org/forum/forums/11/topics/1629 including the crucial point that the latest versions are not on John’s site!.

Please also try to cover MIDI, especially any way we can access the MIDI general instrument list sounds.

Please also try to cover MIDI, especially any way we can access the MIDI general instrument list sounds.

You know, I wrote a module for that. ;-)

Mostly clones the Acorn MIDI module from back in the ’80s, only talking now to modern USB hardware.

Incidentally, I’m not sure that a sound handler should be dealing with MIDI, any more than you might expect it to understand tracker files.

Please don’t leave out the SharedSoundBuffer etc modules from John Duffell…

Noted. Good point. I’ll see what I can do.

I’m less sure about midi. Might be better for someone else who uses it and is familiar with it to document that. Although if people point out the relevant existing docs I can look sometime.

Jim

So where is the current/most up-to-date version of SSBuffer, etc, and its documentation? I just scanned though the 1629 thread but didn’t find this.

I recall finding the Duffel page some time ago, but don’t know now what version I was looking at, or where!

Jim

Is it maintained by Andy Sellors?

Is it maintained by Andy Sellors?

Dunno, but I’ll follow that up unless someone tells me differently.

Cheers,

Jim

I’ve found an Andy Sellors version as well as the Duffel version. However I’m none the wiser about how to go about writing a simple demo that I could use to illustrate how to use it for the purpose of the ROSS document. And I didn’t see a modern version of the SoundFS which would be good.

i.e. I have a list of SWI/API and some example programs. But no real documentation of how to use these. Can anyone help? I can see if I can contact Andy and/or John, but at present I’m stumped.

Jim

Yes, the latest and most functional code is at Andy’s place. John did turn up on the other thread and promised to do something with it but so far as I can tell nothing has changed yet.

As for an example… well I must have found one somewhere in all that in order to understand it enough to make Squeak sound work… buggered if I can remember which one though. Oh, wait, my notes in the Squeak VM code say " Furthermore, my understanding of how to make use of John’s modules relied on reading Andrew Sellors excellent code for !RDPClient." so that must have been it.

You might gain some enlightenment from looking at my file at
http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/RiscOS/plugins/SoundPlugin/sqRPCSound.c?view=markup
(hope that actually works and gets you to the file?). The early part is wrapping of the module calls that would likely be useful to pretty much any user (in C, anyway) but the later code is rather Squeak specific and likely to be worse that Greek to you.

Though actually, looking at it, try this
Consider a loop running in your app
startup with sample rate, your buffer size etc
while samples to play
if available space > 0
play (available space) samples from my buffer
wait on a semaphore or busy wait or sit on an event or just a timer, whatever
goto beginning of loop
close down sounds

That is done with –
a) soundInit() – get things initialised before going any further.
b) snd_Start() – tells the module(s) what we are going to do, what sample rate etc; all passed in from Squeak. Ignore the ’semaIndex and setupSoundSignalling() since that is Squeak stuff to do with passing the info back into Smalltalk land. We set the dynamic area limits, open a stream , set the buffer size, volume, the poll word (important!) and then make sure it is paused. All the rest is to handle failing any earlier parts. Also quite important in order to keep your machine running.
c) snd_AvailableSpace returns how much room there currently is empty and ready to be filled with samples. Smalltalk code then use…
d) and_PlaySamplesFromAtLength() to fill the buffer from the Smalltalk array of samples that it has generated either programmatically or by reading a file or by mixing both. It adds a block of buffer (reusing space when possible, all neatly done in the module) and copies data into it. Really nice and simple!
e) snd_Stop/Volume/SetVolume are pretty obvious

I hope that made some sense….

MIDI general instrument sounds – Rick, did your module provide those? I’m not sure there is a great deal of MIDI use I could see happening but being able to play those standard sounds is quite important to akin Scratch run nicely on the Pi. Raspbian should, theoretically handle it but I can’t find any sense in any of the unixy midi related libraries. In fact they are so bad the Scratch running on unices hasn’t correctly handled the sounds since 2005. T’would be nice to beat them…

MIDI general instrument sounds – Rick, did your module provide those?

No. It provides a MIDI interface, not a synth translation layer, though I am aware that such things as SoundFont exist. Unfortunately I think that implementing it may be above my current capabilities as I would need to write my own sound handler – I can’t just throw commands at the RISC OS voices as basic General MIDI specifies “at least” 16 voices, plus after touch and key pressure and sustain make a lot of modification of the sound in real time…and given my <cough>(in)abilities mathematically…<sigh!>