Pandaboard Support
Malcolm Hussain-Gambles (1596) 811 posts |
For Aemulor pro I keep getting abort on data transfer for newer roms. |
SeñorNueces (1438) 162 posts |
@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! |
Chris Hall (132) 3548 posts |
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. |
Malcolm Hussain-Gambles (1596) 811 posts |
Unfortunately that didn’t help. |
Chris Gransden (337) 1198 posts |
You can download an updated !Speak module here. This makes speech in Pluto output at the correct speed. |
andym (447) 470 posts |
Works brilliantly, thanks Chris! |
Chris Hall (132) 3548 posts |
Now the Raspberry Pi suffers from ‘helium speak’ in RISC OS 5.21. Can this be fixed please? |
jim lesurf (2082) 1437 posts |
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 |
Rick Murray (539) 13764 posts |
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…
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?
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… |
jim lesurf (2082) 1437 posts |
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 |
Frederick Bambrough (1372) 836 posts |
And unlike Usenet can be posted on the forum. :→ Sorry! Couldn’t resist. |
jim lesurf (2082) 1437 posts |
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 |
David R. Lane (77) 760 posts |
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.) |
Chris Gransden (337) 1198 posts |
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. |
David R. Lane (77) 760 posts |
I have just upgraded my Pandaboard’s OS to RISC OS 5.21 from 5.19. 13:29:43.32 [WindowManager/] Run <CPUClock$Dir>.!RunImage By the way, I can’t find module CallASWI anywhere. Verma does not list it. |
Chris Gransden (337) 1198 posts |
According to the CPUClock download page CPUClock isn’t compatible with the Pandaboard.
I believe CallASWI is only of use on older RISC OS versions (<3.7?). |
Raik (463) 2058 posts |
I mean you can only read the clock speed. Use this . |
Chris Johnson (125) 825 posts |
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. |
Rick Murray (539) 13764 posts |
You don’t need it.
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… |
Rick Murray (539) 13764 posts |
Chris – same story on the Pi, errors with the various reason codes. Oh well. |
David R. Lane (77) 760 posts |
!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? |
Martin Avison (27) 1480 posts |
Is something looping … or at least using large amounts of processor? TaskUsage would tell you! |
Chris Gransden (337) 1198 posts |
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. |
Rick Murray (539) 13764 posts |
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. |
David R. Lane (77) 760 posts |
@Martin Avison @Chris Gransden |