Hi, have you tried to patch your Kernel for Real Time ?
Best, Thomas Le 30/05/10 01:30, Andrew a écrit : > I have ran a few more tests of my own, which I thought I would pass along: > > The primary machine that I have experienced this issue on is: > VIA C7 Processor 1000MHz with 512MB of RAM > FreeBSD 7.1 i386. > Liquidsoap 0.9.2-2 using OSS input module > aotuv 20090303 libvorbis (http://www.geocities.jp/aoyoume/aotuv/) > > For AAC+, metadata updates are actually sent over HTTP to icecast, just like > MP3. I believe that the AAC+ streams are skipping when this occurs as well, > but I am more concerned about Vorbis, so I have run these tests using a > single vorbis stream. I have found that regardless of the quality level > (-2.0, -1.0, 0), the skips can occur during metadata changes. In some > situations I have found that the stream continues to loop the same audio over > and over again and does not get unstuck until liquidsoap is restarted, which > is really bad. > > I was able to make the skips occur by rapidly copy and pasting "meta.insert > title='metadata'" over and over again into the telnet session. When skips > occurred they were quite noticeable. > > I noticed this in top: > > Under normal conditions: > CPU: 35.2% user, 0.0% nice, 2.2% system, 3.7% interrupt, 58.8% idle > > During metadata updates: > CPU: 98.9% user, 0.0% nice, 0.7% system, 0.4% interrupt, 0.0% idle > > (It took me awhile to be able to copy-paste this from top as the CPU quickly > spiked up and then went right back down) > > Interestingly enough, I performed the same tests on an Intel(R) Pentium(R) 4 > CPU 3.00GHz with 1GB of RAM, again running FreeBSD 7.1 i386. The skips also > occurred on this machine but they were far less noticeable. The audio just > had a little "blip" in it on metadata updates. > > So it appears that there is a quick spike in CPU usage that is happening on > metadata updates, which is exemplified on slower hardware. > > I would really like to get liquidsoap working on this machine. Is there > anything that can be done? I would be more than happy to run any more tests > or help out in any other way. > > Thanks! > Andrew > > On 2010-05-21, at 2:25 AM, David Baelde wrote: > > >> This is a known but elusive bug for Ogg streams. For AAC+ I'd say that >> it's no surprise: I believe the external encoder is restarted when new >> metadata arises, which is obviously time consuming. For Ogg streams, >> there's no good reason. I have recently made some experiments [1] to >> observe precisely the lag incurred by new metadata in Ogg/Vorbis >> encoded streams but failed to see it on my setup. >> >> I'd understand that you don't feel like reproducing my experiments to >> see what kind of result you get; we developers should try some >> variations to see if we observe anything funny. Can you confirm the >> problem with a simple script involving a single file (or even a sine) >> output to both a vorbis file and soundcard? If so, please also >> indicate your version of libvorbis and libogg. >> >> Hopefully, we'll stumble on a clue... >> -- >> David >> >> [1] http://www.lix.polytechnique.fr/~dbaelde/drift/clocks.html >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
