25 Nov
2012
25 Nov
'12
11 a.m.
Long ago, I've read many people recommending setting relaxed permissions
on /dev/rtc for using programs like Muse, and I remember back in the
early 2000's even seeing MPlayer requiring this and complaining on the
console when it couldn't get it.
Pretty much all distros now set default permissions of 0600 root:root on
/dev/rtc now, and MPlayer works now anyway. Is it still necessary or
recommended these days for proper operation of audio apps to have a
user-accessible /dev/rtc? Is there a security risk? Do regular users
need write access, or would a mode like 0640 root:realtime be
sufficient?
Also, I notice there is a /dev/hpet node too. Same questions apply
there, since I would imagine HPET gives the best time of all.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
25 Nov
25 Nov
1:23 p.m.
Brent Busby wrote:
Is it still necessary or recommended these days for
proper operation
of audio apps to have a user-accessible /dev/rtc?
Not really. Using the RTC or HPET devices directly is necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
You'd need this only if you're using some audio application that hasn't
been updated for many years.
Is there a security risk?
The risk was that handling interrupts at a frequency of 8 kHz would not
leave enough CPU time for applications. I doubt that you have any CPU
where this is actually the case.
Regards,
Clemens
3:32 p.m.
On Sunday 25 November 2012 08:44:57 Clemens Ladisch did opine:
Brent Busby wrote:
Chuckle. You are worried about an 8 kilohertz IRQ?
I have an app on this machine that uses about a 25khz IRQ, Actually slow
because this quad core phenom at 2.1Ghz, has lousy latency test figures,
and were this machine better suited, the app could ask for 50 kilohertz or
better.
It is however, tied to this kernel version:
2.6.32-122-rtai
Because RTAI, when enabled, actually becomes the top dog to do that, with
the kernel playing 2nd fiddle, all other apps get what time is left over.
But everything else on this machine still continues to function albeit at a
slightly slower speed. So it is actually running right now as I type this.
The reason for its existence on this machine is that I do have 2 machines
out in the shop that are suitable for running at a 40+ kilohertz loop rate,
my lathe and my desktop milling machine are both running this same install.
They are running it on Intel "atom" D525MW boards with 2Gb of dram. On that
board, absolute worst case latency is 7 microseconds that might occur while
opening something like firefox. Normal runs 2 to 3. Microseconds. Great
mobo for us, very low power and dirt cheap. But no expansion facilities to
plug in any fancy sound cards. But it does have decent onboard video and
sound, but I haven't tested the sound, it would be hard to hear well when a
6 pack of nema 23 sized double and triple stack stepper motors are growling
as they go about their work, carving steel to thousandth of an inch
accuracies.
FWIW, if I have any xruns or stutters in the sound here, its generally
because my net connection is only a 3 megabit from cable & that can get a
bit stuttery of an evening when the cable folks big pipe gets loaded up.
It not a big enough problem to make me yell at the cable folks.
Point is, low latency CAN be done. On 260 USD machines that are ready to
run OOTB. 250Gb SATA hard drive, and an optical dvd writer/reader.
But now I am curious. The cd to install this is available from
<http://www.linuxcnc.org/index.php/english/download>
I'd be interested in finding out if this approach would do you folks any
good with your latency related problems.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Think twice before speaking, but don't say "think think click click".
Is it still necessary or recommended these days
for proper operation
of audio apps to have a user-accessible /dev/rtc?
Not really. Using the RTC or HPET devices directly is necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
You'd need this only if you're using some audio application that hasn't
been updated for many years.
Is there a security risk?
The risk was that handling interrupts at a frequency of 8 kHz would not
leave enough CPU time for applications. I doubt that you have any CPU
where this is actually the case.
Regards,
Clemens
8:05 p.m.
On Sun, 25 Nov 2012, Clemens Ladisch wrote:
Brent Busby wrote:
Ok, that explains why it's been a long time since I've seen those device
permissions actually break anything. The reason I ask though is because
the web site for Muse still has a section on making sure /dev/rtc is
accessible:
http://muse-sequencer.org/index.php/Faq#RTC_Timer
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
Is it still necessary or recommended these days
for proper operation
of audio apps to have a user-accessible /dev/rtc?
Not really. Using the RTC or HPET devices directly is necessary only
if the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
You'd need this only if you're using some audio application that
hasn't been updated for many years. 
9:17 p.m.
On 11/25/2012 01:23 PM, Clemens Ladisch wrote:
Brent Busby wrote:
What are those timer API's?
Is it still necessary or recommended these days
for proper operation
of audio apps to have a user-accessible /dev/rtc?
Not really. Using the RTC or HPET devices directly is necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
You'd need this only if you're using some
audio application that hasn't
been updated for many years.
So this section has become deprecated?
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti…
If so I'll remove it.
And how does the snd-hrtimer module relate to this matter?
Regards,
Jeremy
Is there a
security risk?
The risk was that handling interrupts at a frequency of 8 kHz would not
leave enough CPU time for applications. I doubt that you have any CPU
where this is actually the case.
Regards,
Clemens
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
26 Nov
26 Nov
3:03 p.m.
Jeremy Jongepier wrote:
Only if all applications actually have been updated.
Wasn't there some sequencer (Rosegarden? Muse?) that still uses RTC?
On 11/25/2012 01:23 PM, Clemens Ladisch wrote:
POSIX timers, interval timers, nanosleep(), usleep(), poll() timeout.
Using the RTC or HPET devices directly is
necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
What are those timer API's? You'd need
this only if you're using some audio application that hasn't
been updated for many years.
So this section has become deprecated?
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti… And how does the snd-hrtimer module relate to this
matter?
It's for some timers used internally by ALSA, and loaded automatically.
Regards,
Clemens
4:24 p.m.
On Mon, 26 Nov 2012, Clemens Ladisch wrote:
Jeremy Jongepier wrote:
Only if all applications actually have been updated.
Wasn't there some sequencer (Rosegarden? Muse?) that still uses RTC?
Can you imagine any reason why an app using /dev/rtc or /dev/hpet would
need write access, or would it be sufficient to do something like 0640
root:realtime ?
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
On 11/25/2012 01:23 PM, Clemens Ladisch wrote:
POSIX timers, interval timers, nanosleep(), usleep(), poll() timeout.
Using the RTC or HPET devices directly is
necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
What are those timer API's? You'd
need this only if you're using some audio application that hasn't
been updated for many years.
So this section has become deprecated?
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti…
27 Nov
27 Nov
11:41 a.m.
On 11/26/2012 03:03 PM, Clemens Ladisch wrote:
Only if all applications actually have been updated.
Wasn't there some sequencer (Rosegarden? Muse?) that still uses RTC?
No idea. But I think I'm going to modify that section anyway because
apparently setting permissions on /dev/rtc and/or /dev/hpet is not
necessary anymore (in general).
In what kind of situations would it load automatically? Because it never
does on my machines, I have to either load it myself or add it to
/etc/modules
Software like Qtractor can use it too when the module is loaded. Is this
recommended? Does it improve MIDI timing for instance? How does it
compare to the default timer setting?
Regards,
Jeremy
Jeremy Jongepier wrote:
Thanks. Having played around with cyclictest I have a slight notion of
what this all means ;)
On 11/25/2012 01:23 PM, Clemens Ladisch wrote:
POSIX timers, interval timers, nanosleep(), usleep(), poll() timeout.
Using the RTC or HPET devices directly is
necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
What are those timer API's? You'd need this only if you're using some
audio application that hasn't
been updated for many years.
So this section has become deprecated?
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti… And how does
the snd-hrtimer module relate to this matter?
It's for some timers used internally by ALSA, and loaded automatically.
Regards,
Clemens
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
12:39 p.m.
On Tue, 2012-11-27 at 11:40 +0100, Jeremy Jongepier wrote:
Software like Qtractor can use it too when the module
is loaded. Is
this recommended? Does it improve MIDI timing for instance? How does
it compare to the default timer setting?
If you use hardware MIDI the different PCM timers or
hr timer can improve jitter or sync between audio and MIDI or whatever,
at least it results in different drift for MIDI and audio, if you record
e.g. one MIDI channel after the other using hardware MIDI.
Usually system timer (default) is the best way to go,
hr timer is better, but can cause issues, PCM timer should be less good,
but there could be some voodoo when using it, that could improve things.
If you don't use hardware MIDI don't care about it and use default,
resp. system timer.
This is what I experienced. Sometimes people fall out a plane when
flying very high, without a parachute and they survive. There's no
rational explanation.
"Default" is default for good reasons, to have other options can help,
but if you don't have issues, there's no reason to care about those
optional timers.
Regards,
Ralf
12:55 p.m.
On 11/27/2012 12:38 PM, Ralf Mardorf wrote:
On Tue, 2012-11-27 at 11:40 +0100, Jeremy Jongepier
wrote:
What do you mean by hardware MIDI? External synths? So when only using
soft synths using snd-hrtimer doesn't make any difference at all?
Software like Qtractor can use it too when the
module is loaded. Is
this recommended? Does it improve MIDI timing for instance? How does
it compare to the default timer setting?
If you use hardware MIDI the different PCM timers or
hr timer can improve jitter or sync between audio and MIDI or whatever,
at least it results in different drift for MIDI and audio, if you record
e.g. one MIDI channel after the other using hardware MIDI.
Usually system timer (default) is the best way to go,
hr timer is better, but can cause issues,
What kind of issues?
PCM timer should be less good,
but there could be some voodoo when using it, that
could improve things.
If you don't use hardware MIDI don't care about it and use default,
resp. system timer.
This is what I experienced. Sometimes people fall out a plane when
flying very high, without a parachute and they survive. There's no
rational explanation.
"Default" is default for good reasons, to have other options can help,
but if you don't have issues, there's no reason to care about those
optional timers.
For me there's another reason, it's not about personal use. I just want
to know how this timer stuff actually works so that I can update the
timers section on the linuxmusicians.com Wiki in such a way that it
makes sense. It's now a bit jibber jabber because I actually have no
real clue how all these different timers affect the Linux audio experience.
Regards,
Jeremy
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:32 p.m.
Jeremy Jongepier wrote:
On 11/26/2012 03:03 PM, Clemens Ladisch wrote:
In theory, always. But it might be possible that it forgets to tell
udev about itself ...
Jeremy Jongepier wrote:
In what kind of situations would it load automatically? And how does the snd-hrtimer module relate to
this matter?
It's for some timers used internally by ALSA, and loaded automatically. Does it improve MIDI timing for instance?
If the ALSA sequencer is used for MIDI event scheduling.
How does it compare to the default timer setting?
It uses 1000 Hz. Typically, HZ is less than that.
Regards,
Clemens
12:10 p.m.
Hi,
2012/11/26 Clemens Ladisch <clemens(a)ladisch.de>de>:
Jeremy Jongepier wrote:
Only if all applications actually have been updated.
Wasn't there some sequencer (Rosegarden? Muse?) that still uses RTC?
MusE first tries RTC, if that doesn't work it will try Alsa and be
happy with that if the aquired frequency is high enough.
Regards,
Robert
On 11/25/2012 01:23 PM, Clemens Ladisch wrote:
POSIX timers, interval timers, nanosleep(), usleep(), poll() timeout.
Using the RTC or HPET devices directly is
necessary only if
the kernel does not use them for timers. Nowadays, kernels do, and
applications use the proper timer APIs.
What are those timer API's? You'd
need this only if you're using some audio application that hasn't
been updated for many years.
So this section has become deprecated?
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti…
4191
days inactive
4193
days old
linux-audio-user@lists.linuxaudio.org
12 comments
6 participants
participants (6)
-
Brent Busby -
Clemens Ladisch -
Gene Heskett -
Jeremy Jongepier -
Ralf Mardorf -
Robert Jonsson