I don't believe that FreeBSD has a Real Time kernel patch. My understanding is 
that is a Linux thing.

Andrew

On 2010-05-30, at 5:57 AM, [email protected] wrote:

> 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


------------------------------------------------------------------------------

_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to