Aznick,
thaks for the link it was useful to better understand.
I don't know the technical details either but regarding Icecast it's
just the server side of the streaming. Then you need an encoder that
actually produces the stream accesset through icecast.
Radish, Kdf, Aznick
thanks for making me
I reenter this thread with some trepidation, recognizing the expertise
of some of the other people who are helping you. That being said, I
think the difference you're seeing between the behavior of your icecast
stream and slimserver's stream.mp3 can be chalked up to stream.mp3 not
being a true "s
Virgus Wrote:
> Thanks Radish!
> I was wrong this time too: I kept listening to squeezebox and after
> killing slim.exe task it took 47 seconds to the buffer to empty! Wow I
> didn't expect a 128k buffer took so long to be emptied!
>
If you mean the softsqueeze buffer, I don't think it's 128k. T
On 6-May-06, at 11:37 AM, Virgus wrote:
If I press stop/pause/skip on the server AND press play on the client
player then the command is accepted and executed instantly by the
server instead of the 6-8 seconds wait.
This would be due to the client making a new request. This flushes the
buffe
Thanks Radish!
I was wrong this time too: I kept listening to squeezebox and after
killing slim.exe task it took 47 seconds to the buffer to empty! Wow I
didn't expect a 128k buffer took so long to be emptied!
I shouldn't do tests too late at night, it's easy to get wrong
conclusions ;-)
On the s
Are you using icecast _and_ slimserver? i.e. slimserver streaming to
icecast and then icecast to the player? If so, I would bet money the
buffer causing you problems is on the input side of icecast.
>
> So it's not a buffer misbehaviour, it's the server waiting from the
> player acknowledgment t
Kdf your feedbacks are so helpful!
The buffer settings as you pointed out depend on the MAXCHUNKSIZE
value.
I think I'm getting closer to the solution:
what took me on the wrong path is the fact that when I
change/pause/stop a track data is still broadcasted. I kept thinking it
was the buffer bu
Networking/Stream.pm is a module that only applies to SliMP3. If you
don't have one of these devices, then it isn't needed by the server and
isn't used. The 32k, I think comes from MAXHUNKSIZE, which is what the
server grabs when preparing the next "chunk" to send to teh streaming
socket. This c
Thanks for your explanation, just for completeness I put all the players
input buffers to the minimum (eg when I stop the streaming player on the
server I get 0,5 sec audio on the client player while when I stop
slimserver's stream I get 6-8 seconds of the big SS buffer)...
The only 32K values I f
Quoting Virgus <[EMAIL PROTECTED]>:
Hi Kdf,
half way from getting slimserver run from my linkstation, I spent some
time in trying to change the buffer.
I changed many values in the following files:
Slim\Networking\stream.pm
Slim\Networking\Slimproto.pm
and found these two entries in Slip\pl
Hi Kdf,
half way from getting slimserver run from my linkstation, I spent some
time in trying to change the buffer.
I changed many values in the following files:
Slim\Networking\stream.pm
Slim\Networking\Slimproto.pm
and found these two entries in Slip\player\Squeezebox.pm:
> # if this is
To Aznick:
Thanks for the effort :-)
I've been playing with slimserver for less than 24 hours now and I am
getting really excited about its potentials (paired also to the
SB2s/SB3s...).
I've read somone has installed slimserver onto a buffalo NAS I'm trying
to tweak my buffalo rigt now :-)
--
Well, it sounds like your understanding of the buffers has progressed
well beyond the basics...and well beyond anything I can help you with
:) ! I've never looked into the details of the buffering, I trust
someone here will be able to help you out...
--
azinck3
Thanks Aznick3 for your explanation,
I'd like to better understand (and manage) the stream.mp3 as I reduced
the buffer of the player to the minimum. I made some tests and think
that the Slimserver stream.mp3 has its own buffer for broadcasting.
I found some parameters in the stream.pm file as I wr
Softsqueeze emulates an SB2 precisely, including its buffer. If you're
getting a delay using softsqueeze you're probably streaming over the
internet? The same delay (approximately) would exist with a hardware
box. When a track change is initiated the buffer is cleared, refilled,
then play comme
Thanks for the fast reply,
I meant the server buffer setting as I'm experimenting with softsqueeze
and other sw players.
...but surely I'll buy a couple of softboxes as I'll come to the US!!
I'd like to try to decrease the buffer not to have that annoying 8
seconds delay between track changes...
The squeezebox hardware itself has a fixed hardware buffer which cannot
be altered. See this page in the wiki for details on the differences
between the units:
http://wiki.slimdevices.com/index.cgi?HardwareComparison
Audio playback commences once a specified portion of the buffer
(perhaps all of
17 matches
Mail list logo
