1 Nov
2012
1 Nov
'12
12:28 p.m.
Changing file permissions didn't solve it.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission
denied precise timer not available, check file permissions and allowed
RTC freq (/sys/class/rtc/rtc0/max_user_freq) Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 72
Muse 2.0.1 Ubuntu Quantal amd64
Any hints are welcome!
Regards,
Ralf
12:49 p.m.
On Thu, 2012-11-01 at 12:42 +0100, Clemens Ladisch wrote:
I'm still curious about the RTC timer issue.
Regards,
Ralf
Ralf Mardorf wrote:
I don't know. I'll test MusE, never used it before. FWIW the output is
the same with and without hr timer enabled.
RtcTimer::setTimerFreq(): cannot set freq 1024 on
/dev/rtc: Permission denied
Why would MusE try to do that?
AlsaTimer::initTimer(): best available ALSA timer: system timer
This timer is better anyway. 
12:45 p.m.
you need to be root (su/sudo)
echo 2048 > /sys/class/rtc/rtc0/max_user_freq
Am 01.11.2012 12:28, schrieb Ralf Mardorf:
Changing file permissions didn't solve it.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission
denied precise timer not available, check file permissions and allowed
RTC freq (/sys/class/rtc/rtc0/max_user_freq) Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 72
Muse 2.0.1 Ubuntu Quantal amd64
Any hints are welcome!
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:02 p.m.
On Thu, November 1, 2012 4:28 am, Ralf Mardorf wrote:
Changing file permissions didn't solve it.
Shouldn't have to, should be in group audio by default.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission
denied precise timer not available, check file permissions and allowed
RTC freq (/sys/class/rtc/rtc0/max_user_freq) Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 72
Muse 2.0.1 Ubuntu Quantal amd64
Any hints are welcome!
edit /etc/rc.local and add a line before the exit like:
echo 3072 >/sys/class/rtc/rtc0/max_user_freq
Also, may not be needed here but recommended for other apps, edit the last
line of /etc/sysctl.d/50-ubuntustudio.conf to uncomment:
dev.hpet.max-user-freq=3072
We have been testing this and had been unable to see any difference with
it enabled or not in MIDI jitter etc. I am not sure if there are downsides
to setting these (more cpu usage for example), but personally I would give
up cpu usage for better sound.
Please let me know if this helps and I will make it the default.
--
Len Ovens
www.OvenWerks.net
2 Nov
2 Nov
10:20 a.m.
On Thu, 2012-11-01 at 14:02 -0700, Len Ovens wrote:
On Thu, November 1, 2012 4:28 am, Ralf Mardorf wrote:
Hi Len :)
I started a song yesterday and will continue today.
1. Muse does crash more often than very often ;).
2. echo 3072 >/sys/class/rtc/rtc0/max_user_freq doesn't work, even for
root it's not allowed.
3. However, I'm using Qtractor at the moment. I never made a serious
production with my RME card. using the RME card with the default
lowlatency kernel I still get xruns, when the latency is less good, than
it was with my elCheapo TerraTec cards in the past. The difference is,
that I used the TerraTec cards with kernel-rt only and that the RME card
is forced to share IRQs, while the TerraTec cards get their own IRQs.
I'll continue using the lowlatency kernel, but I'm thinking of building
a kernel-rt, to see if it will improve this situation. CPU load still is
lower than 10%. I hope I get xruns caused by the kernel and not by the
shared IRQ.
All in all audio and MIDI until now is okay, excepted of the issue with
the RME card and Qtractor's usual teething troubles.
Muse in the past also never run on my machine.
Regards,
Ralf
Changing file permissions didn't solve it.
Shouldn't have to, should be in group audio by default.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission
denied precise timer not available, check file permissions and allowed
RTC freq (/sys/class/rtc/rtc0/max_user_freq) Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 72
Muse 2.0.1 Ubuntu Quantal amd64
Any hints are welcome!
edit /etc/rc.local and add a line before the exit like:
echo 3072 >/sys/class/rtc/rtc0/max_user_freq
Also, may not be needed here but recommended for other apps, edit the last
line of /etc/sysctl.d/50-ubuntustudio.conf to uncomment:
dev.hpet.max-user-freq=3072
We have been testing this and had been unable to see any difference with
it enabled or not in MIDI jitter etc. I am not sure if there are downsides
to setting these (more cpu usage for example), but personally I would give
up cpu usage for better sound.
Please let me know if this helps and I will make it the default.
11:23 a.m.
Hi Ralf,
2012/11/2 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
<...>
1. Muse does crash more often than very often ;).
That's sad to hear.
If you can give us any information how to identify these crashes I'd be
very grateful.
2. echo 3072 >/sys/class/rtc/rtc0/max_user_freq
doesn't work, even for
root it's not allowed.
MusE 2.0.1 brings up a popup if the timer it has aquired is to slow (I
think below 500hz frequency). If this doesn't happen I think you can leave
the timing errors for now.
I think Clemens suggested we use the Alsa timer in all cases anyway.
Still, if you want to examine this further there is this page:
http://muse-sequencer.org/index.php/Faq#Proper_timing_source
But I guess this information may be getting out of date too.
Regards,
Robert
1 Nov
1 Nov
11:23 p.m.
On November 1, 2012 12:28:43 PM Ralf Mardorf wrote:
Changing file permissions didn't solve it.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission
denied precise timer not available, check file permissions and allowed
RTC freq (/sys/class/rtc/rtc0/max_user_freq) Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 72
Muse 2.0.1 Ubuntu Quantal amd64
Any hints are welcome!
Regards,
Ralf
Greetings, Ralf, list.
In MusE, the RTC timer is for the ALSA support.
It is similar to the selection of timers found in Rosegarden or QTractor,
except we try to select the timer automatically.
If using only Jack Midi devices in MusE, you need not worry too much
about RTC.
Some things in MusE are really old.
Several years ago the RTC support in Linux was just that -
it operated on the actual RTC on the PC, and was limited in frequency
and only one user at a time.
Yet, for MusE it was often the best choice for a timer.
But since the advent of HPET, the RTC now operates on the HPET timers
instead, and the frequency can be set much higher now, and more than
one user. If I understand all of this stuff correctly.
One of our devs is trying to run MusE on BSD, where there are no ALSA
timers, so we recently revived talking about the RTC and I think Robert
added some better warning messages and info there.
Follow the advice given there, and here, to get the RTC up to spec.
I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree stuff, eh?
Try MusE. It's kind of old-school midi, I understand you have used
midi for a long time, I think you might like it.
Quite literally, it improves by the hour!
The next release is, in my opinion as one of the main devs, going
to be one of its finest ever, where everything kinda comes together
and works as it should have long ago. Many improvements!
Cheers.
Tim.
10:26 a.m.
On Fri, 2012-11-02 at 08:39 +0100, Clemens Ladisch wrote:
Tim E. Real wrote:
FWIW echo foo > /sys/... even as root isn't allowed. I anyway tested
Muse, but it crashed again and again when using it. I never could use
any version of Muse on my machine. Qtractor does work.
Regards
Ralf
I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree stuff, eh?
For four years, ALSA's default has been the high-resolution timer, so
you don't need to try to use anything. 
1:29 p.m.
On Friday 02 November 2012, Clemens Ladisch wrote:
Tim E. Real wrote:
This is true when a program (properly) uses the ALSA Sequencer scheduled
output for MIDI playback, but the last time I've checked MusE it didn't.
This program uses the ALSA timer interface, and immediate MIDI output.
Regards,
Pedro
I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree
stuff, eh?
For four years, ALSA's default has been the high-resolution timer, so
you don't need to try to use anything.
3 Nov
3 Nov
10:50 p.m.
On November 2, 2012 01:29:18 PM Pedro Lopez-Cabanillas wrote:
On Friday 02 November 2012, Clemens Ladisch wrote:
Are you saying that we can't have our ALSA timer usage and make it high-res
as well? Or we must first jump through a few hoops - ie those settings?
ie the ALSA scheduler does not require you to poke the /sys tree, or wherever?
Tim E. Real wrote:
This is true when a program (properly) uses the ALSA Sequencer scheduled
output for MIDI playback, but the last time I've checked MusE it didn't. I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree
stuff, eh?
For four years, ALSA's default has been the high-resolution timer, so
you don't need to try to use anything. This program uses the ALSA timer interface, and
immediate MIDI output.
Yes. I noticed that long ago. I'm not knowledgeable enough (or patient?)
to implement ALSA scheduling but I did read up on it.
Sometimes it's hard to follow docs of various projects when they
don't (can't) show links to kernel header information, or other headers.
But yeah, scheduler definitely much cooler - let ALSA handle all the timing.
Better for high-res, eh?
Question: If we implemented ALSA scheduling instead of 'direct',
that would allow us to remove our ALSA timer usage completely, right?
I mentioned one of our devs is trying to get MusE running on BSD.
It has a stripped ALSA support package, also found in other distros,
oddly labeled as being specifically for DSSI yet is obviously useful for
everyone. Apparently there are no ALSA timers in this package.
So he made the good point that ALSA needs to be a MusE compile option,
to let Jack handle the particular sound system (OSS).
Slowly getting to that point. I still do remember when I announced our
Jack Midi support that someone in LAD urged the very same, I haven't
forgotten...
Actually our dev asked about removing our ALSA support altogether,
but there are benefits to having a native ALSA driver.
Thanks.
Tim.
4 Nov
4 Nov
10:50 a.m.
On Saturday 03 November 2012, Tim E. Real wrote:
Yes.
On November 2, 2012 01:29:18 PM Pedro Lopez-Cabanillas
wrote:
No. I am not saying that. I've said that this ALSA's default setting is only
applicable when you use ALSA sequencer scheduled output.
And this setting is available as a kernel configuration option
(CONFIG_SND_SEQ_HRTIMER_DEFAULT) so it may be changed by the distros, or the
user compiling the kernel.
On Friday 02 November 2012, Clemens Ladisch
wrote:
Are you saying that we can't have our ALSA timer usage and make it
high-res as well? Tim E. Real wrote:
This is true when a program (properly) uses the ALSA Sequencer
scheduled output for MIDI playback, but the last time I've checked
MusE it didn't. I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree
stuff, eh?
For four years, ALSA's default has been the high-resolution timer, so
you don't need to try to use anything. Or we must first jump through a few hoops - ie those
settings? ie the ALSA scheduler does not require you to poke the /sys
tree, or wherever?
ALSA timer interface can also be used to get access to high resolution
timers, but you need to request this global timer class explicitly.
If you want an example, look at drumstick-timertest:
http://drumstick.sourceforge.net/docs/timertest.cpp-example.html
This program
uses the ALSA timer interface, and immediate MIDI output.
Yes. I noticed that long ago. I'm not knowledgeable enough (or patient?)
to implement ALSA scheduling but I did read up on it.
Sometimes it's hard to follow docs of various projects when they
don't (can't) show links to kernel header information, or other headers.
But yeah, scheduler definitely much cooler - let ALSA handle all the
timing. Better for high-res, eh?
Question: If we implemented ALSA scheduling instead of 'direct',
that would allow us to remove our ALSA timer usage completely, right? I mentioned one of our devs is trying to get MusE
running on BSD.
It has a stripped ALSA support package, also found in other distros,
oddly labeled as being specifically for DSSI yet is obviously useful for
everyone. Apparently there are no ALSA timers in this package.
So he made the good point that ALSA needs to be a MusE compile option,
to let Jack handle the particular sound system (OSS).
Slowly getting to that point. I still do remember when I announced our
Jack Midi support that someone in LAD urged the very same, I haven't
forgotten...
Actually our dev asked about removing our ALSA support altogether,
but there are benefits to having a native ALSA driver.
Thanks.
Tim.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3 Nov
3 Nov
10:09 p.m.
On November 2, 2012 08:39:17 AM Clemens Ladisch wrote:
Tim E. Real wrote:
Ah thanks for the tip.
Does it mean poking the settings in /sys (or wherever) still applies?
i.e. if we want better performance from the ALSA timer we should
poke those settings?
Thanks.
Tim.
I believe there is an RTC/HPET library now.
We should probably try to use it instead of this awkward /sys tree stuff,
eh?
For four years, ALSA's default has been the high-resolution timer, so
you don't need to try to use anything.
Regards,
Clemenbs
4446
days inactive
4449
days old
linux-audio-user@lists.linuxaudio.org
13 comments
7 participants
participants (7)
-
Clemens Ladisch -
hermann meyer -
Len Ovens -
Pedro Lopez-Cabanillas -
Ralf Mardorf -
Robert Jonsson -
Tim E. Real