20 Nov
2004
20 Nov
'04
6 p.m.
Hello,
now that my audio inteerface is working, I can try the wealth of audio
applications.
Starting the SuSE supplied muse (0.7.0) it refuses to start cause it cannot
use /dev/rtc. Since I used the audio group also for providing the realtime
capabilities, I changed the group and mode of /dev/rtc to
crw-rw---- 1 root audio
But then it gives the following error message:
cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control)
für das Gerät
precise timer not available
What is missing? Do I have to update the provided muse to a newer version?
Uwe
20 Nov
20 Nov
7:02 p.m.
Hi Uwe,
lördagen den 20 november 2004 22.59 skrev Uwe Koloska:
Hello,
now that my audio inteerface is working, I can try the wealth of audio
applications.
Starting the SuSE supplied muse (0.7.0) it refuses to start cause it cannot
use /dev/rtc. Since I used the audio group also for providing the realtime
capabilities, I changed the group and mode of /dev/rtc to
crw-rw---- 1 root audio
But then it gives the following error message:
cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control)
für das Gerät
precise timer not available
What is missing? Do I have to update the provided muse to a newer version?
I just posted another message here which I think is exactly the same issue. I
believe something has changed or gone broken in recent 2.6 kernels that cause
this behaviour.
Could you give some more info about your system? Mainly kernel version.
/Robert
Uwe
--
http://spamatica.se/music/
21 Nov
21 Nov
8:15 a.m.
enter as root
"echo 1024 > /proc/sys/dev/rtc/max-user-freq"
this allows users to set rtc frequencies up to 1024 Hz
/werner
On Saturday 20 November 2004 21:59, Uwe Koloska wrote:
Hello,
now that my audio inteerface is working, I can try the wealth of audio
applications.
Starting the SuSE supplied muse (0.7.0) it refuses to start cause it cannot
use /dev/rtc. Since I used the audio group also for providing the realtime
capabilities, I changed the group and mode of /dev/rtc to
crw-rw---- 1 root audio
But then it gives the following error message:
cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control)
für das Gerät
precise timer not available
What is missing? Do I have to update the provided muse to a newer version?
Uwe
1:06 p.m.
Hi Werner,
söndagen den 21 november 2004 14.16 skrev Werner Schweer:
enter as root
"echo 1024 > /proc/sys/dev/rtc/max-user-freq"
I had tried that previously, tried it again and it does not work for me
atleast.
this allows users to set rtc frequencies up to 1024 Hz
Right, and since I'm currently trying as root it shouldn't make any
difference.
I get the feeling something is seriously wrong with the RTC. I tried:
cat /dev/rtc
which I recall previously just meant that the cat hanged on the device.
Now if I do this it returns with the error:
cat: /dev/rtc: Input/output error
I got a mail suggesting that it could have something to do with HPET, High
Precision Event Timers. Don't know if that's included in this kernel, will
check.
Regards,
Robert
/werner
On Saturday 20 November 2004 21:59, Uwe Koloska wrote:
> Hello,
>
> now that my audio inteerface is working, I can try the wealth of audio
> applications.
>
> Starting the SuSE supplied muse (0.7.0) it refuses to start cause it
> cannot use /dev/rtc. Since I used the audio group also for providing the
> realtime capabilities, I changed the group and mode of /dev/rtc to
> crw-rw---- 1 root audio
> But then it gives the following error message:
> cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control)
> für das Gerät
> precise timer not available
>
> What is missing? Do I have to update the provided muse to a newer
> version?
>
> Uwe
--
http://spamatica.se/music/
3:25 p.m.
söndagen den 21 november 2004 19.39 skrev Lee Revell:
On Sun, 2004-11-21 at 18:06 +0100, Robert Jonsson
wrote:
It's the standard Mandrake 10.1 kernel, haven't started with lowlatency tuning
yet.
Hi Werner,
Is this a custom compiled kernel or a binary? What is the output of:
zgrep RTC /proc/config.gz
I guess you mean /boot/config
It prints:
CONFIG_APM_RTC_IS_GMT=y
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m
/Robert
?
Lee
--
http://spamatica.se/music/
4:02 p.m.
On Sun, 2004-11-21 at 20:25 +0100, Robert Jonsson wrote:
söndagen den 21 november 2004 19.39 skrev Lee Revell:
No, I meant /proc/config.gz. This is such a useful feature that I
sometimes forget it's not enabled on some distros ;-)
On Sun, 2004-11-21 at 18:06 +0100, Robert Jonsson
wrote:
It's the standard Mandrake 10.1 kernel, haven't started with lowlatency tuning
yet.
Hi Werner,
Is this a custom compiled kernel or a binary? What is the output of:
zgrep RTC /proc/config.gz
I guess you mean /boot/config
It prints:
CONFIG_APM_RTC_IS_GMT=y
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m
OK this all looks good. I don't know, it sounds like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package with
a Mandrake kernel.
Try a newer version of Muse. Maybe if you compile it your environment
will be detected correctly.
Lee
8:45 p.m.
Hi all,
[OFF-TOPIC]
On Sun, 21 Nov 2004 15:02:24 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
OK this all looks good. I don't know, it sounds
like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package with
a Mandrake kernel.
Has anyone noticed how cute it sounds when you say that aloud? "SuSE-MusE"?
It's especially funny if you know that both words are correctly pronounced
like "Su:sah-Mu:sah" (yes, I am sure because SuSE is a german company and
I especially asked Werner about correct pronounciation of "MusE" during the
LinuxTag fair in June of this year :-)
Back to work,
Frank
22 Nov
22 Nov
6:23 a.m.
Lee Revell wrote:
OK this all looks good. I don't know, it sounds
like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package with
a Mandrake kernel.
I don't think so -- I have a SuSE 9.2 and this means SuSE kernel
with SuSE MUSe ;-)
Try a newer version of Muse. Maybe if you compile it
your environment
will be detected correctly.
Is there a newer version than 0.7.0?
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
11:01 a.m.
On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell wrote:
Maybe it doesn't look good. I found this (the message is in French,
but the quoted part says it all): if CONFIG_HPET_RTC_IRQ is defined,
then RTC_IRQ is undefined which in turn leads to the failing ioctl().
<http://www.guilde.asso.fr/lurker/message/20041105.180307.b02820a2.en.html>
include/asm-i386/mc146818rtc.h :
#define RTC_IRQ 8
drivers/char/rtc.c :
#ifdef CONFIG_HPET_RTC_IRQ
#undef RTC_IRQ
#endif
.config :
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
drivers/char/Kconfig :
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
depends on ACPI_INTERPRETER
help
If you say Y here, you will have a miscdevice named
"/dev/hpet/". Each open selects one of the timers supported
by the HPET. The timers are non-periodioc and/or periodic.
config HPET_RTC_IRQ
bool "HPET Control RTC IRQ" if !HPET_EMULATE_RTC
default n
depends on HPET
help
If you say Y here, you will disable RTC_IRQ in
drivers/char/rtc.c. It is assumed the platform called
hpet_alloc with the RTC IRQ values for the HPET timers.
--
FA
CONFIG_APM_RTC_IS_GMT=y
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m
OK this all looks good. I don't know, it sounds like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package with
a Mandrake kernel. 
11:33 a.m.
On Mon, 22 Nov 2004, Alfons Adriaensen wrote:
On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell
wrote:
Maybe it doesn't look good. I found this (the message is in French,
but the quoted part says it all): if CONFIG_HPET_RTC_IRQ is defined,
then RTC_IRQ is undefined which in turn leads to the failing ioctl().
Exactly: If you set
CONFIG_HPET_RTC_IRQ=n
and recompile the (SuSE 9.2-)kernel, MusE should work.
Matthias
CONFIG_APM_RTC_IS_GMT=y
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m
OK this all looks good. I don't know, it sounds like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package with
a Mandrake kernel.
<http://www.guilde.asso.fr/lurker/message/20041105.180307.b02820a2.en.html>
include/asm-i386/mc146818rtc.h :
#define RTC_IRQ 8
drivers/char/rtc.c :
#ifdef CONFIG_HPET_RTC_IRQ
#undef RTC_IRQ
#endif
.config :
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
drivers/char/Kconfig :
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
default n
depends on ACPI_INTERPRETER
help
If you say Y here, you will have a miscdevice named
"/dev/hpet/". Each open selects one of the timers supported
by the HPET. The timers are non-periodioc and/or periodic.
config HPET_RTC_IRQ
bool "HPET Control RTC IRQ" if !HPET_EMULATE_RTC
default n
depends on HPET
help
If you say Y here, you will disable RTC_IRQ in
drivers/char/rtc.c. It is assumed the platform called
hpet_alloc with the RTC IRQ values for the HPET timers.
--
Dr. Matthias Nagorni
SuSE Linux GmbH
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
12:45 p.m.
Matthias Nagorni wrote:
Exactly: If you set
CONFIG_HPET_RTC_IRQ=n
and recompile the (SuSE 9.2-)kernel, MusE should work.
And why is it set? Normally there is a reason for doing something
;-) Will this changed setting affect other settings, scripts,
programs, etc.???
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
23 Nov
23 Nov
6:02 a.m.
On Mon, 22 Nov 2004, Uwe Koloska wrote:
Matthias Nagorni wrote:
Since HPET is supported only on machines you definitely won't find as
"Home PC's", the changed setting won't change anything other than fixing
/dev/rtc performance.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux GmbH
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
Exactly: If you set
CONFIG_HPET_RTC_IRQ=n
and recompile the (SuSE 9.2-)kernel, MusE should work.
And why is it set? Normally there is a reason for doing something ;-) Will
this changed setting affect other settings, scripts, programs, etc.???
22 Nov
22 Nov
1:13 p.m.
On Monday 22 November 2004 16.33, Matthias Nagorni wrote:
On Mon, 22 Nov 2004, Alfons Adriaensen wrote:
Ah, good with conclusive proof.
In the meantime I found out about the timer features of ALSA.
http://www.alsa-project.org/alsa-doc/alsa-lib/timer.html
Unless I'm missing something (which I very well might be) it seems to work
regardless. Perhaps it uses the HPET?
It also seems to work on PPC/Linux which solves another issue. I'm in the
middle of trying to implement it in MusE, I guess I'll see if it works.
Regards,
Robert
On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee
Revell wrote:
Maybe it doesn't look good. I found this (the message is in French,
but the quoted part says it all): if CONFIG_HPET_RTC_IRQ is defined,
then RTC_IRQ is undefined which in turn leads to the failing ioctl().
CONFIG_APM_RTC_IS_GMT=y
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_SENSORS_RTC8564=m
CONFIG_SND_RTCTIMER=m
OK this all looks good. I don't know, it sounds like a bug in Muse.
There must be some incompatibility using a binary Suse Muse package
with a Mandrake kernel. Exactly: If you set
CONFIG_HPET_RTC_IRQ=n
and recompile the (SuSE 9.2-)kernel, MusE should work.
--
http://spamatica.se/music/
1:53 p.m.
On Mon, Nov 22, 2004 at 06:13:22PM +0100, Robert Jonsson wrote:
Ah, good with conclusive proof.
In the meantime I found out about the timer features of ALSA.
http://www.alsa-project.org/alsa-doc/alsa-lib/timer.html
Unless I'm missing something (which I very well might be) it seems to work
regardless. Perhaps it uses the HPET?
It also seems to work on PPC/Linux which solves another issue. I'm in the
middle of trying to implement it in MusE, I guess I'll see if it works.
Which leads to the following question I've been asking myself for some time:
the ALSA sequencer API seems to allow *timestamped* events - you put such
an event in a queue and it will appear at the other end at the right moment.
If this is true, and if ALSA has an high precision timer available to
implement it, why should apps like MusE bother to do the fine timing
themselves ?
--
FA
2:20 p.m.
Alfons Adriaensen wrote:
the ALSA sequencer API seems to allow *timestamped*
events - you put such
an event in a queue and it will appear at the other end at the right moment.
If this is true,
It is.
and if ALSA has an high precision timer available to
implement it,
Standard 2.4 kernels don't have an high precision timer, unless the
sound card hardware implements one, or if the RTC patch is used. On
2.6 kernels, the system timer is precise enough.
why should apps like MusE bother to do the fine timing
themselves
?
Probably backwards compatibility (with 2.4 kernels _and_ OSS).
Best regards,
Clemens
2:21 p.m.
(added alsa-devel to cc)
On Mon, 2004-11-22 at 18:53 +0100, Alfons Adriaensen wrote:
Which leads to the following question I've been
asking myself for some time:
the ALSA sequencer API seems to allow *timestamped* events - you put such
an event in a queue and it will appear at the other end at the right moment.
If this is true, and if ALSA has an high precision timer available to
implement it, why should apps like MusE bother to do the fine timing
themselves ?
Yes, my thoughts exactly. You don't even have to use the ALSA sequencer
API, you can use the ALSA timer API directly. You get multiple timer
sources (system, RTC, sound card). It should also be more portable.
For example if your sound card's timer is supported by your ALSA driver
like emu10k1 and ymfpci then I think you can use this timer to give
better sync with the hardware.
ALSA devs, is this correct?
Lee
2:54 p.m.
New subject: [Alsa-devel] Re: [linux-audio-dev] muse and /dev/rtc
At Mon, 22 Nov 2004 13:21:07 -0500,
Lee Revell wrote:
(added alsa-devel to cc)
On Mon, 2004-11-22 at 18:53 +0100, Alfons Adriaensen wrote:
Yes, I agree that ALSA timer API would be useful for such a case. The
app can reject to run or do some workaround if the queried timer
resolution is worse than requirements.
Well, my guess for the next reaction is "the lack of documentation" ;)
Takashi
Which leads to the following question I've
been asking myself for some time:
the ALSA sequencer API seems to allow *timestamped* events - you put such
an event in a queue and it will appear at the other end at the right moment.
If this is true, and if ALSA has an high precision timer available to
implement it, why should apps like MusE bother to do the fine timing
themselves ?
Yes, my thoughts exactly. You don't even have to use the ALSA sequencer
API, you can use the ALSA timer API directly. You get multiple timer
sources (system, RTC, sound card). It should also be more portable.
For example if your sound card's timer is supported by your ALSA driver
like emu10k1 and ymfpci then I think you can use this timer to give
better sync with the hardware.
ALSA devs, is this correct?
8:33 p.m.
New subject: [Alsa-devel] Re: [linux-audio-dev] muse and /dev/rtc
On Mon, 2004-11-22 at 19:54 +0100, Takashi Iwai wrote:
Yes, I agree that ALSA timer API would be useful for
such a case. The
app can reject to run or do some workaround if the queried timer
resolution is worse than requirements.
Well, my guess for the next reaction is "the lack of documentation" ;)
I think the only issue is that adding timer support to a driver is not
documented. I did not even know ALSA had a timer API until it was
pointed out to me on the list, as the driver guide was my main
reference. Adding a chapter to the guide would ensure that new drivers
get timer support.
Lee
8:06 p.m.
On Mon, Nov 22, 2004 at 01:21:07PM -0500, Lee Revell wrote:
Yes, my thoughts exactly. You don't even have to
use the ALSA sequencer
API, you can use the ALSA timer API directly. You get multiple timer
sources (system, RTC, sound card). It should also be more portable.
Yes, but using the sequencer's timing should require less process swaps.
--
FA
8:01 p.m.
the ALSA sequencer API seems to allow *timestamped*
events - you put such
an event in a queue and it will appear at the other end at the right moment.
If this is true, and if ALSA has an high precision timer available to
implement it, why should apps like MusE bother to do the fine timing
themselves ?
how far ahead can you queue without getting into trouble when the user
does realtime edits?
think about this for long enough, and i think you will come to same
conclusion: deliver events in a process-callback-style fashion, more
or less "just in time".
--p
8:38 p.m.
On Mon, Nov 22, 2004 at 07:00:59PM -0500, Paul Davis wrote:
how far ahead can you queue without getting into
trouble when the user
does realtime edits?
think about this for long enough, and i think you will come to same
conclusion: deliver events in a process-callback-style fashion, more
or less "just in time".
Yes, but it's the same with audio: once you have sent your samples to e.g.
ALSA, there's no way back, and it is the hardware that does the final timing
of the samples.
So the key to correct use is in the phrase 'just in time' - it would
probably be a bad idea to queue more than a few tens of milliseconds ahead.
But even using the sequencer in this way would avoid requiring a process
swap for each and every timed event. An efficient way to use it would be
to enqueue the events for the next period inside the JACK process callback,
if the app has audio as well.
--
FA
7246
days inactive
7249
days old
linux-audio-dev@lists.linuxaudio.org
21 comments
12 participants
participants (12)
-
Alfons Adriaensen -
Clemens Ladisch -
Fons Adriaensen -
Frank Neumann -
Lee Revell -
Matthias Nagorni -
Paul Davis -
Robert Jonsson -
Takashi Iwai -
Uwe Koloska -
Uwe Koloska -
Werner Schweer