search for: shout_sync

Hello. For various reasons I am writing my own source client. Most things seem to be working well. Connections work. shout_send() and shout_sync() seem to behave as expected. However, I find that if more than about 10-20 seconds passes between shout_send() calls then libshout crashes (takes my client down) during a subsequent shout_send(). Are there any rules about how often shout_send() should be called? (Yes, I know about shout_sync....

....xiph.org/archives/icecast-dev/0660.html). I have then generated a dll and wrapped it in JNI using the stubs from libshout-java (http://benow.ca/index?page=project&project=libshout-java). So, I have libshout basically working through Java on Windows XP. I think everything is working ok, except shout_sync. This call returns immediately under the 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...

On Mon, Sep 17, 2012 at 9:29 AM, George R. Welch <george at grwelch.com> wrote: > Hello. For various reasons I am writing my own source client. > > Most things seem to be working well. Connections work. shout_send() and > shout_sync() seem to behave as expected. > > However, I find that if more than about 10-20 seconds passes between > shout_send() calls then libshout crashes (takes my client down) during a > subsequent shout_send(). Are you sure it's libshout crashing, and not your application? It's norm...

...17/12 12:37 PM, Michael Smith wrote: > On Mon, Sep 17, 2012 at 9:29 AM, George R. Welch <george at grwelch.com> wrote: >> Hello. For various reasons I am writing my own source client. >> >> Most things seem to be working well. Connections work. shout_send() and >> shout_sync() seem to behave as expected. >> >> However, I find that if more than about 10-20 seconds passes between >> shout_send() calls then libshout crashes (takes my client down) during a >> subsequent shout_send(). > Are you sure it's libshout crashing, and not your applica...

...hours (sometimes just one hour, sometimes 5 to 8 hours) i get noise or stutter. Now one thing i have discovered is that the input buffer of ogg123 starts dropping, and after some hours it drops below 1% to 5%, and then the music gets interrupted. So maybe the sleeping period in libshout's shout_sync() is too short? <p>Chris --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject...

...f ices (a test program i have written), and it leads to the same problems. With WinAMP its a bit hard to have diagnostics, but when i look at ogg123 it seems that the input buffer drops and drops, and after some hours i get stutter and sometimes even noise. So i think that maybe libshout's shout_sync() (which is not used in ices, but the code seems to be the same) sleeps too long, so the input buffer of the players will be empty after some hours? (i don't really know why that leads to crashes, though). I will go on testing, tonight i'll run xmms, but maybe anyone of you has another...

...x282a2da4 in .cerror () from /usr/lib/libc.so.4 #1 0x2842ff59 in _thread_sig_handle_pending () from /usr/lib/libc_r.so.4 #2 0x2842f84d in _thread_sig_handler () from /usr/lib/libc_r.so.4 #3 0xbfbfffac in ?? () #4 0x281192b4 in _shout_timing_sleep (sleeptime=231) at timing.c:59 #5 0x281161a7 in shout_sync (self=0x81be200) at shout.c:261 #6 0x805c597 in stream_send_data (stream=0x81be180, buf=0xbfbfeb30 "f", len=4096) at stream.c:369 #7 0x805c211 in stream_send (config=0x81b4a00, source=0xbfbffb60) at stream.c:256 #8 0x805be61 in ices_stream_loop (config=0x81b4a00) at stream.c:111 #9...

I kind of copied the example from the distribution and changed it a bit so it would send my own lame encoded mp3 data. I decode an mp3 and encode that same data again in a lower bitrate and send that data to my icecast server. After each shout_send i use the shout_sync function but it doesn't seem to wait and just sends all available buffers at once to the icecast server. When its done sending all buffers to the icecast server, it just stops playing the stream in my client (even though the source remains connected). Does anybody got an idea what's wrong?...

...din); total = total + read; if (read > 0) { ret = shout_send(shout, buff, read); if (ret != SHOUTERR_SUCCESS) { printf("DEBUG: Send error: %s\n", shout_get_error(shout)); break; } } else { break; } shout_sync(shout); } } else { printf("Error connecting: %s\n", shout_get_error(shout)); } Thanks for your comments _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus --- >8...

...ms to > be no timeout (or, at least, i've let it run for 10mins without > seeing any timeout). > > Is there a way to detect such events using libshout or do i have to > put a timeout on the send function? > > here is the piece of code for the send function : > > shout_sync(m_shout); > int ret = shout_send(m_shout, (unsigned char*)buf, buflen); > if(ret != SHOUTERR_SUCCESS) { > Logger::log("Shout::send shout send error\n"); > return false; > } > return true; > > Thanks for any advice > > Florian > > ------------------...

Attached is a patch against shout-python-0.2 which does two trivial but very useful things (1) The function "get_connected" is exported so that shout-python becomes usable in nonblocking mode. In the current version of shout-python "open" raises an exception in nonblocking mode. (2) The global interpreter lock is released in the potentially blocking functions