Jeff Aroonie wrote:
> Question about the ARM MP3 player project.
>
> Why not add support for the SD nibble bus to improve performance?
AFAIK the AT91SAM7S-serie does not have a MCI.

Martin Thomas wrote:
> Jeff Aroonie wrote:
>> Question about the ARM MP3 player project.
>>
>> Why not add support for the SD nibble bus to improve performance?
> AFAIK the AT91SAM7S-serie does not have a MCI.

That just means it's a little more difficult to do.  Certainly not
impossible, I drive the nibble bus via software bitbang.


Any ideas on headroom during playback of mp3?  I've heard the ARM9E has
plenty.  Dunno about this AT91SAM7S.

Jeff Aroonie wrote:
> Martin Thomas wrote:
>> Jeff Aroonie wrote:
>>> Question about the ARM MP3 player project.
>>>
>>> Why not add support for the SD nibble bus to improve performance?
>> AFAIK the AT91SAM7S-serie does not have a MCI.
>
> That just means it's a little more difficult to do.  Certainly not
> impossible, I drive the nibble bus via software bitbang.
So you alread "drive via bitbang". Can you give some rough numbers for
the average transfer-rates achievable during a linear-read of an
unfragmented file from a FAT16 system in 512 byte blocks (=sector size)?
I'm just curious since I currently have an AT91SAM7SE512-board on my
desk where the controller is connected to a extremememory 1GB
"performance" SD-Card though SPI-Bus using very similar code as in the
MP3-player (latest Chan fat-module and block read/write with DMA/PDC).

> Any ideas on headroom during playback of mp3?  I've heard the ARM9E has
> plenty.  Dunno about this AT91SAM7S.
I do not have the hardware here and just now that Andreas had to move
some code to RAM since the flash-slowed down the decoding too much.
Andreas Schwarz created the MP3 player for AT91SAM7S so maybe you can
ask him by e-mail (see end of this page).

Jeff Aroonie wrote:
> Question about the ARM MP3 player project.
>
>
> Why not add support for the SD nibble bus to improve performance?

The bottleneck is the CPU, not the SD card (4 bit SD card interface
isn't supported on the AT91SAM7 anyway, AFAIK).

> How much headroom is left over on the platform?

You can find some numbers for the read and decoding performance in my
article: http://www.mikrocontroller.net/articles/ARM_MP3/AAC_Player

> I'd like to see an mp3
> project that can playback several channels for live mixing.

You won't see this on an ARM7.

Andreas

> You can find some numbers for the read and decoding performance in my
> article: http://www.mikrocontroller.net/articles/ARM_MP3/AAC_Player

I saw those numbers: 2 ms for about 1KB from the SD card (SPI mode) and
16 ms MP3 decode (low bitrate) per frame.  But without knowing the size
of the frame, or the frequency of all these operations, I can't find the
headroom.


>> I'd like to see an mp3
>> project that can playback several channels for live mixing.
>
> You won't see this on an ARM7.

You saw the graph I posted in the above message?  What exactly is ARM9E
doing which allows so much faster mp3 decoding -- under 10% utilization!
I can't imagine it's just cache related, perhaps they are using a very
optimized decoder library?

Jeff Mathews wrote:
>
>> You can find some numbers for the read and decoding performance in my
>> article: http://www.mikrocontroller.net/articles/ARM_MP3/AAC_Player
>
> I saw those numbers: 2 ms for about 1KB from the SD card (SPI mode) and
> 16 ms MP3 decode (low bitrate) per frame.  But without knowing the size
> of the frame, or the frequency of all these operations, I can't find the
> headroom.

One MP3 frame is 26ms long.

>>> I'd like to see an mp3
>>> project that can playback several channels for live mixing.
>>
>> You won't see this on an ARM7.
>
> You saw the graph I posted in the above message?  What exactly is ARM9E
> doing which allows so much faster mp3 decoding -- under 10% utilization!
> I can't imagine it's just cache related, perhaps they are using a very
> optimized decoder library?

It probably has some useful DSP instructions, the library is optimized
for them, and the clock rate is a lot higher. Cache is not the reason,
the internal SRAM on the AT91SAM7 doesn't have wait states, it doesn't
get any faster than that.

> One MP3 frame is 26ms long.

So you're at about 70% utilization... excluding processing for things
that aren't related to SD card reading and decoding.

> It probably has some useful DSP instructions, the library is optimized
> for them, and the clock rate is a lot higher. Cache is not the reason,
> the internal SRAM on the AT91SAM7 doesn't have wait states, it doesn't
> get any faster than that.


Right, you're running at about 1/3 their clock speed.  Assuming you
could get your 18ms of processing per frame down to 6ms with the clock
increase of 3X alone, you'd be at about 20%.  Possibly enough headroom
to run three audio channels!