How many computing power is lefe for a Beaglebone?

Hi,

I have a Beaglebone like board, which has CPU clock rate 800MHz. It runs a Linux. I find an audio project, which needs CPU power 200MIPS for computing. The audio stream can tolerate some latency such as 10mS. To port this audio project to Linux needs some time and a lot of work to do. Now, I would like to know whether this 800MHz ARM Beaglebone board can run through this audio project.

I don't know Linux leaves how much computing power to a user application. Second, I don't know what maximum latency is for this Linux. Do you know the estimation numbers for the two questions, or a simple method to get the results.

Thanks,

Reply to
Robert Willy
Loading thread data ...

Linux is not all one thing. You can also turn off services on the default distribution.

Just guessing, but for more realtime, I'd consider Angstrom over Ubuntu.

Look for an estimate of MIPS/MHz for that processor.

formatting link

I would write a simple CPU hog loop that blocks now and again, does a mess of floating point operations and uses the stuff in time.h to estimate latency.

The stuff in time.h may or may not actually do what you want; in order for it to be useful, you may need a free-running high speed clock in hardware behind it. It works well enough on a Cubie board, so a Beaglebone should be something like that.

formatting link

Here is a guy who's allegedly done a "zero-latency"* convolution reverb with a Beaglebone as a school project:

formatting link

(for interesting values of zero... )

--
Les Cargill
Reply to
Les Cargill

I struggled with a 250 MHz ARM system running Linux for ages trying to get it to handle stuff that sounds similar to your requirements (MIDI?). Gave up in the end, anything below about 50mS using system timers was too chancy, 10mS would have been totally impossible. Ended up porting everything to Windows, using the MS multimedia library, with queue timers for the sequencing. Absolutely no problems experienced with timing.

If you're going to try the Linux system, I suggest you spend some time prototyping simple timing programs. in my case the problems were clearly apparent with the simplest code snippets. And performance on a

3 GHz desktop running Ubuntu/Debian was not much better, indicating that CPU speed wasn't the problem.

I've had comments from Linux gurus (which I aren't) that the only way to get that OS firing well with real time is to use a real time kernel.

--
This email has been checked for viruses by Avast antivirus software. 
https://www.avast.com/antivirus
Reply to
Bruce Varley

Did you use the real time scheduler? I think 10ms on a beagleboune sounds a bit iffy but not outrageous. Basic task switching time is quite fast, like tens of uS. It seems easy enough to run a simple test, e.g. with a cpu-busy user process and a real time process that bangs a gpio pin and sleeps for a few ms. Then monitor the pin with a scope or even one of the Beaglebone PRU's and see if there are any too-long pauses.

Reply to
Paul Rubin

the standard kernel (even with the RT scheduler) is not enough if you want low latency. You need a hard real time kernel, try Linux RTAI or Linux Xenomai.

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
Reply to
Jack

Thanks for the replies. The application project is digital audio replay. The 10mS I gave may be large than expected. The C project is from a audio signal processing firm. Its implementation includes embedded ARM Linux, but I don't have an accurate number of the latency. There is a website discussing about ALSA audio driver. I don't look into it yet. I would like to get an idea about the latency to avoid a big surprise afterwards. Your info about it is highly welcome.

Thanks,

Reply to
Robert Willy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.