13 Jun
2010
13 Jun
'10
7:36 p.m.
On Sun, 2010-06-13 at 12:14 -0700, Rory Filer wrote:
* What's the general flow of the data from
the disk file (or
streaming audio source) to the device driver? Is it: MP3file
-> streaming software -> codec -> driver or// MP3file ->
streaming software -> Codec -> streaming software (e.g. via
callback) -> driver? (or does it even have a standard
approach?)
Ok, the feeding of the audio output is a hard realtime activity (there
are deadlines that must be met or it all goes pearshaped), so normally
what is done is that the data is read from disk and decoded to PCM which
is used to keep a ring buffer full. The ring buffer contents then feed
the audio device driver (often via a separate thread which blocks on the
write to the device).
* That leaves UART. I don't see how a UART
can be made to look
like an audio device unless I write a driver that presents as
an audio interface to Linux and exchanges the audio traffic
between user space at the top-end and the UART on its
bottom-end. Is there an easier way to create an audio
interface out of a UART?
A bigger problem is that you if the bluetooth part is expecting PCM
audio that uart needs to be extremely quick (If say 16 bit, 44.1Khz
stereo then you need 16 * 2 * 44100 = 1.4Mb/s payload rate so somewhere
around 2Mb/s baud rate. You might like to check to see if there is an
existing serial line discipline for bluetooth over serial port using
your part.
Is there not a sync serial port on the device that could be talked into
doing I2S or similar?
If you did go the uart route (I don't recommend it), you could just open
the appropriate serial device and talk to the blue tooth chip directly
from user space. I wouldn't do it if I wanted to support more general
bluetooth functionality, but for an effective point to point link with
known endpoints it should work.
* gstreamer
* MuSE
* madplay
Between the three of these I think I'll be able to figure something
out (needs to be ported to ARM9). Is anyone able to make a
recommendation?
The ARM9 IIRC lacks a good FPU, so a codec that works with fixed point
integer arithmetic has much to recommend it. IIRC libmad fits this
category. gstreamer and Muse are IMHO rather overkill for the
application, for MP3 explicitly I would just use libmad to handle the
decoding, add a lock free ring buffer and whatever shim ends up being
needed to talk to the hardware.
Oh yea, if nothing seems to work, make sure you don't have endian
issues, some folks seem to think that all the world is an X86.
Regards, Dan.