J?rn Nettingsmeier:
>
> this looks like it could provide a simple way of granting fixed-deadline
> tasks appropriate cpu time without effectively handing the machine over.
> i was quite skeptical of lennart's idea of a userspace daemon to do the
> job reliably, but the scheduler should have pretty good leverage on
> rogue tasks :)
>
Why do you need a special scheduling mode? If you run a watchdog in the
background, you shouldn't handle the machine over.
*****
plug!
*****
"das_watchdog" should be a properly made watchdog. It has saved
me numerous times, and works gently by temporarily turning off
realtime priority for all processes if something happens.
http://archive.notam02.no/arkiv/src/
[paul, i assume this was meant for the list?]
Paul Davis wrote:
> 2009/10/22 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>:
>> hi everyone!
>
> this:
>
>> A feature of BFS is that it detects when an application tries to obtain a
>> realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
>> appropriate privileges to use those policies. When it detects this, it will
>> give the task SCHED_ISO policy instead. Thus it is transparent to the user.
>> Because some applications constantly set their policy as well as their nice
>> level, there is potential for them to undo the override specified by the user
>> on the command line of setting the policy to SCHED_ISO. To counter this, once
>> a task has been set to SCHED_ISO policy, it needs superuser privileges to set
>> it back to SCHED_NORMAL.
>
> doesn't sound like linux or linus style of policy to me. i'll be
> interested to see what happens.
yeah, that's not exactly a touch of genius, but con's user base are,
well, users. making stuff out of the box is how he attracts testers.
in the long run, this should be a limits.conf thing, but in his position
, "wait for your distro to make this work" is a non-starter.
if bfs ever makes it into mainline, this behaviour will surely be shot
down. but the rest sounds interesting. i wonder how the new deadline
scheduler will compare.
hi everyone!
i just came across con kolivas' announcement of the latest release of
the brain fuck scheduler, http://lwn.net/Articles/357451/ .
in it, he explains the idea behind isochronous scheduling (which lennart
brought up when announcing his realtime kit):
> Isochronous scheduling.
>
> Isochronous scheduling is a unique scheduling policy designed to provide
> near-real-time performance to unprivileged (ie non-root) users without the
> ability to starve the machine indefinitely. Isochronous tasks (which means
> "same time") are set using, for example, the schedtool application like so:
>
> schedtool -I -e amarok
>
> This will start the audio application "amarok" as SCHED_ISO. How SCHED_ISO works
> is that it has a priority level between true realtime tasks and SCHED_NORMAL
> which would allow them to preempt all normal tasks, in a SCHED_RR fashion (ie,
> if multiple SCHED_ISO tasks are running, they purely round robin at rr_interval
> rate). However if ISO tasks run for more than a tunable finite amount of time,
> they are then demoted back to SCHED_NORMAL scheduling. This finite amount of
> time is the percentage of _total CPU_ available across the machine, configurable
> as a percentage in the following "resource handling" tunable (as opposed to a
> scheduler tunable):
>
> /proc/sys/kernel/iso_cpu
>
> and is set to 70% by default. It is calculated over a rolling 5 second average
> Because it is the total CPU available, it means that on a multi CPU machine, it
> is possible to have an ISO task running as realtime scheduling indefinitely on
> just one CPU, as the other CPUs will be available. Setting this to 100 is the
> equivalent of giving all users SCHED_RR access and setting it to 0 removes the
> ability to run any pseudo-realtime tasks.
>
> A feature of BFS is that it detects when an application tries to obtain a
> realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
> appropriate privileges to use those policies. When it detects this, it will
> give the task SCHED_ISO policy instead. Thus it is transparent to the user.
> Because some applications constantly set their policy as well as their nice
> level, there is potential for them to undo the override specified by the user
> on the command line of setting the policy to SCHED_ISO. To counter this, once
> a task has been set to SCHED_ISO policy, it needs superuser privileges to set
> it back to SCHED_NORMAL. This will ensure the task remains ISO and all child
> processes and threads will also inherit the ISO policy.
this looks like it could provide a simple way of granting fixed-deadline
tasks appropriate cpu time without effectively handing the machine over.
i was quite skeptical of lennart's idea of a userspace daemon to do the
job reliably, but the scheduler should have pretty good leverage on
rogue tasks :)
has anyone tried the bfs for audio yet?
best,
jörn
Hallo,
this message is to inform the community that in the next edition of the
the "Salon Linux 2010", in march 2010 in Paris, a french Linux event
including a conference cycle, there will be a session around
professional music and video creation with free software.
You can find the call for contribution at
http://www.confsolutionslinuxparis.com/.
The call talk about contribution and not paper because actually
only a presentation is required, not a paper.
We are looking mostly for overviews of availables solutions or
in depth presentations of mainstream ''products''.
Unfortunately, the communication must be in french :-< ...
Feel free to distribute this mail where do you think it may be
appropriate, or to contact me to get more details.
Maurizio De Cecco
--
Music: http://www.myspace.com/mauriziodececco
Blog: http://maurizio.dececco.name/
Software: http://www.jmax-phoenix.org/
Hi Rui :)
after it failed to send the wanted test to you, because of it's length,
I'm blocked :D.
Sorry LAD list, Rui is waiting for this test and I don't know how to
reach him, while I'm blocked.
Cheers,
Ralf
System Administrator wrote:
> Your message
>
> To: Rui Nuno Capela
> Cc: qtractor-devel(a)lists.sourceforge.net
> Subject: Re: Sound quality of audio recordings at 96 Khz/ 24 Bit
> internal Linux - b4: Re: [solved] 'offset/ note length' issue
> Sent: Tue, 20 Oct 2009 02:47:02 +0200
>
> did not reach the following recipient(s):
>
> rncbc(a)rncbc.org on Tue, 20 Oct 2009 02:47:26 +0200
> You do not have permission to send to this recipient. For
> assistance, contact your system administrator.
> <smtp-out02.alice-dsl.net #5.7.1 smtp;554 5.7.1 Service unavailable;
> Client host [88.44.60.12] blocked using bl.spamcop.net; Blocked - see
> http://www.spamcop.net/bl.shtml?88.44.60.12>
>
> ------------------------------------------------------------------------
>
> Reporting-MTA: dns; HSNMST02V06.hsn.alice-dsl.net
>
> Final-Recipient: RFC822; rncbc(a)rncbc.org
> Action: failed
> Status: 5.7.1
> X-Supplementary-Info: <smtp-out02.alice-dsl.net #5.7.1 smtp;554 5.7.1 Service unavailable; Client host [88.44.60.12] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?88.44.60.12>
> X-Display-Name: rncbc(a)rncbc.org
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Sound quality of audio recordings at 96 Khz/ 24 Bit internal Linux
> - b4: Re: [solved] 'offset/ note length' issue
> From:
> "Ralf Mardorf" <ralf.mardorf(a)alice-dsl.net>
> Date:
> Tue, 20 Oct 2009 02:47:02 +0200
> To:
> "Rui Nuno Capela" <rncbc(a)rncbc.org>
>
> To:
> "Rui Nuno Capela" <rncbc(a)rncbc.org>
> CC:
> <qtractor-devel(a)lists.sourceforge.net>
>
>
>
> > Qtractor didn't show the waveform for the brown noise recording
> > completely, I don't know the reason why and I never had this bug or
> > user error before
>
> After closing and launching Qtractor again and loading the recent file,
> Qtractor showed the complete waveform. While I unmuted pink noise
> Qtractor crashed (auto-closed).
>
-------- Original Message --------
Subject: tar.gz including the sound quality test is to long
Date: Tue, 20 Oct 2009 02:55:21 +0200
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Rui Nuno Capela <rncbc(a)rncbc.org>
CC: qtractor-devel(a)lists.sourceforge.net
Your message
To: Rui Nuno Capela
Subject: Sound quality of audio recordings at 96 Khz/ 24 Bit internal
Linux
did not reach the following recipient(s):
rncbc(a)rncbc.org on Tue, 20 Oct 2009 02:36:57 +0200
This message is larger than the current system limit or the
recipient's mailbox is full. Create a shorter message body or remove
attachments and try sending it again.
It's the same for the dev list.
The tar.gz is < 13 MB. Here is the mail without the attached archive:
-------- Original Message --------
Subject: Sound quality of audio recordings at 96 Khz/ 24 Bit internal Linux - b4: Re: [solved] 'offset/ note length' issue
Date: Tue, 20 Oct 2009 02:31:51 +0200
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: Rui Nuno Capela <rncbc(a)rncbc.org>
CC: qtractor-devel(a)lists.sourceforge.net
Hi Rui :)
first I got some noise references.
spinymouse-sudo@64studio:/usr/src/qtractor/noise$ wget
http://upload.wikimedia.org/wikipedia/commons/6/66/Whitenoisesound.ogghttp://upload.wikimedia.org/wikipedia/commons/6/6c/Pink_noise.ogghttp://upload.wikimedia.org/wikipedia/commons/c/c9/Brownnoise.ogg
Then I set the CPU frequency scaling to "Performance" and launched JACK
and after JACK I run Qtractor.
spinymouse-sudo@64studio:/usr/src/qtractor/noise$ jackd -Rdalsa -dhw:0
-r96000 -p512 -n2 -Xseq
spinymouse-sudo@64studio:/usr/src/qtractor$ qtractor -v
Qt: 4.4.0
Qtractor: 0.4.3.1409
spinymouse-sudo@64studio:/usr/src/qtractor$ qtractor
I Imported the three noise.oggs.
Qtractor didn't show the waveform for the brown noise recording
completely, I don't know the reason why and I never had this bug or user
error before, but it's also the first time I used 0.4.3.1409. I tried to
record it 2 times.
I did stereo recordings for the mono clips too, because this shouldn't
cause any changes for the audible result.
Okay, a completely new problem occurred. There's an audible loss for the
quality of the sound, but in this case because of an understandable
reason. The .ogg files are to loud with faders set to +- 0 db. The
important thing with this is, that the loss of the sound quality for the
white noise is comparable with the kind of loss I've got when doing a
recording of music, even if the maximal signal level is under -3 dBFS.
So it doesn't matter if the meters are Full-Scale Square wave or
Full-Scale Sine Wave meters. Anyway, I wonder where the boost is from.
When I recorded music by connecting Qtractors outputs to its inputs
both, source clip and target clip were 96-24-stereo.wav files. There
never was a visible difference for the volume.
Before I go on comparing music recorded by Qtractor and Audacity, I want
some information because of the strange level for the .ogg files from wiki.
The qtractor session is attached as tar.gz. I suppose you'll have a
directory /usr/src/qtractor too, thus you just need to add a directory
/usr/src/qtractor/noise.
spinymouse-sudo@64studio:/usr/src/qtractor/noise$ ls -l
total 17716
-rw-r--r-- 1 spinymouse-sudo src 155775 2006-10-27 00:24 Brownnoise.ogg
-rw-r--r-- 1 spinymouse-sudo src 8604 2009-10-20 02:21 noise_test.qtr
-rw-r--r-- 1 spinymouse-sudo src 5844866 2009-10-20 01:51
noise_test_qtr-Recorded_brown-1.wav
-rw-r--r-- 1 spinymouse-sudo src 5884802 2009-10-20 01:45
noise_test_qtr-Recorded_pink-1.wav
-rw-r--r-- 1 spinymouse-sudo src 5890952 2009-10-20 01:44
noise_test_qtr-Recorded_white-1.wav
-rw-r--r-- 1 spinymouse-sudo src 161738 2005-07-01 04:36 Pink_noise.ogg
-rw-r--r-- 1 spinymouse-sudo src 130717 2006-10-27 00:09
Whitenoisesound.ogg
spinymouse-sudo@64studio:/usr/src/qtractor/noise$ tar czf
~/Desktop/noise_test_qtr.tar.gz *
Cheers,
Ralf
Hi, I have been developing a fork of the Aldrin tracker. If anyone is
interested you can take a look at it at
http://sites.google.com/site/neilsequencer/ It's main aim is to keep a
stable and usable project with a good plugin set.
Vytautas
I've been playing with Non-sequencer over the last few days, love the simplicity and uncluttered approach to the programme, however I'm finding if run alongside Hydrogen or Ardour, the tempo drifts out of sync, this occurs playing any song longer than a couple of patterns. The obvious answer to this is to have ardour as jack transport master, Non-sequencer does not like this however and crashes. I post the question here rather than Linux Audio Users because I plan to write applications utilising Jack MIDI myself and am wondering the best approach to implement tempo in absence of alsa sequencer, which I found quite nice to use but still jittery even with high res timers / real time kernels.
... seems to have been announced. I got an email from ICMA about it.
Why was it not announced here or in the Consortium list? I would
have thought these are the main places where you find good interest.
Any further news?
Victor
