search for: jackit

...bit too high, it all depends on > the drivers and kernel version but the current state is not that bad and > getting better. There are several ways to gain realtime privileges. Running as root is the simplest, but perhaps the worst solution. This is explained in the JACK FAQ... http://jackit.sourceforge.net/docs/faq.php#a52 -- joq

On Mon, 2004-10-18 at 21:04, Jack O'Quin wrote: > > > > > > There are several ways to gain realtime privileges. Running as root > > > is the simplest, but perhaps the worst solution. > > > > Just to be clear, with ices, you can drop to a nominated user after the > > realtime scheduler is selected. Running as root after that is not > >

On Mon, 2004-10-18 at 22:14, Paul Davis wrote: > jackd (realtime) requires various resources which it shares with its > clients: > > realtime scheduling > mlock-ability > shared memory segments > FIFOs (or Mach ports on OS X) > > we consider it *more* of a security risk to allow jackd-as-root to > share these with non-root processes. YMMV.

Karl Heyes <karl@xiph.org> writes: > On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote: > > Karl Heyes <karl@xiph.org> writes: > > > > > Are you running with realtime privileges, for this you need to start as > > > root if you want that. Even with realtime privileges there may be odd > > > cases where the scheduling latency is a bit too

Hi Guys, I'd reflect Vieri's question actually, because there must be a way of doing it? Maybe not with ICES, but maybe combines with JackIT? The reason for my interest is I work in a radio station in Spain, and because of the geographics where I am we have to relay around a lot. If there is a way of sending an incoming feed into ICES, and sending it out in various directions, would JackIT solve that? Maybe routing before the ICES enco...

>I can't really comment on jackd itself, as I haven't looked that much >into it. If running jackd as root requires client apps to also run as >root then that is a pretty bad issue. I would of thought that running >jackd as a realtime process (whether root or not) would be an important >consideration. jackd (realtime) requires various resources which it shares with its

...hael Smith wrote: > Icecast isn't really designed for doing this. However, you could > re-synchronise on the client side (using a custom client) - there's enough > information in the bitstream (at least if you're using vorbis) to do this. You might also take a look at jack (jackit.sf.net) which can pipe uncompressed audio over a lan fast enough for simultaneous playback, as least assuming the two systems have similar output latency. This uses a lot more bandwidth of course, but won't be significant on a 100 Mbps network. It also won't be a precise at actual synchr...

Hi. I'm new to icecast. I can see that IceS can source an input MIC, for example, from a sound card. Can it also output a playlist to a sound card (to the speakers)? If so, how? Thanks ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list.

Any plans for asterisk to support jack for realtime audio?, http://jackit.sf.net -- Esben Stien is b0ef@esben-stien.name http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:b0ef@esben-stien.name

...d avoid leaks at all costs. Even with massive numbers of sources/clients, these 2 goals alone should keep icecast under the OOM Killer's radar. Here are a couple references: http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-experience/ http://article.gmane.org/gmane.comp.audio.jackit/19998 Cheers, R?mi

...s ago) developers of audio applications from making things work RIGHT NOW, these days the driver support and feature set of ALSA make this the better choice, especially for new developments. I've done quite a few audio projects (multi-channel audio logging) in conjunction with JACK (<http://jackit.sourceforge.net/>) which allowed for truly easy multi-threaded/callback-driven audio I/O that never dropped frames, etc, etc. ALSA is actively maintained and improving, and its driver support has lapped the completeness and correctness of OSS for quite some time now. It also has proper API sup...

On Thu, 19 Aug 2004 00:50:58 +0100, Karl Heyes wrote: > On Wed, 2004-08-18 at 22:12, Joern Nettingsmeier wrote: >> karl, ralph, thanks for the hints. >> >> paul, i'm forwarding this to you as well, since pointer to the >> ices-kh sources on jackit-devel turned out to be dead... >> >> karl, i would like to ask the jack website maintainer to add a >> prominent link to ices-jack, where should it point to? the ices page >> on icecast.org does not yet mention it... > > Until a more permanent place is determined f...

...ere's interesting sound deterioration due to repeated ogg-encoding/decoding and noise buildup.here's me toying around with my bass and such a setup: > http://spunk.dnsalias.org/download/netjam.ogg if you have problems setting up jack, i suggest we discuss this on linux-audio-user or the jackit list, it's probably not interesting for most people here. best, j?rn -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan J?rn...

I am starting to work with the speex API under Linux. Simple question what audio system should I target? OSS or Alsa? I looked at portaudio and it targets OSS and it seems to work fine but am I limiting myself? alsa does emulate OSS so it seems the best to target.

hello people, while thinking about the next little fiesta at my place, together with a friend of mine we were talking about streaming our selected music to different rooms within our location. actually it would be only two clients that would have to catch the stream. we are running one linux box which would serve the stream. the clients would be that same box and another ms windows machine.

>From what I have read on some mailing lists, there is a jack module for ices2 that works quite well. Why isn't this information on the ices2 web page or documentation? Ices is useless to me without this, yet so awesome with it. I saw requests from people for you to do this over a month ago. What's the problem? Thanks, Daniel P.S. I couldn't search this list to find out if

Hi, > On Fri, 2011-04-29 at 09:05 +0200, Peter J. Philipp wrote: >> You don't check for malloc failure. I've made a patch that is possibly >> wrong but it saves the program from SIGSEGV and replaces it with SIGABRT. On Fri, 29 Apr 2011, Philipp Schafft wrote: > But I have a question: > Not all of them (only had a brief look at the patch) look to be in a >

i have been working on a voip client that goes head-to-head with skype in technological terms. for this, we used speex wide-band codec. without the denoiser or the pre-processor, i find that speex quality at 16 khz sampling, 16-bit samples (mono) to be clearly superior to anything that skype offers. even though, at the moment, i am not using packet loss compensation, i find that speex is

Just a few weeks ago, I was thinking of writing a streaming source using libshout and portaudio. I was also considering LADSPA support, to do some minor post-processing before encoding. However, I'm currently developing on Mac OS X, and LADSPA's shared library plugin model has some issues here to be resolved. Another nice feature I have given a thought on is incorporating

Hello Does anyone have experience with _real_ real time streaming - i.e. with very little delay/latency? I need to stream from point A to point B in near-CD quality via a 100 Mbit network. That is easily done using icecast. But here is the tricky bit: I want as little delay in the signal as possibble - preferrably below 50ms! I have made a test setup encoding on and serving from an 800 MHz