> The wiki (athttp://code.google.com/p/beagleboard/wiki/HowToGetAngstromRunning)
> lists "The Sound Driver" under "Things That Likely Won't Work" and
> adds, "There are significant problems with the Sound Driver to date in
> Angstrom."
> Is this still the case? I'd like to build a MIDI performance device,
> using an embedded beagle board to turn the MIDI stream into an audio
> signal via basic wavetable synthesis. Is the sound driver working
> well enough for this purpose (ie, won't hang on me?)
Well I can't say i've tried it a lot but playing a sound worked with a
very old angstrom demo image. IIRC (and it's been a while), it tended
to be a bit flakey if the device is closed and re-opened, but I could
be confusing that with something else. Still, it would certainly be
enough to get started - you'll be busy enough getting the other
components working that sound can be fixed in the meantime, if it
isn't already.
The hardware is so dead simple, i'm a bit surprised any driver has issues.
Really, the best way to find out what's working and what isn't is to
get a Beagle board, load up a current kernel & filesystem from
Angstrom or Sakoman and try it. Stop reading web pages.
Oh boy this should be in a FAQ ... the number of 'gee why don't you
just try it and let us know's that come up are a bit disappointing.
What happened to curiosity and self-learning? Although I wouldn't
entirely put this question in that category it's pretty close.
a) Boot times vary depending on what kernel / root you've got. There
was a research project last year that got the Beagle to boot in just a
few seconds. Really though it depends on what drivers are active, how
tuned your bootloader is and what user-space services are enabled.
FWIW The last demo angstrom image (which i believe has just been
updated) booted in about 47 seconds from an SD card when I timed it
last (i'd formed a reply to the original mail but didn't send it as I
thought someone with DSP experience might have more to add). 27
seconds from boot until the end of 'udev init', and another 20 seconds
for the rest. This is to an X login window. This is no doubt on the
slow end of things (the udev thing seems to take an age for something
with fixed hardware).
b) The only tools for the build-in DSP are the TI toolchain - C/C++/
Assembly. AFAIK there are no graphic block-oriented patching systems
that would allow you to build up a signal processing flow without
digging into the guts of the hardware, learning the low-level
architecture and understanding the way the DSP and ARM talk to each
other. It's bare metal all the way.
Well aren't there some api's for abstracting the dsp to some extent,
like dsplink and the dsp/bios, and so forth?
The DSP code for the most part would simply be filling buffers with
data. Given that nothing much else would be happening you could just
use the CPU to give that to a sound driver. And even if it was to be
honest, the CPU is pretty fast at moving memory around. The TI
toolchain is the only one available for programming the DSP code
though, but can be downloaded for free.
If you don't mind learning about the hardware, another alternative
would be to disable sound in the kernel and write your own sound
driver directly inside the DSP - if you can set it up to allow the DSP
access to the registers anyway. I believe it has physical access to
the required registers, but setting up the dsp/buios and linux are
another issue. The linux source to me is pretty hairy (mostly because
it supports so many arm boards), so either/or may be easier to
actually achieve.
This is something i've done from the ARM side - this code runs with no os:
http://code.google.com/p/puppybits/source/browse/src/audio-beep/audio-beep.c
The i2c 'driver' is a bit flakey and it lacks is setting up DMA, but
that is pretty easy assuming you have exclusive access to it, and
presumably dsp/bios or whatever DSP OS you run (there are others)
would provide such facilities anyway.
I want to look at it from the DSP side at some point too, but i'm
probably months away from getting to it at the rate with which i'm
moving lately, and with no os it'll probably take a good chunk of time
before I made any progress beyond that. For me it is purely a hobby
so progress tends to be bursty and random at best. and suddenly I have
a lot less time due to work.
!Z