I'll have to try this adaptive buffer, thanks. I looked at it some more, with data from several DJ's scattered across North America.
The DJ's streaming from New York (which is where the liquidsoap server is located), had uniformly perfect buffer statuses. In fact, one DJ even had a buffer whose size *increased* as his show went along! But the DJ's streaming from the west coast all uniformly had the same pattern of degradation: the buffer gradually decreasing over time. Now, unless sound cards run at different rates based on where they are physically located on the North American continent, I'm inclined to think the problem is one of network latency not of sound card sample rate. I have not taken inventory of which specific soundcards they are all using, but I'd guess it's the usual mix of SoundBlaster's, HDAIntels, and what not. I thought about perhaps there being some weirdness with power regulation and voltage: perhaps the east coast of the USA runs at 120VAC and the west coast at 115VAC or similar, or perhaps differences in the cycle frequency of the mains AC (60.1 Hz in east coast and 59.9Hz on west coast?) but the PC's power supplies, rectifiers, and voltage regulators should even all that out long before the soundcard gets its +5VDC powering its clock. Or am I missing something? -ken -- -------- On Mon, Oct 27, 2014 at 05:41:04AM -0700, David Baelde wrote: > Hi, > Depending on the DJʼs source client, the computerʼs clock can have an > impact too. > Anyway, if this is a serious issue you might want to look at an > operator that Samuel added not so long ago. Something like > buffer.adaptative iirc. > HTH > david > Brad Isbell a écrit: > > All sound cards run at slightly different rates. What you're looking > at is an encoder sending data at a slightly slower rate than you are > expecting. What is 44.1kHz to the DJ that is sending you data may > very well be 44.098kHz to the rest of the world. > The same problem occurs on the playback side of things. Some clients > will run faster, some will run slower. In practice, it doesn't matter > much. Most listeners don't listen long enough for there to be a > problem, and those that do will simply rebuffer for a second or two. > > [] Brad Isbell // AudioPump > [email protected] > Skype: bradisbell > Phone: +1 312-488-4680 > On Fri, Oct 24, 2014 at 10:55 AM, Ken Restivo <[email protected]> wrote: > > Trying to wrap my brain around this data: > http://spaz.org/~ken/damfree2.pdf > That's a DJ connecting from a good DSL setup. The degradation is > very slow, and eventually hits a wall and stops, then starts again, > and then begins anew its descent. > I'm pretty sure their sample rate is set to 44.1khz (the same as the > server), but not entirely sure. Could it be sample rate mismatch, > but with the buffer taking much longer to empty than I've seen > before in sample-rate-mismatch cases? Or something else? Clocks out > of sync? It's baffling. > Thanks. > -ken > -------------------------------------------------------------------- > ---------- > _______________________________________________ > Savonet-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/savonet-users > > > > ----------------------------------------------------------------------- > ------- > ------------------------------------------------------------------------------ > _______________________________________________ > Savonet-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/savonet-users ------------------------------------------------------------------------------ _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
