search for: timing_sleep

...compilation setup above, instead of actually sleeping, screwing up the audio streams. This occurs in exactly the same way when I compile the ezstream utility off of the libraries as when I'm running libshout through Java, so I don't think it's an artifact of the JNI process. Looking at timing_sleep, the only relevant call there is select(), so I'm guessing the problem is in the invocation there, but I can't figure out what would fix it -- I've been programming Java too long, I'm just glad I made it this far :) I modified the JNI wrappers to expose shout_delay and have been ha...

...on a local > > > network as well as my ADSL, both of which are good enough to stream > > > at 12Kb/sec. > > > > Ah, I found this one while playing with ices on solaris. The problem > > seems to be a truncation error in libshout's timing/timing.c, in > > timing_sleep, which results in ices not sleeping at all between > > chunks. I hope you're experiencing the same problem, because I posted > > a patch a couple days ago. Check out the CVS or wait for 0.2.1. > > Unfortunately I am using the CVS version. Is there any way for me to trace >...

...I know it's not bandwidth-based problems. This happens on a local > network as well as my ADSL, both of which are good enough to stream > at 12Kb/sec. Ah, I found this one while playing with ices on solaris. The problem seems to be a truncation error in libshout's timing/timing.c, in timing_sleep, which results in ices not sleeping at all between chunks. I hope you're experiencing the same problem, because I posted a patch a couple days ago. Check out the CVS or wait for 0.2.1. > > Of course ices hasn't had a proper security audit. Please check with > > Theo de Raadt be...

...network as well as my ADSL, both of which are good enough to stream > > > > at 12Kb/sec. > > > > > > Ah, I found this one while playing with ices on solaris. The problem > > > seems to be a truncation error in libshout's timing/timing.c, in > > > timing_sleep, which results in ices not sleeping at all between > > > chunks. I hope you're experiencing the same problem, because I posted > > > a patch a couple days ago. Check out the CVS or wait for 0.2.1. > > > > Unfortunately I am using the CVS version. Is there any way...

...8 encode = ~33kbs = Many sleep > errors. Will you try something to get you going. In the ices/src/input.c file goto line 92, you should see if(sleep > 1000) { LOG_WARN1("Extended sleep requested (%ld ms), sleeping for one second", sleep); timing_sleep(1000); } change to the following if(sleep > 5000) { LOG_WARN1("Extended sleep requested (%ld ms), sleeping for 5 seconds", sleep); timing_sleep(5000); } <p>This will give it a 5 sec tollerance instead of 1 second. I believe it...

I've just finished a little encoding set and the following happened: 22Khz resampled, q-0.4 encode = ~38kbs = one error at the beginning only. 22Khz resampled, q-0.5 encode = ~37kbs = 6 to 7 sleep errors in the first second or so, nothing after that. 22Khz resampled, q-0.6 encode = ~35kbs = 14 to 15 sleep errors then nothing. 22Khz resampled, q-0.8 encode = ~33kbs = Many sleep errors. ---

...-based problems. This happens on a local > > network as well as my ADSL, both of which are good enough to stream > > at 12Kb/sec. > > Ah, I found this one while playing with ices on solaris. The problem > seems to be a truncation error in libshout's timing/timing.c, in > timing_sleep, which results in ices not sleeping at all between > chunks. I hope you're experiencing the same problem, because I posted > a patch a couple days ago. Check out the CVS or wait for 0.2.1. Unfortunately I am using the CVS version. Is there any way for me to trace where it's mistiming...

...local/include/libxml2 -pthreads -g -O2 -c timing.c -MT libicetiming_la-timing.lo -MD -MP -MF .deps/libicetiming_la-timing.TPlo -fPIC -DPIC -o .libs/libicetiming_la-timing.o timing.c: In function `timing_get_time': timing.c:53: storage size of `mtv' isn't known timing.c: In function `timing_sleep': timing.c:63: storage size of `sleeper' isn't known make[3]: *** [libicetiming_la-timing.lo] Error 1 make[3]: Leaving directory `/opt/src/ices-2.0.1/src/timing' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/src/ices-2.0.1/src' make[1]: *** [all-recursive...

Karl Heyes wrote: > Well assuming a pure clock change, a change of 10 secs could cause an > extended sleep period in which icecast could drop the connection. In > this case increasing the source-timeout is not the right solution as > a 10 second gap in audio streaming is really bad! A simple log message > could help track those type of problems. If the > sleep is over say 2

On Tuesday, 10 July 2001 at 01:26, Nick Ludlam wrote: > Not got to the bottom of it yet, but commenting out both LOG_INFO > lines in thread/thread.c stops it segfaulting. Now I'm back to the old problem > of a 128k stream not being sent fast enough to the clients. you should just be able to increase STACKSIZE in thread/thread.c from 8192 to 65536. The default stack size is too small,

At 4:37 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 13:21, tom erbe wrote: >> At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >> > > 0.2 doesn't segfault, but it seems to overrun the server (if that >> >> makes any sense), it plays a 3 minute file in seconds. >> > >> >I'd like to know more about this. Are you