On Tuesday, November 6, 2001, at 06:55 Uhr, Sean Luke wrote:
> 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. :-(
MAD is really excellent code... not quite fully documented but
clear and easy to understand. I also looked through the work you,
Paul and the others did before, that proved to be quite insightful.
> Hmmmm....could you be more specific here? 16 bit *unsigned*? I'd
> assume it's treated as 16-bit signed.
Well, it wasn't really clear from the NPG (the NPG 2.1 addendum
says at one point 16 bit signed but that's it) and other
documentation what the Newton actually wants. I tried 16 bit
signed, but that sounded pretty garbled, so I went with unsigned
samples.
> Why divide the rate by 2? I'd
> assume that NOS can downsample better than we'd be able to (it permits
> arbitrary downsampling).
I downsampled mostly to minimize the space needed in the output
buffer. I figured that 44.1khz is most common in input streams, so
dividing by two comes really close to the 21.6khz the 2000/2100
uses as a default.
> If you can output to 16-bit MuLaw compansion
> rather than 16-bit linear, it'd give better quality; does MAD provide
> this option?
There are actually a couple of output converters, and I think MuLaw
is one of them.
> 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.
Yes, that's what I thought... it works if I schedule a pre-prepared
large sample batch, but for the small, second-sized batches, this
in conjunction with networking could be too much.
> 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.
Thanks for the info. Currently, filling the input buffer only locks
the incoming data (the buffer itself is on the system heap). I've
experimented with different kinds of objects (VBO, NS object,
system heap memory) for the output buffer, but I think there are no
real restrictions as to what can be used.
> 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! I was so far using NHttpLib to simply fetch the raw data
from a web server - actually, this works also for Shoutcast/Icecast
servers. Just not realtime yet. But a couple of test packages would
be neat for testing.
More to come,
Eckhart (standing on the shoulders of giants ;)
--
-- eck_at_40hz.org -- www.40hz.org --
--
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