On Tuesday, November 6, 2001, at 08:59 PM, newtontalk_at_newtontalk.net
wrote:
> I've completed some tests with my port of MAD, a MP3 decoder written in
> C by Robert Lesile (http://www.mars.org/home/rob/proj/mpeg) and I
> thought I let you know how far I got. But first of all, I have to say
> that MAD is an extremely nice software package. I think Robert did an
> outstanding job to create not only a fully functional but also portable
> and modular MP3 decoder library.
Well, THERE'S the biggest news of the month. Eckhart has ported an MP3
player.
Looking at MAD, yep, it's exactly the code we were so desperate for in
the previous mp3 porting attempt. I ported mpg123, but as it was
designed to run under Linux, it was *floating-point* (read: way too
slow), and its memory allocation was too high to all fit in the C++
heap. :-(
And without further adieu, lots of technical discussion most people
could care less about:
> Actual values I used for a 56kbit/s stream with
> a 44.1 khz sampling rate were 7KB for the input buffer and 30KB for
> the output buffer. Total minimum memory requirements are currently about
> 50KB on the system heap, that can be reduced however by optimizing the
> synthesizer part.
50KB is just fine for allocation in the C++ heap space. It's what a
typical Waba app allocates, so it should run without a problem on an
MP2K.
> Now the important question: does it work? Yes. But there needs to be
> work done on the output side. The PCM samples are now crudely rescaled
> from 32 bit signed stereo to 16 bit unsigned mono and the sample rate is
> divided by two. This can and should be made configurable.
Hmmmm....could you be more specific here? 16 bit *unsigned*? I'd
assume it's treated as 16-bit signed. Why divide the rate by 2? I'd
assume that NOS can downsample better than we'd be able to (it permits
arbitrary downsampling). If you can output to 16-bit MuLaw compansion
rather than 16-bit linear, it'd give better quality; does MAD provide
this option? And of course to convert from stereo to mono, average the
samples.
> More important
> seems to me a nice layer for feeding the samples to a sound channel,
> ideally in batches of one to two second sized samples. Another problem
> might be playing MP3 streams since the network layer of the Newton OS is
> probably to slow for anything above 56kbit/s (unless you go down to the
> driver level).
Which is exactly what should be done! Contact Paul Guyot and Roger
Milne about communicating with the sound driver at the C++ level rather
than the NewtonScript level, which has way too much overhead. As to the
buffers you're using: one slowdown for you may be that you always have
to lock the binary and unlock it each time you send samples out. That's
expensive. An option is to use a VBO instead, which has a lower
likelihood of getting moved around and so you can probably lock it once
and unlock it when you're finished playing. You can also lock the
binary object in your NewtonScript heap: it'll just make the NS garbage
collector angry because it the memory can't be grouped together nicely.
See the actual source code implementation of the WITH_LOCKED_BINARY for
more hints.
You'll also need a way to wrap up an MP3 file and store it on the
Newton. Have I got a present for you: Steve Weyer put quite a lot of
effort into making Java tools which bundle up binary stuff (images,
class files, etc.) into packages. I imagine he could easily make a
Java-based stuffer for you. It comes with a nice API for accessing the
data as well.
Great news, Eckhart!
Sean
-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.2 : Sat Dec 01 2001 - 20:02:15 EST