similar to: Increasing Icecast input buffering ?

Good morning, On Wed, 2016-10-19 at 09:57 +0200, Jean-Marc Coursimault wrote: > Hello, > > My question is : is there a way to have Icecast buffer the input / > increase the input buffering ? Even though the latency would increase ? > Why : On some radio streams, the listeners to a Icecast stream > experience very frequent silences / disconnections. There is no input buffer

Hello all, Though I''ve read all I could about the "Lost connection to MySQL server during query: SHOW FIELDS FROM ...", I''m still unable to use RoR. I''m on Linux Mandriva 2006 / MySQL-4.1.12 / ruby-1.8.2 - The userid/password have access to the database and the table (it''s the root user on MySQL) - I''m on a nonstandard socket/port, but

Hi guys , I'm writing in the mailing list for asking if tou know some script or system linke Mrtg for see the bandwitch usage of every mountpoin. Thanks Pierpaolo Gull?

> behavior you are seeing....(that also is a difference between iceast1 and > icecast2 - no server-side buffering in icecast2 and there was in > icecast1)... What do you mean stream buffering? We never buffered in either version that I remember. If you fall behind, you get kicked. It's always been that way. jack. --- >8 ---- List archives: http://www.xiph.org/archives/

Hi, I am running the latest CVS version of Icecast2, updated as of this moment. One thing I've noticed since I've started using Icecast2, is that Icecast2 is quite slow with its pre-buffering - even with only 1 or 2 users connected to a 24Kbps relayed MP3 stream. The load on the p2-233 server (128mb RAM) is minimal, it usually stays below 0.08. I first thought this was related to my

hi, I doing some tests streaming from a connection in South Africa that seems to have difficulty handling even a 32kbps stream. Unfortunately there is no scope to upgrade the connection. The stream will go live to radio in London and hence a client has to have as consistent a connection as possible. I was wondering if there are any tricks to reducing buffering on the client in this kind of

On 02/24/2015 03:30 PM, Dean Sauer wrote: > On Tue, 24 Feb 2015 12:56:11 +0000, Thomas B. R?cker wrote: > >> Have you modified any of the buffer or burst parameters in Icecast? Can >> you provide your icecast.xml (passwords removed) as an attachment? >> > The list seems to dislike xml so hopefully this won't get stripped. > You're posting through the gmane

Geoff Shang wrote: > > This raises a question I've been meaning to ask for awhile. Is there > any reason why we have both burst on connect and burst size? > Compatibility with older versions? The burst size parameter would seem > to be sufficient if setting it to 0 disables it. The burst on connect was introduced as a setting in an earlier queuing implementation. As

> > Is it true ? And if it is, is there any way to change that behavior ? > > Yes. Icecast always sends data at the data rate. This behavior will > not change in the 1.3.x branch. We will however try and make > prebuffering as fast as possible in 2.x (it's currently done the same > way, but we plan to add this feature). Doesn't icecast send the data out as fast as

Hello, I'm not sure whether this message belongs to the "broadcast" side of Icecast, but.. I'm broadcasting a few radio stations but I always have level problems. Either the sound is too low, either it saturates. There's a very fine line between the two and the broadcasters are not always paying attention to the output level. Some radios are on Oddcast / XP, some on

Hi all I'm Toni from Italy and i have a problem with Icecast2 and IceS. I've get the source code from cvs and i installed them an a linux machine with 2.4.18 kernel (mandrake 8.2) with any problem. I've modified the conf files of icecast2 and IceS and I've done a playlist.txt file... i started icecast2 and IceS with no problems, (im using some .ogg with 96.00 kbps) no error comes

On Fri, Feb 05, 2016 at 04:58:45PM -0800, Mehdi Amini wrote: > > > On Feb 5, 2016, at 3:17 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and > > we've found that one of the top consumers of memory is the DWARF emitter in

Hi there, I think I've found a bug in the x86 JIT. I get an assertion failure when using thread-local variables and the fast emitter. It only happens with the JIT, the fast emiiter and thread-locals. (The IR passes the verifier) Here's the failure: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*):

Hi Jim, The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete encoding in plain 0’s and 1’s, to be as precise as possible during the scheduling process. I did

> try using the quality tags instead of nominal-bitrate as that currently > implies the managed mode which is more CPU hungry. The quality value > will depend on the samplerate but at 44.1khz try <quality>-0.5</quality> exists anywhere some complete icecast (not ices) tag list ? Sometimes I'm confused with ices and icecast tags, and I don't know if both uses the same

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it

On Fri, Feb 5, 2016 at 5:51 PM Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Feb 5, 2016, at 5:40 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Fri, Feb 05, 2016 at 04:58:45PM -0800, Mehdi Amini wrote: > >> > >>> On Feb 5, 2016, at 3:17 PM, Peter Collingbourne via llvm-dev < > llvm-dev at

Yes your absolutely right, the Opcode and the Operands in each machine instruction are sufficient to generate the final binary representation of the MachineInstruction but not exactly. If you take a look at the format of each MIPS instruction, you’ll see that there are some fixed bits for each instruction which are not available inside the machine instruction object –From what I saw so far-.

Hi all, when trying to build LLVM+Clang (r180247) on a BlueGene/Q, I get the following error message (multiple times): llvm[3]: Building PPC.td code emitter with tblgen llvm-tblgen: Unknown command line argument '-gen-emitter'. Try: '/homea/jjsc13/jjsc1301/.pool/.build/llvm_r180241/Release+Asserts/bin/llvm-tblgen -help' llvm-tblgen: Did you mean '-mc-emitter'? Has

Dear Philipp, I've compiled it from source on my raspberry pi, and replaced the binary from the synaptic package manager with the compiled one. Everyting is working fine now, it seems that there is indeed a "faulty" package in the repository. I don't know who I should contact to get this fixed? Anyway, it works, but while using ogg as output stream from mopidy, I get a delay of