Pandaboard Support

For Aemulor pro I keep getting abort on data transfer for newer roms.
Anything newer than Oct last year.
It seems other people have this working, so I was wondering what this could be. Anyone got any ideas how I can work it out?

@Malcolm: sadly, I have the same problem, so I had to use PandaLand “stable” ROM from may-2012.

44100Hz and 22050Hz sample rates are a must… Please don’t remove 44100Hz sample rate and please add 22050Hz sample rate!

For Aemulor pro I keep getting abort on data transfer for newer roms.

I have Aemulor in !Boot.Choices.Boot.Tasks (not PreDesk) and do not have AODT errors with the 5.21 ROM.

Unfortunately that didn’t help.
I’m also using a Pandaland based build, so I guess there is something specific to that HardDisc Image.
Be interesting to find out what it is.
I have updated my HardDisc Image, but I guess there is something hanging around that shouldn’t be anymore?

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

You can download an updated !Speak module here. This makes speech in Pluto output at the correct speed.

You can download an updated !Speak module here. This makes speech in Pluto output at the correct speed.

Works brilliantly, thanks Chris!

Now the Raspberry Pi suffers from ‘helium speak’ in RISC OS 5.21. Can this be fixed please?

I’ve only just found this thread by accident. I must confess I’m do have some doubts over some of what has been said in the past about what the sound system of the PandaBoard hardware can actually cope with. However I’m not clear about versions, etc.

That said, I think this may underscore one of my general feelings about where Ro audio has lagged behind. Put simply is really should both

A) work correctly for all the hardware-supported rates and allow almost ‘pass the parcel’ delivery of 16bit audio. (And my reading of the specsheets for the TI chip used on the ARminiX PandaBoard makes me think that includes 44.1k and 48k, but I might be wrong.

B) That we really do need some decent resampling interpolation to cope with rates that are non-hardware. Not just linear interpolation or repeating the last sample.

In effect we need something akin to the ALSA alternatives of hw: and plughw: built in at some suitable driver or module layer as well as being able to pass the data when the hardware can accept it.

From brief tests I did a while ago, simply taking out the low rates (44.1k and 48k) simply gives problems like the ones people have mentioned, particularly with *nix-ported things.

Even if 44.1k/48k aren’t hardware direct supported, the present ARminiX situation where you get mono with ultrasonic hash (actually DSBCS modulated 44.1k from the L-R signal) shows that resampling at a suitable layer would work if done without assuming you have to use both input channels to feed both output channels. Just interpolate sensibly. Pretty much like Linux does.

Sorry if this was all obvious to people anyway. Its late so i’m probably rambling now I can finally get to type and see what i’m typing into the letterbox! :-)

Slainte,

Jim

A) work correctly for all the hardware-supported rates and allow almost ‘pass the parcel’ delivery of 16bit audio.

Certainly. Ditto for other hardware, FWIW. If a ‘device’ can work with X, Y, and Z; then RISC OS’s involvement really ought to be minimal. Translating older 8 bit stuff or unsupported sampling rates and bit depths. Otherwise, just take the data and chuck it at the hardware…

That we really do need some decent resampling interpolation to cope with rates that are non-hardware.

Agreed. Sample repetition and such made sense when the systems were old and slow. Can this be said of nowadays? Didn’t I read somewhere that a running USB system fires off thousands of events per second and yet RISC OS is still decently fast? Would it take so much/hurt performance to have smarter interpolation for audio samples?

Sorry if this was all obvious to people anyway.

