similar to: very low bandwidth encoding

I'm rebroadcasting a realplayer stream and there are two problems. The icecast2 sounds tinny and its delayed something like 3secs. Any advice to perhaps use speex as it's talk radio? Can I cut the delay? Here is my ices2 config: http://static.natalian.org/2006-06-21/ices-alsa.xml Here is details of the feed, so you can take a listen:

Hi, (this is my first post here) A previous thread, starting Date: Tue 19 Nov 2002 - 06:09:56 EST "[vorbis] need speech and music in one" http://www.xiph.org/archives/vorbis/200211/0142.html expressed needs similar to mine, to encode a lengthy speech at low bitrate. I did some tests initially in September then concluded in December, and I was surprised to find Vorbis to be the best

I am trying to use the speex echo canceler and preprocessor with sipXtapi to develop a sip user agent. the sipXmedialib call flow graph uses 10ms frames and I am not sure what the implications are if I try to change this. The documentation seemed to indicate that a 20ms frame was recomended, but it didn't go into the consquences of using other frame sizes. We are going to use headsets

I have an Icecast server and an Asterisk dialplan containing a call to ICES(/my/ices.xml). So Asterisk launches "ices /my/ices.xml" where /my/ices.xml contains: <input> <module>stdinpcm</module> <param name="rate">8000</param> <param name="channels">1</param> </input> and <encode>

This patch adds a new option "channel-mapping" to opusenc which sets the channel mapping family used by the multistream encoder. Please let me know whether adding this option is worthwhile and whether the help string is okay. I tried to keep it short but accurate. The error message for an unimplemented channel mapping is "Error cannot create encoder: request not implemented".

While integrating 1.1, I ran into some errors with my compiler and, after examining the code, saw what might be some invalid pointer math in opus_encoder.c. In optimize_framesize(), the first parameter 'x' is typed as opus_val16 and pointer math is done on the variable (in the 'if (buffering)' block) and then x is passed to the downmix function. I see that the downmix function uses

Me again.... After getting regular playlist streaming working, I'm not trying to complete the project and implement the live streaming. Unfortunately, due to the sad, lacking documentation for icecast and ices (especially what the xml tags in the configuration files actually DO and how they can be used), I've run into another snag that only you guys can help me out with. Here it goes.

On Aug 07 08:30:31, hans at stare.cz wrote: > On Aug 07 00:41:52, petrparizek2000 at yahoo.com wrote: > > ????#1. To test encoding at low bitrates, I encoded a sine sweep at 12 kbps > > with Opusenc and then decoded the resulting file with Opusdec. > 1) Opusenc --bitrate 12 --downmix-mono Sweep50.wav Sweep50.opus Why are you using a stereo file containing the same sweep in both

Folks: I'm trying to set up a streaming server under Fedora Core 2 using Icecast 2.2.0. Everything compiles; everything runs. There are no indications of a problem in any of the log files. When I look at http://192.168.0.128:8000/status.xsl, everything looks ok. But when I click on "Click to listen", it brings up xmms, but there's no indication of audio, and xmms shows a bit

The prospect of people actually putting B-format audio (via the panner or directly input) into Ogg/Vorbis brings an interesting challenge: What do we do with the audio after decoding it? The following sane options exist: A) Simply output the B-format audio B) Produce a downmix 1) Mono. 2) Stereo blumlein crossed pairs 3) Stereo UHJ 4) binaural C) Produce speaker feeds 1) Fully

Hi, I would like to create an output file with mono audio. How to do it ? If use a video with mono as input, the result will be a video with stereo. Is there a way to use the --downmix from oggenc ? Regards -- ZikZak

Stack: (gdb) bt #0 0x0000000000aaf38a in silk_VAD_GetNoiseLevels (pX=pX at entry=0x7f26740297a0, psSilk_VAD=psSilk_VAD at entry=0x15897c38) at silk/VAD.c:315 #1 0x0000000000aa4a9d in silk_VAD_GetSA_Q8_sse4_1 (psEncC=0x15897c18, pIn=<optimized out>) at silk/x86/VAD_sse.c:177 #2 0x0000000000a9f92b in silk_encode_do_VAD_FLP (psEnc=psEnc at entry=0x15897c18) at

On Sun, 2003-11-23 at 00:35, Kerry Cox wrote: > Now I tried to add a third stream by adding the following <instance> to > the above config: > > <instance> > <hostname>xx.xxx.x.xxx</hostname> > <port>8000</port> > <password>secretpasswd</password> >

Hi fellow streamers ;-) I am trying to add an user authenticated mount point to our Icecast2.2 server. I include the relevant section of my config file below. <mount> <mount-name>/stream1</mount-name> <max-listeners>100</max-listeners> <fallback-mount>/test</fallback-mount> <fallback-override>1</fallback-override>

> geoff@bumpy:src$ grep -ine shout_strerror stream.c > 151: shout_strerror(sdsc->conn.error)); > 185: shout_strerror(sdsc->conn.error)); > 208: shout_strerror(sdsc->conn.error)); > > all of these generated errors. Those are correct. Now what does your $prefix/include/shout/shout.h have? Also, I bet you that it's

Hi Jean-Marc, gdb out is "Program terminated with signal 8, Arithmetic exception." most likely this division by zero. you're right, this crash is reproduce on seq number 4294967265 (20ms rtp packet). This is about 994 days. "Jean-Marc Valin" <jmvalin at jmvalin.ca> писал(а):Hi Dmitry, > >So it's not explicitly in your report, but it looks like the crash

Hy, I've just installed the latest release of icecast2 and ices from CVS. I have a linux Slackware 9.0 with the default packages. After install of ices and icecast & relative libraries (with no errors), I've started the icecast server. When starts ices, this is the debug: --- INFO ices-core/main ices started... INFO input-oss/oss_open_module Opened audio device /dev/dsp at 2

On Sat, 7 Jun 2003, Karl Heyes wrote: > your sound card/driver does not deal with 44100hz samplerates, try 48000 > instead. Remember to change the resample tags according. Are there many cards in this category? I'dve thought that all cards would support 44100, it being the standard that it is. Your comments however suggest experience of this problem. Geoff. --- >8 ---- List

Since the opusenc and opusinfo changes were independent I split them up and landed the opusinfo changes (with updated mapping family numbers). - Mark On Thu, Sep 6, 2018 at 4:22 AM, Mark Harris <mark.hsj at gmail.com> wrote: > Hi Drew, > > Sorry for the delay. > > FYI the patch that you attached is not your latest version. This > thread that you replied to is an older

Hi: Well, up until about a week ago, we had our stream up and running on 3 seperate mountpoints and it was rock solid. then we started hitting problems with disconnects and the like. I recompiled everything this morning and set it running again. But one mount has died already. We have 3 streams running. the first is the ogg files as they were encoded (egoplay.ogg). the second is a