[vorbis-dev] ogg123 HTTP streaming (was Re: [vorbis-dev] Ports)

Kenneth C. Arnold kcarnold at arnoldnet.net
Sun Dec 24 13:50:52 PST 2000


According to Michael Smith (sometime around Sun, Dec 24, 2000 at 10:24:23PM +0000):
> >>It's something that belongs externally to the program. (i.e. 'nice', or the equivalent on non-unix systems). You're welcome to have it in your own copy, but it isn't going into CVS. 
> >
> >The problem with that idea is that some systems (including OS/2 & I believe
> >Win9x/NT) have no equivalent of 'nice', at least not standard (not all the
> >world is unix). 
> Seems strange. Oh well. I suggest you just have it in your local copy (if you REALLY want it in the mainstream code, I'll accept an implementation that a) makes it optional, and b) implements it fully on all the supported OSes (win32, os/2, linux, freebsd, solaris, macosX, and probably a bunch of other unixes). If that looks like a lot - well, it is. I don't think it should be there.

Could you PLEASE wrap lines at 72 (or even something close) spaces?
Thanks ...

> >
> >>>I've got more now including an OS/2 ao plugin & a dl -> OS/2 API shim to
> >>>load it, making ogg123 work. I'll get it cleaned up & post it.
> >>
> >>That'd be good. Is there a good/well designed library for cross-platform dynamic loading, so we could just use that instead of a heap of platform-specific implementations? 
> >
> >The only one I know of (because I've been involved in its development) is
> >APR (see http://apr.apache.org/ ), an offshoot of the Apache Server
> >project.
> Yeah, APR looks very nice - but it's a big dependency to add for something like this. 
> >
> >It's not that big a deal though, I've attached the dl for OS/2 code I wrote
> >just to show how simple it is. I could write one for Win32 just as easily.
> Yes - it isn't hard or complex, it's just messy to have a whole bunch of implementations. Not a big problem - going with platform-specific code is probably better (at least for now). The code looks fine, so I'll commit it once you've sent along the rest of the code (for libao os/2 output).
> >
> >>>BTW, is http streaming in ogg123 supposed to work?
> >>
> >>Yes. I don't know if it does, though. It requires a high-speed connection, since it doesn't do anything nice like proper buffering, and it's quite likely to not work on non-unix systems. I haven't tested it in a long time, though, so it might not work any more.
> >
> >Ok, probably not worth worrying about for now. I tried it using an Apache
> >server running on the same machine & just got the "input not an Ogg Vorbis
> >audio stream" error.
> I just tested it (on a file from www.vorbis.com), and it works fine (well, it skipped a few times, because of the lack of buffering, but that's not a surprise). 
> Make sure your local webserver is specifying the correct mime type (application/x-ogg, I think) - some systems will break if it isn't set. That's my only guess for what's causing problems. Does OS/2 inherit the DOS stupidity of text/binary files? That would cause this if you don't have a mime type set.

This is a biggie on my ogg123 cleanups. Current http streaming is very
hacked up (*hack* messy *hack*), and really needs to go (but it'll
stay for my first commit, which is just simple reworks and going in
later tonight if I get a few more min^H^H^Hhours to work on it). Any
suggestions for how to buffer in a cross-platform way? I'd like to
avoid #ifdef'ing huge blocks of code, but I suppose that a small
platform-specific section would be okay. Suggestions? Win32 coders:
how easy is creating a thread and sharing memory? Can you do it in a
separate file from the rest of the code (look at oggenc), or does it
have to muck in the internals a lot? How about on Unix? pthreads, or
is that too much of a mess to pull in? POSIX shared memory? I have
tried a buffer using I/O on a socket between two forked processes, but
the I/O killed it. It must be shared memory, unless I really code I/O


Kenneth Arnold <ken at arnoldnet.net> / kcarnold / Linux user #180115

<LI>application/pgp-signature attachment: stored
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20001224/6caf17b6/part.obj

More information about the Vorbis-dev mailing list