TCP, odd jobs

[Amos Hayes]

Request data when buffer < 95% full
Start playing when buffer first becomes >= 50% full
Stop when 0% full
This would work for streams where we can pull data as fast as we
want, i.e. a regular HTTP server. However for shoutcast/icecast, we only
get data at whatever the bit-rate of the song. So we'd have to wait even
longer at the beginning of the stream if we wanted to have a large buffer.

That is what I was thinking of. I'm thinking of situations where the
throughput might, on average, be high enough to support the stream but is
very sporatic. If you could specify a "number of seconds to cache", you
could get around some of those problems at the expense of a bit of a
wait for the stream right?

Actually, that's something I always thought was lacking from shoutcast
- when you first connect, they should start you out several seconds back
in the stream, so that you fill an initial buffer quickly.

They maintain some sort of outbound cache which can be passed at max speed
to a new client upon connect? Otherwise you just wind up always a few
seconds behind right?

I'm trying to picture what happens when retrieveing an mp3 stream. I
assume the bitrate is enforced by the server by virtue of it sending out
only what it has got so far... be it from a live show or where it's at
with a file from disk. Would today's clients be able to retrieve the first
few seconds at a higher rate without modification?

Kind of pie in the sky anyway.. :)

--
Amos Hayes
ahayes-***@public.gmane.org


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

As for TCP stuff.... can you help explain what happens when the client's
buffer runs out?

The client's logic is as follows:

Request data when buffer < 95% full
Start playing when buffer first becomes >= 50% full
Stop when 0% full

Anyone want to implement a configurable stream buffer on the server
side?

This would work for streams where we can pull data as fast as we
want, i.e. a regular HTTP server. However for shoutcast/icecast, we only
get data at whatever the bit-rate of the song. So we'd have to wait even
longer at the beginning of the stream if we wanted to have a large buffer.

Actually, that's something I always thought was lacking from shoutcast
- when you first connect, they should start you out several seconds back
in the stream, so that you fill an initial buffer quickly.

I'm not sure a large buffer in the server would solve anything - if the
WAN just isn't fastest enough, you'll still run out of buffer space
eventually.

Sean


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/75YKVC/7.PDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Amos Hayes]

Amos,
I'll volunteer for some TCP stuff. Sorry I haven't been more involved with
server development lately.

Sean, you've got more than enough on your hands I'm sure. Congrats on an
official Slim Devices home base. :)

As for TCP stuff.... can you help explain what happens when the client's
buffer runs out? I can't seem to maintain a stream for more than 2-4
songs. I'm guessing that my connection to the streaming server is bogging
down long enough at one point for the client to stall. Anyone want to
implement a configurable stream buffer on the server side? I think it's
probably over my head.

--
Amos Hayes
ahayes-***@public.gmane.org


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited calling with 3-way conferencing. Only $1/Mo.
with CrystalVoice! FREE trial. Click Here.
http://us.click.yahoo.com/Hb1xVB/HxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Daniel Sully]

Once upon a time Sean Adams shaped the electrons to say...

Which DBM interface should we use for cross platform happiness?
I see DB_File, GDBM_File, NDBM_File, SDBM_file...

You just do dbmopen(%hash, "filename", 644) and then you can access it
exactly like a hash.

perldoc -f dbmopen

[This function has been largely superseded by the "tie" function.]

Just FYI. tie() is easy to use.


-D
--
There was supposed to be a big kaboom.

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Sean Adams]

Which DBM interface should we use for cross platform happiness?
I see DB_File, GDBM_File, NDBM_File, SDBM_file...

You just do dbmopen(%hash, "filename", 644) and then you can access it
exactly like a hash.

Perl uses whatever DBM style it wants, and all perls come with this
built-in, so there are no platform-specific issues. The reason for using a
DBM instead of a tab delimited file is that you get random access to any
value you want, and you don't have to worry about periodically saving the
state. It's *very* easy, and one of the coolest features of Perl.

