I'd appreciate some pointers to sites which could explain to me some
details on
1. Using a flash card (i.e. SD) to store MP3 data
2. Using a (powerful, i.e. PowerPC) controller to read the bit stream
3. Perform the decoding, outputting to a DAC

Point three I can find much info but I'm having problems finding info
on one and two. I'm interested if a TOC or similar is used on the flash
devices in order for the host controller to determine the number of
tracks etc.

Any links would be appreciated.

Thanks

myusenetaccount@yahoo.co.uk wrote:
Easiest way is to get a USB SD reader.

Of course, you need USB host support on the PPC.

MP3s are files, not tracks, in most implementations.

linnix wrote:

Depends on the PowerPC. Easiest way is more likely to use GPIOs or the
on-chip SPI controller, if they have any.

Yep of course. Sorry. So the controller would look through the files on
the external file system reading header info from each mp3 file to
determine track name / lenght etc. Right?
Any links to how this is done in practice?

look for yampp
d.

MyUsenetAccount wrote:
Yes, there is a header at the beginning of each mp3 file.

Same as reading/writing any files on the flash, usually FAT file
system.
Most OS would have FAT fs on USB drives/readers. You might have
to do it yourself on SPI.

linnix wrote:

What is with this USB fetish?

Most OS that have a FAT filesystem would be properly designed, with a
layered driver model. The filesystem driver would not care if it is
reading from SPI or from USB or from anything else, for that matter.

As a point of order, a "USB" block device is really an ATAPI device on
top of a USB transport layer.

Thanks but this implementation uses a dedicated decoding chip. I'm
looking for infos on using a controller to do this.

innix wrote:
So I require a fat32 file system on the controller which uses the SPI
driver to read the files back. I should check the interface that the
file system requires the SPI driver to support, right? I gather that
NOT all file systems expect the same interface or is it OS dependant?
Thank

Thanks but this implementation uses a dedicated decoding chip. I'm
looking for infos on using a controller to do this.

innix wrote:
So I require a fat32 file system on the controller which uses the SPI
driver to read the files back. I should check the interface that the
file system requires the SPI driver to support, right? I gather that
NOT all file systems expect the same interface or is it OS dependant?
Thanks

MyUsenetAccount wrote:

The interface between FS and block device driver is OS dependent.

If you are not using an OS, one free FAT filesystem for you to play
with is mine, http://www.zws.com/products/dosfs/

Thanks for the quick response, and sorry all for the double post.

is POSIX complaint then it is clear what the driver interface (open,
read, etc.) will be right?

for the subject.

Thank all for helping my understanding.

larwe wrote:


And a great help it is! BTW some time ago I sent you some
patches at zws.com for it (one involving pointer underrun
is necessary); please let me know if you got 'em.

Regards,

Michael Grigoni
Cybertheque Museum

MyUsenetAccount wrote:
Could be done, but not currently done for most os.

Implementations are os specific. USB storage devices with Fat/Fat32
are standard for Windows and Linux.

Hi!

I didn't get those. I have cyclic problems with antispam measures being
enforced upstream of me. Some days I'll receive four thousand bounced
spams that had zws.com/larwe.com return addresses. Some days I won't
receive any mail at all. Please resend

MyUsenetAccount wrote:

I'm on shaky ground here, but I believe the answer to this is no. POSIX
standardizes what the app layer sees. The way the OS talks to internal
FS components is not part of this equation.

Windows XP has a token POSIX compliance, but XP device drivers,
including installable file systems, are in no way compliant with any
kind of published standard.