I have never been too thrilled with the audio quality of the Beagle
Board (blame my days of running live sound for years) so I "thought" I
would work on something to allow it to deliver professional quality
sound. So a few things possibly more questions. I noticed the McBSPX
appear to be rated for 48Mhz as the fastest rate? Is it possible to
push them 49.152mhz? (Ack PRCM looks like I have too peer into).
I probably should have noticed the McBSP2 is not brought to the
expansion connector sooner, but I digress. So I am left with McBSP1
and McBSP3 at the connector. Both of these have a buffer of 128 Words
OR in my case 8 frames deep. (8 channels * 2 {in + out} == 16 128
words/16 = 8 frames of data). I guess I have buffer envy or something
because the McBSP2 has 1024 words or 64 frames of buffering.
Obviously McBSP2 was designed for audio use, and I'm not going to ask
why the McBSP2 was only connected to the TPS65950 (routing issues not
likely, just probably didn't want the expansion header any bigger).
So now the question, in peoples humble opinion (or not so humble LOL),
is the DMA system going to be burdened by 8 + 8 channels at 192ksps if
place on McBSP1 or McBSP3? (1/24000th of a second can be stored in
McBSP1/3 versus 1/3000th in McBSP2). Is this too much for the OMAP3530
period? Is it possible to use McBSP2 in any way shape or form?
Any thoughts or suggestions? I Suppose I can cut the channel count way
down, that would be a depressing, but if you can't use 8 channels in
and out without tying up the processor what's the point? So those who
have spent more time with the hardware make suggestions if possible.
I have an electrically isolated system for the audio to prevent noise
injection from the beagle board itself. The split planes between
beagle land and audio world (pun intended) will keep things clean.
There is a lot of fiddling around with the analog versus digital power
as well just in the separate system. Unfortunately such a design
means you need YAWW (Yet Another Wall Wart) because the 5V supply
generally used with a beagle board won't be enough (audio power draw
is approximately 3.5watts) so a whole separate supply system was
needed (it made isolation easier as well). It looks like I have to
look through the PRCM (you know the technical reference manual should
be called a mini encyclopedia at 3411 pages) module.
Is it possible to
push them 49.152mhz? (Ack PRCM looks like I have too peer into).
I have no personal experience with this but in the “McBSP I2S on Expansion to talk to an Audio Codec” -thread on this list Mr. Nikkilä mentions he has a system like that working.
I don’t think the DMA will have any performance issues with 49Mbps, it is quite a low bit rate after all. I would look at tuning the used FIFO/transfer size and maybe DMA priorities to mitigate possible latency issues.
Is it possible to push them 49.152mhz?
(Ack PRCM looks like I have too peer into).
In case you can hit the actual frequency I think a 5% "overdrive" would work
in the lab/prototyping stage.
That being said I'm not sure I would count on it for mass production or long
time deployment...
Obviously McBSP2 was designed for audio use, and I'm not going to ask
why the McBSP2 was only connected to the TPS65950 (routing issues not
likely, just probably didn't want the expansion header any bigger).
I think main reason was that TPS65950 was the main audio codec considered
when the Beagle was build.
That being said you will have access to McBSP2 on a header in the new
upcoming Beagle-XM
And in case you really want, and you *know* what you are doing you can
actually access the traces doing a little HW rework/soldering on the normal
BeagleBoard as well
So now the question, in peoples humble opinion (or not so humble LOL),
is the DMA system going to be burdened by 8 + 8 channels at 192ksps if
place on McBSP1 or McBSP3? (1/24000th of a second can be stored in
McBSP1/3 versus 1/3000th in McBSP2). Is this too much for the OMAP3530
period? Is it possible to use McBSP2 in any way shape or form?
I think the DMA should be able to keep up with this. Configure it with high
priority and utilize the auto-aiming/looping feature of the SDMA and I think
you should be just fine - For more info on this please have a look at the
OMAP3 TRM SDMA chapter...
It looks like I have to
look through the PRCM (you know the technical reference manual should
be called a mini encyclopedia at 3411 pages) module.
Then you should have a look at the internal design information. I don't know
the exact amount, but I guess it at least ~10 times the size... The TRM is a
nice "short" summary of this
I think the DMA should be able to keep up with this. Configure it with high
priority and utilize the auto-aiming/looping feature of the SDMA and I think
you should be just fine - For more info on this please have a look at the
OMAP3 TRM SDMA chapter...
DSP is another option.
I run audio from the DSP using EDMA with buffers as low as 16 samples
(or 8 samples per channel) at 48khz. Works quite well. I'm using McBSP2
and the TWL4030 codec (yes I still work on my B4 beagleboard).
But I see no reason why the other McBSPs should not work as well. They
have a smaller fifo, but as far as I know the McBSP3 for example still
has fifo for 128 samples (tx and rx path each).
At 48khz for record and playback that would make 750 interrupts/second..
Quite doable.
Oh, and the EDMA3 transfers can be started from the McBSP hardware, so
you don't even have to serve the time critical interrupts yourself.
> OMAP3 TRM SDMA chapter...
DSP is another option.
Agree
But I see no reason why the other McBSPs should not work as well. They
have a smaller fifo, but as far as I know the McBSP3 for example still
has fifo for 128 samples (tx and rx path each).
The FIFO buffer on McBSP2 is 10 times the size of the FIFO for the other
McBSP channels
At 48khz for record and playback that would make 750
interrupts/second.. Quite doable.
Agree, but 192kHz 24bit 8 channels stereo (in+out) as Cyberman wants is
quite larger than this
I though still think it's possible using any of the options....
Oh, and the EDMA3 transfers can be started from the McBSP hardware, so
you don't even have to serve the time critical interrupts yourself.
Again: Agree - And just for information the same can be done using the SDMA
controller
Søren
Agree, but 192kHz 24bit 8 channels stereo (in+out) as Cyberman wants is
quite larger than this
Oh - I haven't read that.. Wow! That is quite a load..
The word-length does not make much of a difference. As far as I know the
McBSP treats all samples as 32 bit, even if the codec just sends 24 or
16 bit..
But for 192khz @ 8 channes, with a McBSP Fifo of 128 samples that would
make 48.000 DMA-transfers per second.
I though still think it's possible using any of the options....
I agree.. It will not be easy, but if the entire DSP code is in internal
memory and all DMA does all transfers into the internal memory there
should be even still a little bit of spare time to do some basic channel
mixing or so..
But not much more..
Again: Agree - And just for information the same can be done using the SDMA
controller
Yep. Well thought out hardware, isn't it?
I love the fact that I can have Linux on the arm with all the tools,
protocol stacks, file-systems ect, and then I have a bare bones DSP with
a dedicated, powerfull DMA controller for the hard real-time stuff.
> Agree, but 192kHz 24bit 8 channels stereo (in+out) as Cyberman wants
> is quite larger than this
Oh - I haven't read that.. Wow! That is quite a load..
The word-length does not make much of a difference. As far as I know
the McBSP treats all samples as 32 bit, even if the codec just sends 24 or
16 bit..
AFAIR (although I admit that I didn't check recently) this is configurable
as well...
But for 192khz @ 8 channes, with a McBSP Fifo of 128 samples that would
make 48.000 DMA-transfers per second.
