Thanks Dan,

Yes, it does make a lot more sense having libcurl doing
decompressing, de-chunking, etc... so I will have a look at the
buffer method. One of my concerns is that libcurl will fetch and
buffer data faster than mpg123 will consume it.

Is there a way of stopping the WriteFunction callback until there is
room in the buffer?

nick.

On 18 Oct 2006, at 21:07, Dan Fandrich wrote:

> On Wed, Oct 18, 2006 at 08:27:07PM +0100, Nicholas J Humfrey wrote:
>> I am working on replacing the old bug-ridden HTTP code in mpg123 with
>> something a bit better and then thought that perhaps I should be
>> using libcurl instead. It would also give us https and lots of other
>> protocols for free..
>>
>> Currently we have a function or two that establishes the HTTP
>> connection, and then normal file IO code is used to read in the MPEG
>> Audio from the socket for decoding. Is something like this possible
>> with libcurl?
>>
>> All the examples I have seen on the website use callback functions
>> and intermediate buffers, which I would ideally like to avoid (and
>> keep the memory footprint down). While having a buffer would help
>> with network stalls, reading MPEG Audio directly from the network
>> socket has always worked quite well in mpg123.
>
> This paradigm doesn't quite match libcurl's as the latter expects to
> perform all the low-level grunt transfer work itself. This allows
> it to
> handle compression, chunked transfers, and encryption itself and avoid
> burdening the application with knowledge of all those areas. The
> mpg123
> situation where it reads raw data directly from a descriptor only
> works if
> the data is not encoded in any way. If you want any of libcurl's data
> transformation options, then the raw descriptor approach will fail.
>
> Having said that, it is possible to use various libcurl options to
> force
> a raw, unencoded transfer, and there is now an option to obtain the
> socket being used by libcurl, so you could almost do what you
> want. The
> big problem is that libcurl reads data in big chunks, so it will
> usually
> gobble up the first chunk of MP3 data before the socket can be passed
> to the app. You could get around this by modifying libcurl to do 1
> byte
> reads until it reaches the end of the headers.
>
> But there's little point in doing all that. libcurl would simply be
> reduced to opening a socket and sending some HTTP headers across
> the line,
> tasks that mpg123 is doing already (ok, a few other tasks could
> still be
> handled by libcurl, such as authentication and tunneling through
> proxy servers). But you gain much more versatility by changing
> mpg123 to
> conform to libcurl, rather than the other way around.
>
>>>> Dan
> --
> http://www.MoveAnnouncer.com The web change of address
> service
> Let webmasters know that your web site has moved
Received on 2006-10-19