19 Oct
2009
19 Oct
'09
10:41 p.m.
The best way to test if your Linux setup is ready for audio, I think, is
here:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Download the .pl file, make it executable, and run it in a terminal. In
other words, in a terminal:
wget
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl
chmod +x realTimeConfigQuickScan.pl
./realTimeConfigQuickScan.pl | less
and study the results. My hardware is such that realtime kernel is not
necessary, and I'm not sure about 'noatime' on the filesystems, but
everything else it reports has been extremely valuable. AVLinux ran
well before I did all the things it requested; after I did them, it
began to run screamingly.
There is a list of multimedia-oriented distros on that page, but some of
the listings are alpha quality, no longer in existence, et cetera.
J.E.B.
19 Oct
19 Oct
11:40 p.m.
2009/10/20 Jonathan E. Brickman <jeb(a)joshuacorps.org>
The best way to test if your Linux setup is ready for
audio, I think, is
here:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Download the .pl file, make it executable, and run it in a terminal. In
other words, in a terminal:
wget
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl
chmod +x realTimeConfigQuickScan.pl
./realTimeConfigQuickScan.pl | less
and study the results. My hardware is such that realtime kernel is not
necessary, and I'm not sure about 'noatime' on the filesystems, but
everything else it reports has been extremely valuable. AVLinux ran
well before I did all the things it requested; after I did them, it
began to run screamingly.
There is a list of multimedia-oriented distros on that page, but some of
the listings are alpha quality, no longer in existence, et cetera.
J.E.B.
noatime means no record of access time:
http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6s…
Since on a Linux system files are written to almost every minute, recording
atime everytime an access occurs increases the disk I/O.
I need to know access times for some files so I don't quite like that. I use
relatime: http://kerneltrap.org/node/14148
Such tests like to assume a lot of things, so I don't like those either.
Anyway this isn't really a test, it's just a mockup a user put up because he
was asking for something similar and realised there was no answer.
20 Oct
20 Oct
5:47 a.m.
On Tue, Oct 20, 2009 at 09:39:50AM +0800, Ray Rashif wrote:
Since on a Linux system files are written to almost
every minute,
recording atime everytime an access occurs increases the disk I/O.
I'm not sure that is right; the way you put it.
Perhaps you mean "Since on a Linux system files are read from almost
every minute, recording atime every time a read occurs increases the
write disk I/O."
atime on a file is changed whenever the file is read. The change is
buffered in memory for a while; usually no more than a minute, then is
written out to disk.
So atime causes at least one disk write I/O for a set of disk read I/Os.
It certainly does impact performance ... if it is not needed.
I need to know access times for some files so I
don't quite like that.
I use relatime: http://kerneltrap.org/node/14148
Another method is to place these files in a separate filesystem with
atime enabled.
--
James Cameron
http://quozl.linux.org.au/
5:45 a.m.
2009/10/20 James Cameron <quozl(a)us.netrek.org>
On Tue, Oct 20, 2009 at 09:39:50AM +0800, Ray Rashif
wrote:
I actually meant to type "read from", but thanks for correcting :)
Since on a Linux system files are written to
almost every minute,
recording atime everytime an access occurs increases the disk I/O.
I'm not sure that is right; the way you put it.
Perhaps you mean "Since on a Linux system files are read from almost
every minute, recording atime every time a read occurs increases the
write disk I/O."
atime on a file is changed whenever the file is read. The change is
buffered in memory for a while; usually no more than a minute, then is
written out to disk.
So atime causes at least one disk write I/O for a set of disk read I/Os.
It certainly does impact performance ... if it is not needed.
I need to know access times for some files so I
don't quite like that.
I use relatime: http://kerneltrap.org/node/14148
Another method is to place these files in a separate filesystem with
atime enabled. 
22 Oct
22 Oct
4:18 a.m.
On Mon, Oct 19, 2009 at 07:41:52PM -0500, Jonathan E. Brickman wrote:
The best way to test if your Linux setup is ready for
audio, I think, is
here:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Download the .pl file, make it executable, and run it in a terminal. In
other words, in a terminal:
wget
http://realtimeconfigquickscan.googlecode.com/hg/realTimeConfigQuickScan.pl
chmod +x realTimeConfigQuickScan.pl
./realTimeConfigQuickScan.pl | less
and study the results. My hardware is such that realtime kernel is not
necessary, and I'm not sure about 'noatime' on the filesystems, but
everything else it reports has been extremely valuable. AVLinux ran
well before I did all the things it requested; after I did them, it
began to run screamingly.
There is a list of multimedia-oriented distros on that page, but some of
the listings are alpha quality, no longer in existence, et cetera.
Thank you, that is an extremely useful tool.
It caught two errors on my EEE, one of which I knew about, and the other was a ttotally
new thing to me.
I know my kernel doesn't have HZ=1000, becuase when I do that, it doesn't boot.
So, sorry, no 1000Hz timer.
But it also caught this other weird thing I'd never heard of:
fs.inotify.max_user_watches = 524288
Which was easy enough to fix.
Fascinating. Thanks again!
-ken
11:48 a.m.
On Wed, 21 Oct 2009 23:25:36 -0700
Scott <lau(a)troutpocket.org> wrote:
Ken Restivo wrote:
I'm also very curious about this one as I've never heard of it before
and haven't seen any help that explains what it does.
It wrongly assumes a tmpfs has to be on /tmp and nice doesn't help with
rt stuff afaik.
I'm also not quite sure about the filesystem related stuff it checks
for, like the use of atime or whatever.
I'd say the script is a nice start but nothing to rely on or use as
definitiv guideline.
But it also caught this other weird thing I'd
never heard of:
fs.inotify.max_user_watches = 524288
Which was easy enough to fix.
What sort of problem were you having that changing that setting fixed?
-Scott 
2:19 p.m.
hollunder(a)gmx.at wrote:
On Wed, 21 Oct 2009 23:25:36 -0700
Scott <lau(a)troutpocket.org> wrote:
Since we're on the subject of improving performance I should share one
little thing I learned recently. I use Fedora+CCRMA. The Fedora update
manager is python based. After disabling the automatic update service I
eradicated virtually all xruns. I asked a more knowledgeable friend why
this may be and he told me that Python is/can be greedy with resources.
YMMV.
-Scott
Ken Restivo wrote:
I'm also very curious about this one as I've never heard of it before
and haven't seen any help that explains what it does.
It wrongly assumes a tmpfs has to be on /tmp and nice doesn't help with
rt stuff afaik.
I'm also not quite sure about the filesystem related stuff it checks
for, like the use of atime or whatever.
I'd say the script is a nice start but nothing to rely on or use as
definitiv guideline.
But it also caught this other weird thing I'd
never heard of:
fs.inotify.max_user_watches = 524288
Which was easy enough to fix.
What sort of problem were you having that changing that setting fixed?
-Scott
2:27 p.m.
New subject: Test if Linux is ready for audio (realtimeconfigquickscan.pl script)
Scott Ecker wrote:
Since we're on the subject of improving performance I should share one
little thing I learned recently. I use Fedora+CCRMA. The Fedora update
manager is python based. After disabling the automatic update service I
eradicated virtually all xruns. I asked a more knowledgeable friend why
this may be and he told me that Python is/can be greedy with resources.
YMMV. Thanks, good tip.
\r
see also:
http://linuxmusicians.com/viewtopic.php?f=27&t=452&st=0&sk=t&am…
hollunder(a)gmx.at wrote:
> On Wed, 21 Oct 2009 23:25:36 -0700
> Scott <lau(a)troutpocket.org> wrote:
>
>
>
>> Ken Restivo wrote:
>>
>>
>>> But it also caught this other weird thing I'd never heard of:
>>> fs.inotify.max_user_watches = 524288
>>>
>>> Which was easy enough to fix.
>>>
>>>
>>>
>> What sort of problem were you having that changing that setting fixed?
>>
>> -Scott
>>
>>
> I'm also very curious about this one as I've never heard of it before
> and haven't seen any help that explains what it does.
>
+1 , I think it was found in the Rosegarden wiki maybe?
> It wrongly assumes a tmpfs has to be on /tmp and
nice doesn't help with
> rt stuff afaik.
>
I think its in the FAQ of jackaudio.org
> I'm also not quite sure about the filesystem
related stuff it checks
> for, like the use of atime or whatever.
>
> I'd say the script is a nice start but nothing to rely on or use as
> definitiv guideline.
>
It would be nice if could improve the script by more feedback of people
here on LAU
7:32 p.m.
New subject: Test if Linux is ready for audio (realtimeconfigquickscan.pl script)
rosea grammostola wrote:
Scott Ecker wrote:
Since we're on the subject of improving performance I should share one
little thing I learned recently. I use Fedora+CCRMA. The Fedora update
manager is python based. After disabling the automatic update service I
eradicated virtually all xruns. I asked a more knowledgeable friend why
this may be and he told me that Python is/can be greedy with resources.
YMMV.
Thanks, good tip.
hollunder(a)gmx.at wrote:
> On Wed, 21 Oct 2009 23:25:36 -0700
> Scott <lau(a)troutpocket.org> wrote:
>
>
>
>
>> Ken Restivo wrote:
>>
>>
>>
>>> But it also caught this other weird thing I'd never heard of:
>>> fs.inotify.max_user_watches = 524288
>>>
>>> Which was easy enough to fix.
>>>
>>>
>>>
>>>
>> What sort of problem were you having that changing that setting fixed?
>>
>> -Scott
>>
>>
>>
> I'm also very curious about this one as I've never heard of it before
> and haven't seen any help that explains what it does.
>
>
+1 , I think it was found in the Rosegarden wiki maybe?
> It wrongly assumes a tmpfs has to be on /tmp
and nice doesn't help with
> rt stuff afaik.
>
>
I think its in the FAQ of jackaudio.org
> I'm also not quite sure about the
filesystem related stuff it checks
> for, like the use of atime or whatever.
>
> I'd say the script is a nice start but nothing to rely on or use as
> definitiv guideline.
>
>
It would be nice if could improve the script by more feedback of
people
here on LAU
From the horse's mouth:
It has to do with Python's lack of support for
signals in threads.
https://bugzilla.gnome.org/show_bug.cgi?id=481569
http://dev.laptop.org/ticket/4680
The Red Hat people have put a lot of work into fixing this, along with
Sugar.
Python apps which initialize threads will end up waking every 1/10th
of a second, rather than idling properly.
-Scott
8:15 p.m.
New subject: Test if Linux is ready for audio (realtimeconfigquickscan.pl script)
On Thu, Oct 22, 2009 at 02:32:17PM -0700, Scott wrote:
Actually, PyGTK applications. The update manager relies on PyGTK.
Python applications not dependent on PyGTK are unaffected.
--
James Cameron
http://quozl.linux.org.au/
From the
horse's mouth:
It has to do with Python's lack of support for signals in threads.
https://bugzilla.gnome.org/show_bug.cgi?id=481569
http://dev.laptop.org/ticket/4680
The Red Hat people have put a lot of work into fixing this, along with
Sugar.
Python apps which initialize threads will end up waking every 1/10th of a
second, rather than idling properly. 
8:45 p.m.
New subject: Test if Linux is ready for audio (realtimeconfigquickscan.pl script)
On Thu, Oct 22, 2009 at 02:32:17PM -0700, Scott wrote:
So what ? Many apps wake up at that frequency or higher and don't
cause any problem at all by doing so. Every Jack app will wake up
at period rate, typically more than 100Hz.
The problem discussed in the links above seems to be related
more to PyGTK than Python in general.
Here at the CdS all the audio systems are controlled by multi-
threaded 'master' programs written in Python. The threads are
handling network connections and updating the wireless remote
control apps (running on EEE's) all the time, normally at 25
Hz or close. I've never seen an xrun here.
Hint: don't run NetworkManager.
Ciao,
--
FA
From the
horse's mouth:
> It has to do with Python's lack of support for signals in threads.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=481569
> http://dev.laptop.org/ticket/4680
>
> The Red Hat people have put a lot of work into fixing this, along with
> Sugar.
>
> Python apps which initialize threads will end up waking every 1/10th
> of a second, rather than idling properly.
5557
days inactive
5560
days old
linux-audio-user@lists.linuxaudio.org
12 comments
9 participants
participants (9)
-
fons＠kokkinizita.net -
hollunder＠gmx.at -
James Cameron -
Jonathan E. Brickman -
Ken Restivo -
Ray Rashif -
rosea grammostola -
Scott -
Scott Ecker