similar to: libshout nonblocking API

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

usleep is deprecated under POSIX 2008 and is optionally unavailable with uClibc-ng. Signed-off-by: Rosen Penev <rosenp at gmail.com> --- examples/nonblocking.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/examples/nonblocking.c b/examples/nonblocking.c index 8e38a94..2f15b80 100644 --- a/examples/nonblocking.c +++ b/examples/nonblocking.c @@ -70,8 +70,10 @@ int

Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in

In the absence of any negative feedback (or positive, for that matter), I've decided to just go ahead and drop the new version of libshout, libshout 2.1. New features: * nonblocking I/O: call shout_set_nonblocking(1) before shout_open. If the socket is busy, your data will be queued until the next time libshout attempts a write. The current queue length in bytes is visible through

I've tried everything I know how (and a lot I don't) to get ices to compile on this beige G3 ppc box. I've got the latest cvs of libshout and ices. Gentoo linux ppc 1.2-r1, from stage3 tarball. gcc 2.95.3 I've made sure that libshout points to libshout.so.2.0.2. Don't know what else to try. I've got the box here, and I've port-forwarded through my firewall to

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()

Hi, I've been working on a customized version of ezstream and I've been noticing that with a particular setup after playing particular tracks ezstream terminates. I say terminates because there are no error messages, it just exits. I've tried this on both my version and the stock version available via icecast.org just be certain and it happens with both versions. I'm

The open source fdk-aac encoder, available there: https://github.com/mstorsjo/fdk-aac offers pretty good quality. As for libshout, I do not think that it is currently posible to send AAC data using it. First, libshout doesn't have support to buffer and control timing of data sent. And even is you use the un-timed API (shout_send_raw), the library cannot set the proper mime type, due to a

Okay, I am using libshout to stream to a NullSoft Shoutcast server. I am using libmad and libmp3lame to do re-encoding on the fly. I am streaming to the server (currently) with shout_send_raw(). When I try to use shout_metadata_add(), I get a segfault in strdup(). Anyone have any ideas as to why? Everything else works fine, just not the metadata. Thanks In Advance, Deven --- >8 ----

Hello... I have a doubt with the use of shout_send()... at low level, what should it send? the example reads from "stdin" and sends the read buffer with shout_send, but... where should fread() read from (behind the stdin)? I could think about something like this (for example) mpg123 "audio_file" ---> stdout --pipe-- stdin <--- libshout_application I include the

Hi, Let me know if this is the wrong place to post this, but I am having problems with cutouts in my streams using libshout2. I am taking audio files and re-encoding them at 32Kbs and then streaming them. Problem is that every 20 secs or so, the stream cuts out for about 5-10 secs and then continues. Any ideas as to why? Should I try using shout_send_raw? Thanks in advance!! Deven

Hi List, i have a problem streaming mp3's to the icecast server via libshout-2.1. Everything works fine as long as i send ogg's to the icecast server. libshout as well as icecast do not report any errors. what might be the problem? my code looks like this: shout_init() shout_set_host(...) shout_set_password(...) shout_set_mount(...) shout_open() shout_set_format(...) while(

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

Hi, I have been trying to stream MPEG Audio Layer 2 using libshout in my dvbshout program: http://www.ecs.soton.ac.uk/~njh/dvbshout/ However I have been using the shout_send_raw() API call because the MPEG audio header parser rejects audio that isn't Layer 3. Streaming layer 2 works in exactly the same way as Layer 3 and without any problems. Would it be possible to get src/mp3.c

Okay, this is interesting.... The metadata functions work fine with icecast (2.0.0) but do not work at all with NullSoft's ShoutCast server. . . Is that not supported by libshout? Just curious... Deven Deven Phillips wrote: > Okay > > Nevermind the SEGFAULT, it was string pointers in my code. Sorry > for the inconvenience. Continuing with the issue though . . . . >

He means that development of WinAmp 3 has discontinued. WA2 is being updated to support WA3's extra features (video, media library), and WinAmp 5 (2+3=5) is the main new development. You can read the announcement on the WinAmp forums. >===== Original Message From Stefan Neufeind <stefan@neufeind.net> ===== >On Fri, 16 May 2003 at 13:15:22, Geoff Shang wrote: > >> I

>This is in subversion now. I'll try to get a new release out this >weekend. Thanks! Thanks! But I noticed that giving up the global interpretor lock in a few functions allows other threads to do something stupid (like deleting the shout object during a write). So for everything to be absolutely thread safe a python shout object should contain a mutex and there should be appropriate

I'm getting errors like; /tmp/ccJK5HgU.o(.text+0x426): In function `connect(shout*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': : undefined reference to `shout_open' for each of the ices function calls. My gcc command looks like this; g++ -o myicestream -L/usr/lib/shout -lmysqlclient myicestream.cpp and libshout is in; find /usr -name

Karl Heyes wrote: >> In file included from sock.c:49: >> sock.h:32: os.h: No such file or directory >> make[2]: *** [sock.lo] Error 1 >> make[2]: Leaving directory `/opt/ices2/libshout/src/net' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/opt/ices2/libshout/src' >> make: *** [all-recursive] Error 1 > > > yes

>Why would you keep a non-thread safe API ? I do not want to touch libshout. I am only concerned with the python bindings. Probably Brendan can answer this better but I think libshout is not thread safe for simultaneous accesses to a shout_t object. This is not a problem as the posix locking primitives are trivial to use. For python apis should in principle be absolutely thread safe.