Re: [linux-audio-dev] muse and /dev/rtc
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
Re: [linux-audio-dev] muse and /dev/rtc
On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell wrote: 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. 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
Re: [linux-audio-dev] muse and /dev/rtc
On Mon, 22 Nov 2004, Alfons Adriaensen wrote: On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell wrote: 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. 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 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
[linux-audio-dev] cli midi
Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? Preferably it would work on SMF as well as realtime (ALSA), and have filters to filter out undesirables (e.g. active sensing or perhaps sysex). If such a beast doesn't exist, I'll probably hack something up for myself. If I do, would there be interest in my releasing it? -- .O. Hans Fugal| De gustibus non disputandum est. ..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg OOO| WindowMaker, gaim, UTF-8, RISC, JS Bach - GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460 signature.asc Description: Digital signature
Re: [linux-audio-dev] muse and /dev/rtc
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
Re: [linux-audio-dev] muse and /dev/rtc
On Monday 22 November 2004 16.33, Matthias Nagorni wrote: On Mon, 22 Nov 2004, Alfons Adriaensen wrote: On Sun, Nov 21, 2004 at 03:02:24PM -0500, Lee Revell wrote: 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. 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(). 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 Exactly: If you set CONFIG_HPET_RTC_IRQ=n and recompile the (SuSE 9.2-)kernel, MusE should work. -- http://spamatica.se/music/
Re: [linux-audio-dev] cli midi
Hans Fugal [EMAIL PROTECTED] writes: Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? I remember once having had such a tool for ALSA sequencer at least, but I appear to have forgotten how it was called and can't find it either. Preferably it would work on SMF as well as realtime (ALSA), and have filters to filter out undesirables (e.g. active sensing or perhaps sysex). Yay, mididump, that would be very useful. If such a beast doesn't exist, I'll probably hack something up for myself. If I do, would there be interest in my releasing it? Yes, if it works with SMF and realtime with ALSA seq (and probably raw alsa midi devices) I'd very much be interested in that. -- CYa, Mario
Re: [linux-audio-dev] muse and /dev/rtc
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
Re: [linux-audio-dev] cli midi
Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? You could try some of the examples in Gary Scavone's RtMidi: http://www.music.mcgill.ca/~gary/rtmidi/ Best, Ge!
Re: [linux-audio-dev] cli midi
Hans Fugal wrote: Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? arecordmidi --dump; or the tool I posted last week: http://sourceforge.net/mailarchive/message.php?msg_id=10069180 (amidi --dump is human-readable, too, if you happen to have the right human at hand. ;-) HTH Clemens
Re: [linux-audio-dev] muse and /dev/rtc
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
Re: [linux-audio-dev] muse and /dev/rtc
(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
Re: [linux-audio-dev] cli midi
Es geschah am Montag 22 November 2004 17:30 als Hans Fugal schrieb: Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? Preferably it would work on Never used, but have a look at 'midge': http://www.dmriley.demon.co.uk/code/midge/ The following taken from Debian's package description: Description: A text to MIDI program Midge generates MIDI files from text input. Most General MIDI features are supported, and there are some basic methods of randomly generating sequences. Also included is a decompiler and an emacs mode. CU Christian
Re: [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: 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? 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
Re: [linux-audio-dev] cli midi
On Monday 22 November 2004 18:07, Hans Fugal wrote: Is there an app that will dump midi events in human-readable format to stdout (or a file, or gui window, whatever)? Preferably it would work on SMF as well as realtime (ALSA), and have filters to filter out undesirables (e.g. active sensing or perhaps sysex). The following utilities are included on newest alsa-utils packages. Both can print the incoming MIDI events as human readable text in realtime. amidi (using ALSA raw MIDI interface) amidi is a command-line utility which allows to receive and send SysEx (system exclusive) data from/to external MIDI devices. It can also send any other MIDI commands. -d, --dump Prints data received from the MIDI port as hexadecimal bytes. Active Sensing bytes (FEh) will not be shown, unless the -a option has been given. arecordmidi (using ALSA sequencer) arecordmidi is a command-line utility that records a Standard MIDI File from one or more ALSA sequencer ports. -d,--dump Shows the events received as text on standard output. For SMF files, both Fluidsynth and Timidity can do so. $ timidity -idvvv music.mid $ fluidsynth -v music.mid You can also try my little utilities in C and Pascal, including a midi monitor utility with GUI interface for Kylix that you can find here: http://perso.wanadoo.es/plcl/ Regards, Pedro
[linux-audio-dev] Alsa OSS emulation
Hi (Takashi?)! The OSS emulation in ALSA is slightly wrong regarding number of requested buffers. To quote from my own notes to self from own source: /** Setting up the soundcard for CD-HiFidelity Stereo * */ audio.path = /dev/dsp; audio.speed = SAMPLERATE; audio.format= AFMT_S16_LE; audio.is_stereo = TRUE; // 3 buffers of 256 bytes == 3 * 64 (16bit) stereo samples // 0x0002 buffers == n - 1, although Alsa (mis)interpretes oss buffers // == n!!! Use 0x0003! // // 0008 bytes == log2(number of bytes in buffer), 2^8 == 256 == 64 // stereo samples; audio.bufsize = 0x00030008; ... so ALSA UNDERSHOOTS the number of buffers BY ONE (which of course will not work for RT-people on the edge.) mvh // Jens M andreasen PS: Thanks to the mdk10.1 beeing distributed on DVD by LinuxFormat this month, work is ongoing for a clean alsa solution of my handyworks ... DS
Re: [linux-audio-dev] muse and /dev/rtc
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
[linux-audio-dev] New releases
Hello LAD, New releases of Aeolus and JAAA are available at the usual place : users.skynet.be/solaris/linuxaudio. From the Aeolus-0.3.1 README : * Added 'instability'. Each pipe is individually phase modulated in order to emulate the random fluctuations in a real one. This provides for a much more natural sound, in particular for long sustained notes. CPU load has gone up a bit, but not too much. * New reverb. Comments invited. * Added stereo position slider. Internally Aeolus uses a full 3-D sound format (which you can use with the -B, -C 4 or -C 8 options). The stereo output is derived from a 'virtual stereo microphone' placed in the 3-D sound field. The apparent position can be set anywhere between 'back' and 'front'. * Divisions II and III can now be put at the back. * Wavetables can now be saved to disk. They will be used when Aeolus is later started with the same sample frequency and tuning, giving 'immediate satisfaction'. * New option -W directory to select the wavetables loaded on start. * New default colors, a bit warmer than before. * Added -name name option, this permits multiple instances when running under JACK. * New 32 stop. In fact just the Trombone 16 scaled down by one octave and tweaked a bit, but quite spectacular if your speakers can handle it. There's also a new demo file, Xmas.ogg (I know it's a bit early :-). For JAAA-0.1.2 : * Added -name name option, this permits multiple instances when running under JACK. Both apps need an update of clxclient.so, version 1.0.1. Enjoy ! -- Fons
Re: [linux-audio-dev] muse and /dev/rtc
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
Re: [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
Re: [linux-audio-dev] muse and /dev/rtc
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
[linux-audio-dev] LAC2005: Paper templates are online
Hi all, a short announcement for those who might plan to do a presentation at the next Linux Audio Conference in April 2005 in Karlsruhe: The paper templates for OpenOffice and LaTeX are now available at: http://www.zkm.de/lac/downloads.shtml We are a little late with this for which I am sorry, but I hope you were not blocked in writing your papers. Reminder: The deadline for paper submissions (as well as music, workshops, project notes, posters) is January 10th, 2005. For more details about the conference and the calls for paper etc, please visit the web page at http://www.zkm.de/lac. Greetings, Götz Dipper Matthias Nagorni Frank Neumann
