Pandaboard Support

The latest version of the OMAP4 rom thinks only sample rates of 88200 and 96000 are available so RISC OS is defaulting to 88200 instead of 44100 previously.
As long as the sample rate isn’t hard coded in whatever program you are using to play sound you can just change it’s settings to use 88200.

Meastro is clealy not set properly then?

I think Maestro may be wrong anyway. It looks like it is assuming the tempo is based on a default sample rate of 22050.
Changing line 4600 of the !RunImage as follows seems to be about right.

*128*4096DIV6000

to

*128*1024DIV6000

This is tinkering – what about other apps that use sound – like BASIC for example? The beep on booting etc etc.

This is tinkering – what about other apps that use sound – like BASIC for example? The beep on booting etc etc.

I imagine there are loads of programs out there that make assumptions about what the underlying sound hardware is capable of.

what about other apps that use sound – like BASIC for example? The beep on booting etc etc.

Speech in Pluto has gone all “hamster on helium” again, with 5.21.

What advantages does the new ROM bring over 5.19? I’ve only had a brief play, but I can’t see any real difference. I notice “reset” still doesn’t work.

Speech in Pluto has gone all “hamster on helium” again, with 5.21.
What advantages does the new ROM bring over 5.19?

It seems to boot faster, and obviously the sound is faster in use :-0)
Bear in mind it represents the next development on from 5.20, which will be the stabilised version of 5.19.

So if you want 5.19 behaviour without any development bugs -use 5.20 (when it is sanctioned for release)
I think it’s been said many times, don’t use a development version if you insist on stability. There is a warning on the download page.

Speech in Pluto has gone all “hamster on helium” again, with 5.21.

More likely, you’re highlighting how few people actually try the nightly builds. Nothing has been changed in OMAP4 (well, other than the version number going up by 0.02), and I suspect actually a HAL change 8 weeks ago is what you’re seeing.

More likely, you’re highlighting how few people actually try the nightly builds. Nothing has been changed in OMAP4 (well, other than the version number going up by 0.02), and I suspect actually a HAL change 8 weeks ago is what you’re seeing.

This one I presume:

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

One difficulty in trying the daily builds, is that there are problems with the OMAP4 ROM and it is difficult for a simple user to know when one of them has been fixed and is therefore worth trying and testing. It would help massively if the ‘known problems’ with the OMAP4 port were listed and ticked off as they get sorted. I hadn’t thought it necessary to test whether a bug fix had actually introduced problems, especially as they normally say ‘tested on ..’. If they said something like ‘tested on OMAP3 but may have problems on OMAP4 with sound system’ then that might prompt me to test it.

Looks like 5.20 for the OMAP4 and Pi will take a little bit longer than we thought – hopefully a few weeks – at least 5.20 isn’t being released until it is stable.

Sprow, and the fact that Untarbz2 has been broke for years means that either

1. No one uses it to untar the archives or

2. No one downloads the archives or

3. Everyone assumes it works ok.

For me I use 7-zip

Does 7-zip return complete pathnames?

I’ve always used Untarbz2, and more recently I wrote an Obey file to fix up known pathname truncation. It’s a viable option because the affected pathnames only change very rarely.

If it doesn’t replace the tar part of untarbz2 with the binary in this
tar.zip. The problem is that the archives are in ustar format and tar in untarbz2 doesn’t support it.

So long as it is fixed in 5.20, it doesn’t matter. Hopefully the testing has already found this.

5.20/1 are the fixed versions already. The OMAP4 only support samples rates of 88200 and 96000.
Anything that uses SharedSound should be ok. Anything below 88200 is automatically upsampled. Playit, DiskSample, AMPlayer and the system Beep/voices all work correctly.
Anything that uses DigitalRenderer (Unixlib ports mainly) or Speak (Pluto) sound like Alvin and the Chipmunks. Anything else that accesses the RISC OS sound system directly.
Speak is easily fixed. Not sure about DigitalRenderer.

