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

Reply via email to