I was thinking of trying to use clock.assign_new for this situation as well. Did it seem to help at all?
On Sun, Oct 26, 2014 at 11:45 AM, Ken Restivo <[email protected]> wrote: > On Sat, Oct 25, 2014 at 01:51:22AM -0700, Ken Restivo wrote: >> If I have a situation like: >> >> h = input.harbor(...) >> >> b1 = buffer(fallible=true, h) >> b2 = buffer(fallible=true, h) >> >> output.icecast(...., b1) >> output.file(...., b2) >> >> And the output.icecast is localhost... >> >> Does it still make sense to wrap the output.icecast in a clock.assign_new, >> if the icecast is localhost? There won't be any network lag, for sure. >> > > > I should also note, I've found some strange behavior with the above setup: > the output.file plays correctly but appears to have very few packets between > granulepos increments (with vorbis). > > I am starting to wonder if the above configuration might be problematic. I > might try a clock.assign_new and see if it helps, but I'd sure love to > understand why or why not first. > > -ken > > > ------------------------------------------------------------------------------ > _______________________________________________ > Savonet-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/savonet-users -- -Tony Miller github.com/mcfiredrill @freedrull freedrool.us ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