Sean


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Win a Capcom Console Game of Your Choice Or Even a Capcom Arcade System. Click Here to Enter.
http://us.click.yahoo.com/tmpz8B/exbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Daniel Sully]

Once upon a time Enno Davids shaped the electrons to say...

|>
|>Keeping (certain) client state values between server restarts should be
|>pretty easy. We can just use a single DBM file with values like
|>"10.0.1.2;volume". Then you don't have to worry about periodically saving
|
|Which DBM interface should we use for cross platform happiness?
|I see DB_File, GDBM_File, NDBM_File, SDBM_file...
Can I ask why we need a DBM file at all? We surely don't have even 100
pieces of state info to store and using a name=value text file would cope
well with it I would have thought. Read it into an assoc array at startup
and you get all the same keyed lookup abilities as a dbm file offers.
And you have the added advantage that you don't need yet another perl
module, you can edit the state with a plain text editor, its cross platform
portable (I don't see a big need for this, but maybe one day Sean will
want to ship the code with some factory defaults?) and its low (complexity)
cost.

use AnyDBM_File;

SDBM comes and is built with all versions of perl, so there will always
be a DBM interface available.

-D
--
As you well know, magic and weapons are prohibited inside the cafeteria.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Need new boots for winter? Looking for a perfect gift for your shoe loving friends?
Zappos.com is the perfect fit for all your shoe needs!
http://us.click.yahoo.com/ltdUpD/QrSDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Enno Davids]

Guys,

another 2c worth...


On Sun, Dec 16, 2001 at 03:10:33PM -0800, dean blackketter wrote:
|>
|>Keeping (certain) client state values between server restarts should be
|>pretty easy. We can just use a single DBM file with values like
|>"10.0.1.2;volume". Then you don't have to worry about periodically saving
|
|Which DBM interface should we use for cross platform happiness?
|I see DB_File, GDBM_File, NDBM_File, SDBM_file...

Can I ask why we need a DBM file at all? We surely don't have even 100
pieces of state info to store and using a name=value text file would cope
well with it I would have thought. Read it into an assoc array at startup
and you get all the same keyed lookup abilities as a dbm file offers.

And you have the added advantage that you don't need yet another perl
module, you can edit the state with a plain text editor, its cross platform
portable (I don't see a big need for this, but maybe one day Sean will
want to ship the code with some factory defaults?) and its low (complexity)
cost.


Enno.



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Unlimited PC-PC calling at Crystal Voice! - Only $1/Mo.
Download your free 30 day trial. Click here.
http://us.click.yahoo.com/Gb1xVB/GxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

Keeping (certain) client state values between server restarts should be
pretty easy. We can just use a single DBM file with values like
"10.0.1.2;volume". Then you don't have to worry about periodically saving
the values or loading them at startup. You just access them through the
dbm - it's pretty fast.

Which DBM interface should we use for cross platform happiness?

I see DB_File, GDBM_File, NDBM_File, SDBM_file...

-dean

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Call any Phone in the World from your PC with CrystalVoice
-LOW rates world-wide - $0.039/min in U.S.
FREE trial. Click here.
http://us.click.yahoo.com/Ib1xVB/IxbDAA/ySSFAA/rIp0lB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
slimp3-dev-unsubscribe-***@public.gmane.org



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[dean blackketter]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [slimp3-dev] TCP, odd jobs</title></head><body>
<div><br>
<br>
</div>
<blockquote type="cite" cite><br>
Keeping (certain) client state values between server restarts should
be<br>
pretty easy. We can just use a single DBM file with values like<br>
&quot;10.0.1.2;volume&quot;. Then you don't have to worry about
periodically saving<br>
the values or loading them at startup. You just access them through
the</blockquote>
<blockquote type="cite" cite>dbm - it's pretty fast.</blockquote>
<div><br></div>
<div>Which DBM interface should we use for cross platform
happiness?</div>
<div><br></div>
<div>I see DB_File, GDBM_File, NDBM_File, SDBM_file...</div>
<div><br></div>
<div>-dean</div>
</body>
</html>