It would help massively if the ‘known problems’ with the OMAP4 port were listed and ticked off as they get sorted.

There isn’t really a list that can be ticked off as such. Some are due to hardware difference, others due to lack of available documentation.

Using a screen mode 1920×1200 > 50Hz refresh causes green speckles to appear on the screen on the PandaBoard ES.
HDMI port non functional. Lack of documentation.
Shutdown/Restart, Ctrl-Break nearly always result in a freeze.
Only sample rates of 88200 and 96000 supported by hardware.
Certain brands of SD card fail to boot if the reset button is pressed. Removing and reinserting the SD card continues the boot.
No support for screen modes using < 256 colours.

There are also at least 2 changes that haven’t made it into CVS yet. The Smartreflex driver (CPU runs much cooler) and the CJE Power control module support. (This solves the problem of shutdown/restart not working).

There are also at least 2 changes that haven’t made it into CVS yet.

Ah! Enlightenment at last. What is the reason, please, that these have not yet made it into CVS?

Anything that uses SharedSound should be ok. Anything below 88200 is automatically upsampled. Playit, DiskSample, AMPlayer and the system Beep/voices all work correctly.

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 too high-pitched. 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 easy to fix please?

Ah! Enlightenment at last. What is the reason, please, that these have not yet made it into CVS?

I’m not sure why they’re not in CVS.

It still works on all but recent roms for the Pandaboard ES, where it is too high-pitched

It must have always been wrong on the Pandaboard. I tried it on a Raspberry Pi and the speed changes if the sample rate changes from the default of 22050. I assume it’s expecting the sample rate to always be 22050.

When I got around to posting about Pluto and eSpeak on RISCOSitory, ISTR including a comment to the effect that the latest version of eSpeak now works correctly on systems that don’t support 22,050 such as the PandaBoard – and that the most recent update to Pluto was to include the latest version of eSpeak.

So if Chris’s suggestion that it must have always been wrong on the PandaBoard is correct, it may be that you just need to upgrade to the most recent version.

There was a change to the HAL 8 weeks ago on the OMAP4 port that started the ‘helium speak’, see above.

Revision 1.14: download – view: text, markup, annotated – select for diffs
Sun Apr 7 08:13:07 2013 UTC (8 weeks, 3 days ago) by rsprowson

Pluto 3.06b 15.04.2013
=======
eSpeak now speaks correctly on systems which have 44100Hz but not 22050Hz audio (eg. PandaBoard).

(My emphasis)

Every 26-bit game I’ve tried on the Pandaboard via Aemulor-pro is plagued by “hellium speak” syndrome, too. I guess these use 22050Hz (or even lower).
Does all this mean that there won’t be support for below-44100Hz sample rates on the Pandaboard, ever?

I first found the Pi is totally unable to run old games via Aemulor and now Pandaboard is going forward without mantaining a minimal backwards compatibility regarding audio sample rates… It’s no good. It was the last machine I had Risc OS running on, waiting patiently for low sample-rates to be supported for years now.

I don’t understand why there’s a problem… sample rate conversion is hardly rocket science. Why is 22.05MHz not supported? It would appear to be trivial.

@nemo, I’m asking myself the same question. Even sub-22050Hz sample rates should be easily supported on the Pandaboard without much work, and it would benefit A LOT of old software. CPU on the Pandaboard is powerful enough to cope with software samplerate conversion without problems at all.
I would even donate money to such a cause, but I don’t know if it’s expected or logical.

Someone took the decision to remove support for slower sample rates 8 weeks ago. Please restore this in 5.20.

Someone took the decision to remove support for slower sample rates 8 weeks ago. Please restore this in 5.20.

Even if the previous sample rates (44100 & 48000) were reinstated it still wont’t help with anything that assumes a 22050 sample rate.

Even if the previous sample rates (44100 & 48000) were reinstated it still wont’t help with anything that assumes a 22050 sample rate.

Yes but a similar ‘kludge’ may be possible?