hello, David Baelde a écrit : > Hi, > > I'm glad that you could work around the glitches and that you're > enjoying liquidsoap -- but, about your bug report, I confirm that you > put your finger on dirty things and I'll fix that soon. > > On Wed, Dec 3, 2008 at 1:40 AM, okay_awright <[EMAIL PROTECTED]> wrote: >> -the input.harbor on_connect and on_disconnect callbacks are really >> great. However, it could also be useful to have this kind of mechanism >> when this function does not produce any stream anymore, without >> disconnecting first, and then resumes streaming. >> e.g. a track played through the Winamp DSP plugin or whatever is now >> over: no sound is broadcast but the source is not disconnected: it could >> be handy to notify any third-party software when it happens, in order to >> take any appropriate measure. >> Maybe there are other ways to achieve this but I wasn't able to find out >> how. > > If I understand correctly, you want to know when the harbor client is > streaming silence. You can't get anything better: with an icy/shout > stream, we can't distinguish silence inside and outside a track. A > solution is to use the on_blank() operator that will call a given > function when a certain amount of blank is detected on a source. > Another solution is to use strip_blank() that will make a source > unavailable when it is streaming too much silence; that would be > combined with a switch above, transitions, etc.
yep, exactly. I knew about the on_blank feature but AFAIK there is no way to get a callback when the stream is up again. >From the logs, it appears liquidsoap was aware of the transient 'no stream available' situation: 2008/11/30 15:22:55 [src_5502:2] Feeding stopped: Mad.End_of_stream 2008/11/30 15:22:55 [threads:3] thread "harbor source feeding" exited but it didn't process this signal as a proper disconnection. > > In case I haven't said enough, there is a summary of blank detection > operators there: > http://savonet.sourceforge.net/doc-svn/blank.html > > Concerning LADSPA I don't have time to check again right now, but the > CPU consumption did not seem absurd to me. In any case, I'm afraid we > can't do much better without changing the whole architecture -- > especially since you already asked gcc to optimize. You talk about > similar apps doing 10-20% CPU: are they using LADSPA as well? That > would be a concern. Do you know a better lib? I do understand, I knew LADSPA plugins are usually not designed to be used for real-time processing (too few, too little choice). The test system was a P4 2.6 w\ 2Gb of RAM (the liquidsoap server is a P4 2.8 w\ 2Gb of RAM) but running Windows XP and either DirectX or VST plugins (there are tons of such plugins as you already know). I've first benchmarked a chain of 3 generic VST components from Steinberg (expander->compressor->limiter for three distinct bands) and then the DirectX version of Izotope Ozone (really impressive BTW). And none stressed the CPU above a mere load of 25% (15-20% was the norm). Sorry, I'm rather new to the audio realm of Linux/Unix and LADSPA is the only unified library that comes to my mind. > > I'm not the expert about the internal sound processing operators. I'm > sure they can be done better, what we have now is only the first > stable implementation -- although it's already far from naive as far > as I can see. You can put a ticket for our idle days, somebody may > pick it up. > > Cheers, thanks for your answer -- best regards, sincèrement, okay_awright <okay_awrightATddcrDOTbiz> Public PGP key on request ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
