similar to: Icecast2?

On 19/02/02 03:06, Jack Moffitt shaped the electrons to say: > > The point is, is this list related to icecast2 development? I made some > > changes to the server and sent a patch to Jack Moffitt, but I'm not sure > > he's still mainaining the server. > > You're in the right place, and I still maintain the server. I don't > remember your patch right

I send a patch again the last CVS version. The changes are: - Configurable prebuffer, in seconds. - prebuffering parameter in configurable in <limits>...<prebuffer>seconds</prebuffer>... - Created a new function (send_client_queue) to send the client->queue. Better modularisation. - Moved queue_lenght verification to send_client_queue(). - instead of disconnecting when

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, I think you dealing with the development. Almost a year ago I've sent few patches to Jack, several of them are already applied to the current version. I'm back again, and tested the last version. I noticed it isn't as resilient to network congestion as my last patched version (just disconnect the ethernet cable of

On 19/02/02 18:09, Likai Liu shaped the electrons to say: > >It's partially done in the patch I've sent you, completelly done in my > >current version... I can send you the second patch, you will save some > > work. > > how is the calculation being done? do you extract the bitrate from the > stream data, or do you use a different method? I'd advocate *that*

What is the best way to pick a prebuffering length for a streaming audio application using UDP transport? I'm using Speex in a VoIP application with RTP transport, currently with a fixed 500ms prebuffer on the playback side. However, I'd like something a bit more adaptive to accomodate high-jitter connections. For example, in one test configuration there is a very low average

On 19/02/02 23:09, Likai Liu shaped the electrons to say: > Ricardo Galli wrote: > >By assigning a timestamp to each packet read from the source socket. I > > think the only sane way to do it. > > great idea. with this implementation, actually you can set a smaller > buffer size, but wait a longer time for recovery. once congestion is > clear, previous "missed"

Ok, this is a silly question, but what does the jitter buffer do? I'm really new to audio, so please bear with me. From what I gather (primarily from the list archive), the jitter buffer is a wrapper around the Speex decoder. I give it the packets I receive, in whatever order I receive them, and then it gives me back a clean stream of audio samples. But what I don't entirely

Hrm, yes it does sound like a bug in WinAmp. Even if it does prebuffer, the length counter should be going beyond 0:01 since you've obviously been listening longer than that after the first second. =P (I don't think the counter resets after buffering, but I could be wrong.) Can you see if you can duplicate it by getting someone else to tune in to the 'cast with WinAmp?

Noticing a strange issue, i'm not sure where this lies. I'm using oddcastDSP to stream Ogg to icecast2, which seems to be working ok, but using winamp (v2) to stream from icecast, winamp is constantly prebuffering, displaying a length of 0:01. Is this a known bug in either Winamp or icecast, or a configuration issue perhaps? I have a feeling this is Winamp, but I was wondering if anyone

Sounds like WinAmp isn't storing a large enough buffer, or Icecast isn't putting a long enough buffer between what it recieves from Oddcast & what it transmits to clients. I've never had such a problem, though. Could be your connection? >===== Original Message From John Farnsworth <si@darkness.nu> ===== >Hrm, but it works fine (and the mountpoint is /dnumusic.ogg).

Ah, I'm sorry, I have read the manual and believe I have a reasonably good grasp on how to use the Speex encoder and decoder altogether. In fact I've been using it with great success in my P2P SIP/RTP VoIP application for almost a year now; it's been working wonderfully and I can't thank you enough. However, the manual makes no mention of the jitter buffer, nor does it (so

I must use Windows for Streaming. and the interface must be an port or something else, because the software interface runs on a dedicated server. ----- Original Message ----- From: "Ricardo Galli" <gallir@uib.es> To: <icecast-dev@xiph.org> Sent: Wednesday, February 25, 2004 10:10 AM Subject: Re: [icecast-dev] I need a Freelance Coder... <p>> On Wednesday 25 February

Hello there, I'm checking if I can upgrade safely from CentOS6.5 to 6.6 using yum, and here's what it says: ===================== [snip] --> Finished Dependency Resolution --> Running transaction check ---> Package kernel.x86_64 0:2.6.32-431.23.3.el6.centos.plus will be erased ---> Package kernel-devel.x86_64 0:2.6.32-431.23.3.el6.centos.plus will be erased ---> Package

*Hi everyone, I am a new subscriber, so I hope I'm posting in the right way. I need to load a hdf5 file, so I installed the hdf5 libraries ad the hdf5 R package; in downloaded a small sample file from the hdf5 website and I could correctly load it. But when I try to load my file: * require(hdf5) rm(list=ls()) ls() hdf5load("my_file.h5", verbosity=3) *I get this error message: *

Is there anybody who can help my for implement a feature in icecast 2? I want to update ogg vorbis meta data album/title/genre/artist via an webbased interface. like metadata.xml for mp3 files. If there`s anybody, contact my benny@name-pool.net i would pay for this feature. thanks --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To

Known bug for 32-bit. Workaround is on the net. http://mulps.wordpress.com/2009/05/29/compiling-xen-kernel-2-6-29-2/ Boris ________________________________ From: Mehdi Sheikhalishahi <mehdi.alishahi@gmail.com> To: bderzhavets@yahoo.com Sent: Sun, January 3, 2010 4:25:00 PM Subject: Xenified linux kernel Hi Dear: I am refering to the

I've loaded R-0.50-a1 but when I try to apply the patches it cannot find the files to apply patches to. [9] gilp/R0.50 : patch <R-0.50-a1.patch1 Looks like a new-style context diff. File to patch: [10] gilp/R0.50 : [10] gilp/R0.50 : [10] gilp/R0.50 : cd R-0.50-a1 [11] gilp/R0.50/R-0.50-a1 : ls CHANGES RESOURCES configure.mac* COPYING TASKS configure.win* COPYRIGHTS TASKS.OLD

http://bugs.freedesktop.org/show_bug.cgi?id=24830 Summary: Some characters are not drawn well, missing vertical lines with NVIDIA NV18 Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh, why not just use ices with a perl song choser module ? This eliminates the need to develop the libshout based streamer (use ices instead) and give ices the title from your module, ices will take care of the rest. Or I am wrong ? :) On Wed, 25 Feb 2004, Renaud Waldura wrote: > For what's it's worth, I do something similar to this

We're running a setup with M3W on a PC in Sri Lanka, encoding to a server in the UK. What factors govern the time delay between things being said to the microphone in SL and heard by a client connecting to the server, and how can we reduce it as much as possible? Currently we're experiencing 20-30 secs or more.