The general idea is obvious, the implementation less so. I read the nerdy maths stuff in the other thread, and heard that familiar wooosh of something going right over my head… :-( It’s a maths thing…

The general idea is obvious, the implementation less so. I read the nerdy maths stuff in the other thread, and heard that familiar wooosh of something going right over my head… :-( It’s a maths thing…

I’ll draw a diagram and post a link to it. Had to do that to get my own head around what is required. Picture worth many hand-waves. Simple once twigged. :-)

Jim

Picture worth many hand-waves.

And unlike Usenet can be posted on the forum. :→

Sorry! Couldn’t resist.

OK, I’ve now done a short webpage with a diagram. This is the easiest way for me as it (gasp!) includes some equations, etc, as well as a diagram.

http://jcgl.orpheusweb.co.uk/temp/interpolate/over.html

Not as pretty and edited as I’d like. But wanted to produce it and see if it helps. So bypassed my usual stages of tweaking and editing to look better and fix my lousy English.

Jim

Can anyone say how OMAP4 ROM version 5.21 runs on the Pandaboard? Is it as stable as version 5.19? (OK, I know it’s not a ‘stable’ release.)

Can anyone say how OMAP4 ROM version 5.21 runs on the Pandaboard? Is it as stable as version 5.19? (OK, I know it’s not a ‘stable’ release.)

It’s no more or less stable than it was before. On any given day you may get unlucky if a particular change is causing problems. These are usually minor and fixed fairly quickly.

The best thing to do is try it and see making sure you can revert back if you do get problems. The jump from 5.19 to 5.21 involves upgrading !Boot first.

I have just upgraded my Pandaboard’s OS to RISC OS 5.21 from 5.19.
The only problem I have come across so far is that !CPUClock won’t run. On attempting to run it Panda gives a ‘cog wheel’ error. The relevant lines from Martin Avison’s !Reporter are as follows.

13:29:43.32 [WindowManager/] Run <CPUClock$Dir>.!RunImage
13:29:43.33 [Appl/] RMEnsure UtilityModule 3.70 RMEnsure CallASWI 0.02 RMLoad System:Modules.CallASWI
13:29:43.33 [Appl/] RMEnsure FPEmulator 4.03 RMLoad System:Modules.FPEmulator
13:29:43.33 [Appl/] RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib
13:29:43.33 [Appl/01403974] Exec
13:29:43.33 * WimpError * from Invalid Task address: &00000000
Error : &00000000
Message: PortableSpeed2 SWI check failed. The following reason codes produced errors. 0 3 4 5 9 CPUClock cannot continue.
13:29:43.33 [Appl/CPUClock] Exec
13:29:45.87 [WindowManager/] Exec

By the way, I can’t find module CallASWI anywhere. Verma does not list it.

The only problem I have come across so far is that !CPUClock won’t run.

According to the CPUClock download page CPUClock isn’t compatible with the Pandaboard.

By the way, I can’t find module CallASWI anywhere. Verma does not list it.

I believe CallASWI is only of use on older RISC OS versions (<3.7?).

I mean you can only read the clock speed. Use this .

When I wrote CPUClock for the BB, the SWI PortableSpeed2, which CPUClock relies upon, had not been implemented fully in the OMAP4 OS. Because of this, CPUClock runs a check on this SWI when it initialises. As the error box tells you, reason codes 0, 3, 4, 5 and 9 all produced errors when the SWI was called with those reason codes. Thus there is little point CPUClock continuing, since it relies on the values returned from the SWI, so it raises the warning and then quits.

I don’t yet have a PandaBoard, but I believe it is possible to set the cpu clock speed when the board itself boots up (by editing one of the hardware startup files), although it is not possible to change it once RISC OS has booted. I am sure that someone like Chris Gransden could be more authoritative on the subject.

By the way, I can’t find module CallASWI anywhere.

You don’t need it.

13:29:43.33 [Appl/] RMEnsure UtilityModule 3.70 RMEnsure CallASWI 0.02 RMLoad System:Modules.CallASWI

What that is saying is to load CallASWI if you have a version of RISC OS less than 3.70. Later versions have the CallASWI functionality built into RISC OS.

The module may well be somewhere like $.System.310.Modules; but I don’t think anybody bothers to supply it these days. It isn’t necessary for the new machines and it is quite likely the older machines will already have it…

Chris – same story on the Pi, errors with the various reason codes. Oh well.

!CPUClock worked with Panda’s previous RISC OS 5.19. It may be something to do with the previous ROM having ‘Smart Reflex’. It seems that this ROM, RISC OS 5.21, downloaded from the ROOL website doesn’t.

With the previous ROM, on shutdown, a box appeared with several options: Restart, Shutdown and Cancel as I remember it. But now all I get is a Shutdown button that doesn’t work and stiffs Panda. :-((

Just tried Raik’s PB_CPUdetect and it works. Thanks, Raik.

What might be a related matter is the temperature of the OMAP4460 ES1.1 SoC. PB_CPUdetect says that Panda is running at 1200MHz with !CPUTmpMon giving temperatures between 60C and 70C. With the previous ROM (5.19), !CPUClock said, most of the time, that CPU was running at the slow speed, 300MHz I think, with !CPUTmpMon giving lower temperatures between 40C and 50C.

Are any of these temperatures too high for the health of the chip?

Is something looping … or at least using large amounts of processor? TaskUsage would tell you!

!CPUClock worked with Panda’s previous RISC OS 5.19. It may be something to do with the previous ROM having ‘Smart Reflex’. It seems that this ROM, RISC OS 5.21, downloaded from the ROOL website doesn’t.

That explains why it ran previously. You must have gotten the 5.19 ROM from somewhere else as the ‘Smart Reflex’ changes haven’t made it into the ROOL CVS yet.

Are any of these temperatures too high for the health of the chip?

What is the ambient temperature, and do you have any sort of cooling?

My Beagle xM and Pi run around 45-60C with no cooling, and my eeePC runs around 55-65C with a fan. I’m running eeectl to override my fan to speed it up, if the BIOS had its way, the machine would be around 75C!

A TI document I found in a brief search said that the critical junction temperature is 120C, but you should not exceed 110C overall.
That said, a gigahertz and a bit in a package that small with GPU inside and memory on top… It may get warm, yes…

@Martin Avison
Task Usage says 0% for all module tasks and also 0% for everything else. I also have something called Usage with a ‘lookalike’ icon (are they by any chance related?) which says Idle time = 100% and everything else 0%. !CPUTmpMon is saying 65C.

@Chris Gransden
So when is Smart Reflex going to bounce smartly into ROOL CVS?