[LAD] timers
Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? Some timers can be opened only once ? For example if jackdbus is using hr-timer, no other application can too ? But applications need to use the same timer in order to sync - right ? Which concepts exist to share a certain timer ? How to verify if a timer is working ? Is there tool that would help ? Opening the hr-timer with rosegarden freezes my whole system here, what could cause that ? Thanks Related to my sytem: I get: -- $ lsmod | grep rtc rtc_cmos9680 0 rtc_core 16784 1 rtc_cmos rtc_lib 2844 1 rtc_core But the following command doesn't list any rtc-timer (is that expected, what to do ?): - $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 2 : running Client sequencer queue 0 : running P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-1-0: PCM playback 0-1-0 : SLAVE P0-2-1: PCM capture 0-2-1 : SLAVE P1-3-0: PCM playback 1-3-0 : SLAVE P2-0-0: PCM playback 2-0-0 : SLAVE P2-0-1: PCM capture 2-0-1 : SLAVE P5-0-1: PCM capture 5-0-1 : SLAVE $ ls /dev/rtc* -lh lrwxrwxrwx 1 root root 4 2009-11-05 17:13 /dev/rtc - rtc0 crw-rw 1 root audio 251, 0 2009-11-05 17:13 /dev/rtc0 $ uname -a Linux 2.6.31-rt11-e1 #1 SMP PREEMPT RT Oct 27 CET 2009 i686 GNU/Linux Debian -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client sequencer queue 0 : stopped ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Hi guys, Here is what I have: $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 0 : running P1-0-0: PCM playback 1-0-0 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE Ralf, you do not benefit from a high res timer. See how much more precise the HR timer is from the output above. Check which snd timer you have loaded: $ lsmod | grep timer snd_hrtimer 2148 1 snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm Of course, your h/w should have a HR timer: $ ll /dev/hpet crw-rw 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet you can specify the clock source to jackd: $ jackd --help ... [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ] ... J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:04 AM Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client sequencer queue 0 : stopped ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
I forgot to add that snd_hrtimer is used by jackd. If I turn jackd off, the snd_hrtimer module is not used: $ lsmod | grep timer snd_hrtimer 2148 0 ## not used snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm J. --- On Sat, 11/7/09, James Warden warj...@yahoo.com wrote: From: James Warden warj...@yahoo.com Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de, Ralf Mardorf ralf.mard...@alice-dsl.net Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:34 AM Hi guys, Here is what I have: $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 0 : running P1-0-0: PCM playback 1-0-0 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE Ralf, you do not benefit from a high res timer. See how much more precise the HR timer is from the output above. Check which snd timer you have loaded: $ lsmod | grep timer snd_hrtimer 2148 1 snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm Of course, your h/w should have a HR timer: $ ll /dev/hpet crw-rw 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet you can specify the clock source to jackd: $ jackd --help ... [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ] ... J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:04 AM Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client sequencer queue 0 : stopped ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
Steve Harris wrote: On 5 Nov 2009, at 23:33, David Robillard wrote: On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote: On the LV2 website, Lars Luthman's UI extension is described as: This extension is written for revision 2 of the LV2 specification and is NOT compatible with revisions 3 and later. Do not implement this extension in new plugins or hosts, and do not expect it to work in old ones. It is only available here for archaeological purposes. For anyone genuinely interested and not just taking vain pot shots to further some weird personal vendetta or whatever the hell: The thing that changed in r3 is: persistent references to ports must refer to ports by their symbol, and not their index. Persistent means things on disk that might refer to several versions of a plugin in the future, nothing about the index has actually changed. Plugin data files, host session files, etc. This was a hangover from LADSPA, which had confusing and contradictory claims about what should/shouldn't be used to identify ports. I still don't think there's consensus there. can you elaborate on this? archive links would be good, too. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Thank you Emanuel for this thread :) thank you James for the information :) hopefully this might narrow down my trouble with MIDI jitter for external equipment, OTOH I don't have any MIDI jitter for MIDI internal Linux. ALSA MIDI and JACK MIDI seems to be fine what ever timer I use, this means there is absolutely no jitter when using a Linux sequencer to control a Linux synth. Jitter only occurs when using my USB MIDInterface to control external MIDI equipment. Unfortunately I can't get my Envy24's MPU working. There seems to be no hrtimer available yet: $ lsmod | grep snd_hrtimer $ lsmod | grep timer snd_timer 22024 2 snd_pcm,snd_seq snd63800 21 snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device $ uname -a Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT Thu Feb 26 16:18:05 UTC 2009 x86_64 GNU/Linux Before I start googleing. Is this a feature for 2.6.31 only? I'm still not able to boot the .31 kernel-rt from the Suse 11.2 RC repository and compiling for Suse also failed, but in the past I never had trouble to build kernel-rt for Debian/ Ubuntu based 64 Studio. Maybe I should try to build a kernel .31 for 64 Studio? Or is it just a module I need to add? Or is my hardware missing something? Going to use Google now. Bye, Ralf James Warden wrote: I forgot to add that snd_hrtimer is used by jackd. If I turn jackd off, the snd_hrtimer module is not used: $ lsmod | grep timer snd_hrtimer 2148 0 ## not used snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm J. --- On Sat, 11/7/09, James Warden warj...@yahoo.com wrote: From: James Warden warj...@yahoo.com Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de, Ralf Mardorf ralf.mard...@alice-dsl.net Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:34 AM Hi guys, Here is what I have: $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 0 : running P1-0-0: PCM playback 1-0-0 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE Ralf, you do not benefit from a high res timer. See how much more precise the HR timer is from the output above. Check which snd timer you have loaded: $ lsmod | grep timer snd_hrtimer 2148 1 snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm Of course, your h/w should have a HR timer: $ ll /dev/hpet crw-rw 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet you can specify the clock source to jackd: $ jackd --help ... [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ] ... J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:04 AM Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client sequencer queue 0 : stopped ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg Gromit bit me says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Oops, I forgot something too: spinymouse-s...@64studio:~$ ll /dev/hpet bash: ll: command not found spinymouse-s...@64studio:~$ ls /dev | grep hpet hpet Ralf Mardorf wrote: Thank you Emanuel for this thread :) thank you James for the information :) hopefully this might narrow down my trouble with MIDI jitter for external equipment, OTOH I don't have any MIDI jitter for MIDI internal Linux. ALSA MIDI and JACK MIDI seems to be fine what ever timer I use, this means there is absolutely no jitter when using a Linux sequencer to control a Linux synth. Jitter only occurs when using my USB MIDInterface to control external MIDI equipment. Unfortunately I can't get my Envy24's MPU working. There seems to be no hrtimer available yet: $ lsmod | grep snd_hrtimer $ lsmod | grep timer snd_timer 22024 2 snd_pcm,snd_seq snd63800 21 snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device $ uname -a Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT Thu Feb 26 16:18:05 UTC 2009 x86_64 GNU/Linux Before I start googleing. Is this a feature for 2.6.31 only? I'm still not able to boot the .31 kernel-rt from the Suse 11.2 RC repository and compiling for Suse also failed, but in the past I never had trouble to build kernel-rt for Debian/ Ubuntu based 64 Studio. Maybe I should try to build a kernel .31 for 64 Studio? Or is it just a module I need to add? Or is my hardware missing something? Going to use Google now. Bye, Ralf James Warden wrote: I forgot to add that snd_hrtimer is used by jackd. If I turn jackd off, the snd_hrtimer module is not used: $ lsmod | grep timer snd_hrtimer 2148 0 ## not used snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm J. --- On Sat, 11/7/09, James Warden warj...@yahoo.com wrote: From: James Warden warj...@yahoo.com Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de, Ralf Mardorf ralf.mard...@alice-dsl.net Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:34 AM Hi guys, Here is what I have: $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 0 : running P1-0-0: PCM playback 1-0-0 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE Ralf, you do not benefit from a high res timer. See how much more precise the HR timer is from the output above. Check which snd timer you have loaded: $ lsmod | grep timer snd_hrtimer 2148 1 snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm Of course, your h/w should have a HR timer: $ ll /dev/hpet crw-rw 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet you can specify the clock source to jackd: $ jackd --help ... [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ] ... J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:04 AM Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client sequencer queue 0 : stopped ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Secret of Tux:
Re: [LAD] timers
Ralf, It depends how ALSA was compiled in the kernel. Here is my kernel config related to this matter: CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: James Warden warj...@yahoo.com Cc: Emanuel Rumpf xb...@web.de, linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:36 AM Thank you Emanuel for this thread :) thank you James for the information :) hopefully this might narrow down my trouble with MIDI jitter for external equipment, OTOH I don't have any MIDI jitter for MIDI internal Linux. ALSA MIDI and JACK MIDI seems to be fine what ever timer I use, this means there is absolutely no jitter when using a Linux sequencer to control a Linux synth. Jitter only occurs when using my USB MIDInterface to control external MIDI equipment. Unfortunately I can't get my Envy24's MPU working. There seems to be no hrtimer available yet: $ lsmod | grep snd_hrtimer $ lsmod | grep timer snd_timer 22024 2 snd_pcm,snd_seq snd 63800 21 snd_ice1712,snd_ak4xxx_adda,snd_cs8427,snd_ac97_codec,snd_i2c,snd_mpu401_uart,snd_usb_audio,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device $ uname -a Linux 64studio 2.6.29-1-multimedia-amd64 #1 SMP PREEMPT RT Thu Feb 26 16:18:05 UTC 2009 x86_64 GNU/Linux Before I start googleing. Is this a feature for 2.6.31 only? I'm still not able to boot the .31 kernel-rt from the Suse 11.2 RC repository and compiling for Suse also failed, but in the past I never had trouble to build kernel-rt for Debian/ Ubuntu based 64 Studio. Maybe I should try to build a kernel .31 for 64 Studio? Or is it just a module I need to add? Or is my hardware missing something? Going to use Google now. Bye, Ralf James Warden wrote: I forgot to add that snd_hrtimer is used by jackd. If I turn jackd off, the snd_hrtimer module is not used: $ lsmod | grep timer snd_hrtimer 2148 0 ## not used snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm J. --- On Sat, 11/7/09, James Warden warj...@yahoo.com wrote: From: James Warden warj...@yahoo.com Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de, Ralf Mardorf ralf.mard...@alice-dsl.net Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:34 AM Hi guys, Here is what I have: $ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) G3: HR timer : 0.001us (10 ticks) Client sequencer queue 0 : running P1-0-0: PCM playback 1-0-0 : SLAVE P1-0-1: PCM capture 1-0-1 : SLAVE Ralf, you do not benefit from a high res timer. See how much more precise the HR timer is from the output above. Check which snd timer you have loaded: $ lsmod | grep timer snd_hrtimer 2148 1 snd_timer 17408 3 snd_hrtimer,snd_seq,snd_pcm Of course, your h/w should have a HR timer: $ ll /dev/hpet crw-rw 1 root audio 10, 228 2009-11-05 12:59 /dev/hpet you can specify the clock source to jackd: $ jackd --help ... [ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ] ... J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Emanuel Rumpf xb...@web.de Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 7:04 AM Emanuel Rumpf wrote: Hi I'm confused about all the timers. There is: - system timer - hpet (high precision event timer) - hr-timer (high resolution timer) - rtc (real time clock) - cyclic (what's that? a coded loop?) - anything else ? What is the relation of all these ? Which hardware devices are actually used by those ? Which is the prefered timer for sequencing ? hr-timer / rtc ? If hardware is fine with Linux real-time audio, if I understand correctly, the preferred timer for MIDI sequencers is (should be) system timer at ! 1000 Hz ! For my hardware, that has got problems with real-time audio, it's PCM playback and PCM capture. Using this timers MIDI jitter will decrease a little bit. This is the output I get for 64 Studio 3.0-beta3: spinymouse-s...@64studio:~$ cat /proc/asound/timers G0: system timer : 1000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE Client
Re: [LAD] timers
CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y Are defaults. You need: CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y It's inside one of the first few menus. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
yeah, I have added a few things in a startup script. Among other things, I have: chgrp audio /dev/hpet echo 1024 /proc/sys/dev/hpet/max-user-freq modprobe snd-hrtimer The modprobe may not be needed anymore as my kernel is using hr-timer by default. I wrote this script quite some time ago and forgot about it :) J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:52 AM James Warden wrote: Ralf, It depends how ALSA was compiled in the kernel. Here is my kernel config related to this matter: CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y J. There is another question I've got :S. spinymouse-s...@64studio:~$ ls -l /dev | grep hpet crw-rw 1 root root 10, 228 2009-11-07 13:38 hpet The group for hpet isn't audio, thus I guess a user won't be able to use it?! Oops, # CONFIG_SND_HRTIMER is not set, has this now become something I should post to the 64 Studio list? It's the default for the 64 Studio kernel. It's not a self build kernel. spinymouse-s...@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 | grep CONFIG_SND CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_HRTIMER is not set # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_SB_COMMON=m CONFIG_SND_SB16_DSP=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m CONFIG_SND_ALS300=m CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS5530=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_FM801_TEA575X=m CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_INTELHDMI=y CONFIG_SND_HDA_ELD=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_SPI=y CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SND_PCMCIA=y CONFIG_SND_VXPOCKET=m CONFIG_SND_PDAUDIOCF=m # CONFIG_SND_SOC is not set ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org
Re: [LAD] timers
yeps, forgot to copy this part of the config here, thanks :) J. --- On Sat, 11/7/09, Ray Rashif schivmeis...@gmail.com wrote: From: Ray Rashif schivmeis...@gmail.com Subject: Re: [LAD] timers To: Linux Audio Developers linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:53 AM CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y Are defaults. You need: CONFIG_HPET_TIMER=yCONFIG_HPET_EMULATE_RTC=yCONFIG_HPET=yCONFIG_HPET_MMAP=y It's inside one of the first few menus. -Inline Attachment Follows- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Thank you very much James and Ray :). Ralf James Warden wrote: yeah, I have added a few things in a startup script. Among other things, I have: chgrp audio /dev/hpet echo 1024 /proc/sys/dev/hpet/max-user-freq modprobe snd-hrtimer The modprobe may not be needed anymore as my kernel is using hr-timer by default. I wrote this script quite some time ago and forgot about it :) J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:52 AM James Warden wrote: Ralf, It depends how ALSA was compiled in the kernel. Here is my kernel config related to this matter: CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y J. There is another question I've got :S. spinymouse-s...@64studio:~$ ls -l /dev | grep hpet crw-rw 1 root root 10, 228 2009-11-07 13:38 hpet The group for hpet isn't audio, thus I guess a user won't be able to use it?! Oops, # CONFIG_SND_HRTIMER is not set, has this now become something I should post to the 64 Studio list? It's the default for the 64 Studio kernel. It's not a self build kernel. spinymouse-s...@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 | grep CONFIG_SND CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_HRTIMER is not set # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_SB_COMMON=m CONFIG_SND_SB16_DSP=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m CONFIG_SND_ALS300=m CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS5530=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_FM801_TEA575X=m CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_INTELHDMI=y CONFIG_SND_HDA_ELD=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_SPI=y CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y CONFIG_SND_USB_US122L=m CONFIG_SND_PCMCIA=y CONFIG_SND_VXPOCKET=m CONFIG_SND_PDAUDIOCF=m # CONFIG_SND_SOC is not set ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- Secret of Tux:
Re: [LAD] LV2 compliant tests
Hi dave, Thanks for your upload. I saw the thread on LAD mail archive but without code. Let's see what I can do with it. Regards, Sylvain - Original Message - From: David Robillard d...@drobilla.net To: linux-audio-dev@lists.linuxaudio.org Sent: Wednesday, November 04, 2009 5:41 PM Subject: Re: [LAD] LV2 compliant tests On Tue, 2009-11-03 at 09:32 +, Machel Sylvain wrote: Hi, I'm about to work on a LV2 wrapper for the FxEngine Framework and I would like to know if it exits compliant tests to validate LV2 plugin according to the port type, scope, ect . ? With the exeption of a few unitary tests, I didn't find anything on the web. Damon Chaplin posted one to the list based on his LADSPA test app a few months ago: http://linuxaudio.org/mailarchive/lad/2009/7/30/157338 I dug the attachment out of my mail archive and uploaded it here (unmodified but for an added By Damon Chaplin line): http://drobilla.net/files/test-lv2.c I don't know if it this is the most recent version, or if it lives on elsewhere on the 'net. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Help to choose an audio library for a project
On Sat, 2009-11-07 at 17:33 +0100, Ludovic RESLINGER wrote: Hello, I'm student in computer science and for one of my projects, I would like to program an audio player. The player will be developed for GNU/Linux environment but I would like to use an audio library which permit a portability for Windows and MacOS X too. The player will must read files in wav, MP3 and OGG/vorbis (at first) and it will have an equalizer. For file reading, libsndfile will handle everything except the mpeg formats (patent issues), which you can handle with libmad, for audio IO I would probably go with portaudio, and for the equaliser just grab the code from one of the SWH LADSPA pligins and extract what is needed. The audio part should take less then a day to write (Mostly copy and paste), the gui will (as usual) take somewhat longer. Regards, Dan. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On Fri, 2009-11-06 at 18:27 +0100, f...@kokkinizita.net wrote: On Fri, Nov 06, 2009 at 10:55:17AM -0500, David Robillard wrote: How could changing the rules about how anything references ports be done as an extension? By doing it the new way if the extension is requested, and the old way otherwise. This would not solve the problem because hosts need to follow the rules too. The core spec obviously has to specify things like how to refer to ports correctly. There are a small number of things that need to be defined in the core spec for obvious reasons, this is one of them. ... What extensions are in conflict? FUD FUD FUD Can you name two LAD members with the same birthday ? Probably not, but if you put 23 of them in a room the chances are 50% there will be two. At the moment there are few extensions, so probably there's no conflict. This presumes that extensions conflicting makes sense, or is likely to happen. Or depend on things that are specified nowhere, such as the order in which a host should use them and call any new extension specific functions in the plugin ? This doesn't really make any sense. Doesn't it ? If a host has to consider all active extensions as a whole then the number of possible combinations explodes. If it considers them one by one, doing what is required for extension A could easily have an impact on extension B Why? Says who? Example? , if both are about similer things, e.g. ports. For this reason a host author could decide to do first B then A, if that solves his problem. At the same time a plugin author could assume (even without been aware of this) that the order has to be A then B. I don't know what this order stuff means at all. Extensions don't have an order. What mechanism is there in LV2's core spec that ensures that extensions will be orthogonal to each other, even if written by authors who don't know each other's work, and evaluated by a host in unspecified order ? This also makes no sense. It might be possible to deliberately construct a really, really, really cracked out extension that would somehow be in conflict with another, but I can't even come up with such a case. I'd say the chance of this happening with extensions that aren't deliberately written to do this is extremely close to 0. Prove it. Extensions are usually either new port types, which can't conflict with anything, or newly added functions, which can't conflict with anything either. The only kind of extension that could conflict is what that redefines the semantics of something very fundamental in the core spec, which is silly, and again, even if such an extension existed, it doesn't matter, because that one particular weird extension might not make sense with such and such a host/plugins/extension/whatever. So? If it's fundamentally incapable of working in some setup, then it won't. You are making the outrageous claim, the burden of proof is on you. Even in this overwhelmingly unlikely case, if conflicting extensions existed it simply would not make sense to implement them both in a single plugin. The whole idea of a plugin system is that host and plugins can be developed separately. This requires that all parts of the API, *including their possible interactions and dependencies* are either well-defined, or guaranteed by design not to interfere with each other. Again, what interactions and dependencies? You're waving your hands around screaming about conflict with no example or argument to suggest such conflict is likely or even possible. Is isn't, and furthermore, if it did happen it's not a big dealer, and furtherfurthermore, the community would take care of this anyway (why would anyone do this without a good reason? and if they did, why would anyone implement it?) Here is an actual example of the sort of way extensions might conflict: Extension A says the block size passed to the process method must be always 1. Extension B says the block size passed to the process method must be always 512. These extensions conflict. So what? You can't do both on the same plugin, obviously. The things they describe inherently conflict. This is simply not a problem. If you think it is a problem, then come up with an example for why. I can't think of one. You not wanting to do stuff is certainly is not an argument against LV2. Having one potential plugin author less means a (small) impact on its acceptance. It's not a technical argument, that's true. Maybe, and everyone would like as many plugins as possible, but you don't have any concrete reasons. I'd love to address your concerns, but you don't have any actual concerns. One can not make a patch for FUD. Why should you even care if this conflicting thing is possible anyway? Will it affect your plugins? Obviously not, you couldn't implement conflicting extensions on a single set of plugins anyway, by definition. Should I
Re: [LAD] How to develop guis for LV2?
On Sat, 2009-11-07 at 13:41 +0100, Jörn Nettingsmeier wrote: Steve Harris wrote: On 5 Nov 2009, at 23:33, David Robillard wrote: On Thu, 2009-11-05 at 22:21 +0100, f...@kokkinizita.net wrote: On the LV2 website, Lars Luthman's UI extension is described as: This extension is written for revision 2 of the LV2 specification and is NOT compatible with revisions 3 and later. Do not implement this extension in new plugins or hosts, and do not expect it to work in old ones. It is only available here for archaeological purposes. For anyone genuinely interested and not just taking vain pot shots to further some weird personal vendetta or whatever the hell: The thing that changed in r3 is: persistent references to ports must refer to ports by their symbol, and not their index. Persistent means things on disk that might refer to several versions of a plugin in the future, nothing about the index has actually changed. Plugin data files, host session files, etc. This was a hangover from LADSPA, which had confusing and contradictory claims about what should/shouldn't be used to identify ports. I still don't think there's consensus there. can you elaborate on this? Labels are not useful as an identifier for LADSPA ports at all - there are plugins out there that use the same label for several ports, for example. Despite this there's code out there that attempts to use them as such. More generally there's been a lot of confusion and screw-up over identification of plugins. The spec says to use the ID, which is annoyingly centralized and limited. There are plugins in the wild with conflicting IDs. Many people suggested using the library name and plugin label as an identifier instead. Unfortunately this doesn't work, there are packages of the same plugins with different library names, or different distributions of plugins among libraries. I don't believe there is a single correct way to refer to a LADSPA plugin that actually works with all the plugins out there. Many people just have an extremely small number of plugins (e.g. 2 or 3 of the most popular big packages) and don't notice. The index vs. symbol thing with LV2 is more to do with dynamicism and versioning, though. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Another thing you can check: dmesg | grep -i hpet You'll see if your h/w supports it. You can read more at http://en.wikipedia.org/wiki/High_Precision_Event_Timer J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: James Warden warj...@yahoo.com Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:57 AM Thank you very much James and Ray :). Ralf James Warden wrote: yeah, I have added a few things in a startup script. Among other things, I have: chgrp audio /dev/hpet echo 1024 /proc/sys/dev/hpet/max-user-freq modprobe snd-hrtimer The modprobe may not be needed anymore as my kernel is using hr-timer by default. I wrote this script quite some time ago and forgot about it :) J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 8:52 AM James Warden wrote: Ralf, It depends how ALSA was compiled in the kernel. Here is my kernel config related to this matter: CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m # CONFIG_SND_MIXER_OSS is not set # CONFIG_SND_PCM_OSS is not set # CONFIG_SND_SEQUENCER_OSS is not set CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y J. There is another question I've got :S. spinymouse-s...@64studio:~$ ls -l /dev | grep hpet crw-rw 1 root root 10, 228 2009-11-07 13:38 hpet The group for hpet isn't audio, thus I guess a user won't be able to use it?! Oops, # CONFIG_SND_HRTIMER is not set, has this now become something I should post to the 64 Studio list? It's the default for the 64 Studio kernel. It's not a self build kernel. spinymouse-s...@64studio:~$ cat /boot/config-2.6.29-1-multimedia-amd64 | grep CONFIG_SND CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_HRTIMER is not set # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_SB_COMMON=m CONFIG_SND_SB16_DSP=m CONFIG_SND_PCI=y CONFIG_SND_AD1889=m CONFIG_SND_ALS300=m CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m # CONFIG_SND_AW2 is not set CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS5530=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_FM801_TEA575X=m CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_INTELHDMI=y CONFIG_SND_HDA_ELD=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SONICVIBES=m
Re: [LAD] timers
2009/11/7 James Warden warj...@yahoo.com: You can read more at http://en.wikipedia.org/wiki/High_Precision_Event_Timer Thanks for your interrest. I found some kernel docu: http://www.mjmwired.net/kernel/Documentation/timers/ And: http://lwn.net/Articles/167897/ Looks like HPET and RTC are hardware devices, where HPET is meant to be superior and replace the RTC. I still don't get: What is the HR-timer ? I mean how does it compare to the HPET ? When to decide for the HPET, when for the HRT api ? Does one if it depend on the other ? The kernel-devs seem to distinguish between high-resolution clock (=hpet ??) and HR-timer : We used the high-resolution clock subsystem ontop of hrtimers to verify 152 the hrtimer implementation details in praxis ... -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
2009/11/7 Jörn Nettingsmeier netti...@folkwang-hochschule.de: This was a hangover from LADSPA, which had confusing and contradictory claims about what should/shouldn't be used to identify ports. I still don't think there's consensus there. can you elaborate on this? archive links would be good, too. I think Steve may be thinking of the inflammatory subject of how you identify plugins, not ports. I'm pretty sure LADSPA ports are always by number. Chris ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
On Sat, Nov 7, 2009 at 2:51 PM, Emanuel Rumpf xb...@web.de wrote: Looks like HPET and RTC are hardware devices, where HPET is meant to be superior and replace the RTC. correct, to a large extent. I still don't get: What is the HR-timer ? I mean how does it compare to the HPET ? When to decide for the HPET, when for the HRT api ? Does one if it depend on the other ? Modern motherboads come with timers that are capable of massively higher precision than older ones, and allow for very precise scheduling of timer interrupts quite along time in advance of the timer going off. The existence of this kind of capability can be used to implement system scheduling in some moderately different ways. HR-Timer is the name given to some kernel patches (now in the mainstream kernel) that allowed the use of this timing hardware. The changes were a mix of new code that deals with the new capabilities, and patches that reimplement the existing system timer/scheduling design using the new hardware. So, HR-Timer (patches/code/design) requires a high res clock (like HPET). Note that one of the possible ways to use the HR Time infrastructure is to go totally tickless. In this design, the kernel is no longer woken at fixed, regular intervals as has been the case for the entire history of Linux. Instead, the kernel constantly adds new deadline times which, when expired, generate an interrupt. In the very, very unlikely case of there being only one process that is runnable, you can it without any timer deadlines at all (until some other process becomes runnable). Obviously, its rather complex, but also totally awesome stuff. This is separate from HR-Timer, but relies upon it, and it generally referred to as a tickless kernel. the HR-Timer infrastructure is a MUCH better basis for scheduling MIDI. Even with RTC=1 (10^4), you still don't have a clock that is running in sync with the nominal MIDI data rate. with HR-Timer in place, you can actually schedule the delivery of MIDI bytes precisely on time (wake me up in another 0.3msecs) and not rely on a metronomic tick like RTC. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On Sat, 7 Nov 2009, David Robillard wrote: A better analogy would be well-formed XML or RDF, where things can easily be added but it doesn't break anything because the technology has been designed specifically to handle this; or my shared library analogy from earlier. rant Except when you want your XHTML (1.1)+MathML (v3)+SVG (1.1)+CSS (Level 3)+XSLT (1.0)+Javascript content to work as expected in everyone's browser. It doesn't break in the sense that babies aren't dying... but it doesn't *work*, either. Manwhile the hapless user with IE6 is thinking, Why doesn't this stuff work?? It's just a web page! Microsoft's site looks fine... so it must be /them/. Hell, even if you stick to HTML 4.0 + CSS 1... you blinkstill/blink have to find workarounds for IE 6. /rant FWIW, I think XML is awesome... but this part grates on my nerves. I think LV2 looks awesome, too... but I can't get a grip on this... THE PROBLEM: I *want* to write a host that can load anyone's LV2 synth and FX... and it just works. I want to write synths and FX that will work in anyone's host.[5] Where do I start? Looking over the docs... it looks like a host has to support nearly every extension listed on the wiki[1] if I want to accomplish this. The more I dig in... and the more I read David's comments... the more that this appears to be the case. And if something gets added to the list, looks like I'll have to update my host to support it. I know of two synths, zyn[3] and linuxsampler[4]. Zyn requires rtmempool and wants dynparam. LinuxSampler wants hardRtCapable (whatever that is) and saverestore. I can't find mention of EventPort or MidiEvent in the RDF files -- but I'm sure those are necessary, too (since they're synths). Meanwhile, I know of one LV2 host for synths, zynjacku.[2] I have no idea which extensions it supports... except that I know it supports whatever zyn has (because it appears Nedko did them together). So, if I write a synth that requires URI Map -- I don't know if it will work with zynjacku without digging into source code or bugging Nedko about it. Then, Lars's tutorial appears to be using his own portgroups extension, as well as some kind of namespace extension, and I'm not sure if he's using Midi Port or Midi Event. I have no idea if his examples will work in zynjacku without compiling them and trying it. And this is before considering GUI extensions Looking at this, people say, This is good, but it's kind of a mess at the moment. Can we get some sort of 'canonical list of extensions' or /something/ stable for devs to work from? To which Dave replies, FUD! FUD! FUD! Such a list accomplishes nothing! Am I just missing it, or what? What's the solution to The Problem? Is there core infrastructure (critical extensions) still missing or something? I'm _really_ willing to help, but so far every idea that I've put forth has been shot down... and Dave *seems* to think that The Problem isn't a problem. Thanks, Gabriel [1] http://lv2plug.in/docs/index.php?title=Main_Page [2] http://home.gna.org/zynjacku/ [3] aka zynadd http://home.gna.org/zyn/ [4] Version 1.0 at least includes an LV2 version. [5] Yes, I know there's cases where you have something that is so application-specific that you can't always do this. I think it's really cool that LV2 is extensible so that you can work around it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On Sat, Nov 07, 2009 at 12:52:52PM -0500, David Robillard wrote: This wouldn't be an LV2 plugin at all. In spirit, no. But technically it would be a perfectly conforming plugin. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] timers
Ralph, As I said, this startup script is something I wrote a long time ago. The max-user-freq is for apps like video players, some polling frequency for improving the playback performance (smoother playback). The default used to be 64Hz. Increasing it to 1024 was making mplayer or xine much more performant. Actually, I will reboot my DAW when I have some spare time without this startup script (except for the /dev/hpet group permission) and see what the newer kernel sets as default. J. --- On Sat, 11/7/09, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: From: Ralf Mardorf ralf.mard...@alice-dsl.net Subject: Re: [LAD] timers To: Paul Davis p...@linuxaudiosystems.com, Emanuel Rumpf xb...@web.de, James Warden warj...@yahoo.com Cc: linux-audio-dev@lists.linuxaudio.org Date: Saturday, November 7, 2009, 4:40 PM Summarized: I guess my mobo supports hpet :). $ dmesg | grep -i hpet [ 0.00] ACPI: HPET 77EE89C0, 0038 (r1 ATI ASUSACPI 42302E31 AWRD 98) [ 0.00] ACPI: HPET id: 0x8200 base: 0xfed0 [ 0.000999] hpet clockevent registered [ 0.000999] HPET: 4 timers in total, 0 timers will be used for per-cpu timer [ 0.177117] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 [ 0.177123] hpet0: 4 comparators, 32-bit 14.318180 MHz counter [ 1.166497] rtc0: alarms up to one month, 242 bytes nvram, hpet irqs 1. The kernel has to support it too. 2. If the kernel-rt does support it, I need to add a startup script: chgrp audio /dev/hpet echo 1024 /proc/sys/dev/hpet/max-user-freq modprobe snd-hrtimer Here I don't understand what the value 1024, written to max-user-freq does mean ;). 3. I need to launch JACK2 with the option -c, e.g.: jackd -Rc h -dalsa -dhw:0 -r96000 -p512 -n2 -Xseq 4. The sequencer timing source needs to be set up to hpet or hrtimer too? rosegarden -v 1.7.3 and qtractor -v 0.4.3.1418 aren't able to do it? Or will the -c option for JACK2 replace a chosen timer for Qtractor or Rosegarden with hpet? --- With a Linux kernel, you need the newer rtc-cmos hardware clock device driver rather than the original rtc driver. (http://en.wikipedia.org/wiki/High_Precision_Event_Timer) I guess this is within the vanilla kernel source code?! Cheers, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On 11/08/2009 08:37 AM, Gabriel M. Beddingfield wrote: On Sat, 7 Nov 2009, David Robillard wrote: A better analogy would be well-formed XML or RDF, where things can easily be added but it doesn't break anything because the technology has been designed specifically to handle this; or my shared library analogy from earlier. rant Except when you want your XHTML (1.1)+MathML (v3)+SVG (1.1)+CSS (Level 3)+XSLT (1.0)+Javascript content to work as expected in everyone's browser. It doesn't break in the sense that babies aren't dying... but it doesn't *work*, either. Manwhile the hapless user with IE6 is thinking, Why doesn't this stuff work?? It's just a web page! Microsoft's site looks fine... so it must be /them/. Hell, even if you stick to HTML 4.0 + CSS 1... youblinkstill/blink have to find workarounds for IE 6. /rant FWIW, I think XML is awesome... but this part grates on my nerves. I think LV2 looks awesome, too... but I can't get a grip on this... THE PROBLEM: I *want* to write a host that can load anyone's LV2 synth and FX... and it just works. I want to write synths and FX that will work in anyone's host.[5] Where do I start? Would a set of reference template code written for the various languages that we have at our disposal be of any use here? I again ask for submissions. Even if we just have one template that we can agree on it won't be that much effort to port it across to the other languages that we would like to have supporting LV2. that will make things that much clearer for developers across the board. The standard in the closed source world is to provide a package with the example code in place add some descriptive comments and a web accessible howto and we are good to go. Looking over the docs... it looks like a host has to support nearly every extension listed on the wiki[1] if I want to accomplish this. The more I dig in... and the more I read David's comments... the more that this appears to be the case. And if something gets added to the list, looks like I'll have to update my host to support it. I know of two synths, zyn[3] and linuxsampler[4]. Zyn requires rtmempool and wants dynparam. LinuxSampler wants hardRtCapable (whatever that is) and saverestore. I can't find mention of EventPort or MidiEvent in the RDF files -- but I'm sure those are necessary, too (since they're synths). Meanwhile, I know of one LV2 host for synths, zynjacku.[2] I have no idea which extensions it supports... except that I know it supports whatever zyn has (because it appears Nedko did them together). So, if I write a synth that requires URI Map -- I don't know if it will work with zynjacku without digging into source code or bugging Nedko about it. Then, Lars's tutorial appears to be using his own portgroups extension, as well as some kind of namespace extension, and I'm not sure if he's using Midi Port or Midi Event. I have no idea if his examples will work in zynjacku without compiling them and trying it. It's clear that we need to better define the plugin publishing and dependency system for LV2? We need a more transparent way of referencing an extension/plugin by to it's dependencies. And this is before considering GUI extensions Looking at this, people say, This is good, but it's kind of a mess at the moment. Can we get some sort of 'canonical list of extensions' or /something/ stable for devs to work from? To which Dave replies, FUD! FUD! FUD! Such a list accomplishes nothing! Am I just missing it, or what? What's the solution to The Problem? Is there core infrastructure (critical extensions) still missing or something? I'm _really_ willing to help, but so far every idea that I've put forth has been shot down... and Dave *seems* to think that The Problem isn't a problem. Thanks, Gabriel [1] http://lv2plug.in/docs/index.php?title=Main_Page [2] http://home.gna.org/zynjacku/ [3] aka zynadd http://home.gna.org/zyn/ [4] Version 1.0 at least includes an LV2 version. [5] Yes, I know there's cases where you have something that is so application-specific that you can't always do this. I think it's really cool that LV2 is extensible so that you can work around it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On Sun, 8 Nov 2009, Patrick Shirkey wrote: Would a set of reference template code written for the various languages that we have at our disposal be of any use here? I don't think so. ATM, there's plenty of high-quality reference code... especially with Lars's tutorial. This is a different issue. It's clear that we need to better define the plugin publishing and dependency system for LV2? Not quite (though that would be a Good Thing). More like a standard that says something like.. FOR SYNTH HOSTS: If you follow these guidelines, you may call yourself an LV2 Synth Host and you will be able to work cleanly with every synth that calls itself an LV2 Synth Plugin. + Support (at least) extensions A, B, and C. + The synths will have several MIDI input ports (for note data) and several audio output ports. + All configuration will be done with the events extension. + All feedback will be done with the events extension. + The plugins may provide a GUI interface. Its width will be 200, 400, 600, or 800 pixels. Its height will be a multiple of 100 pixels. FOR SYNTH PLUGINS: -- If you follow these guidelines, you may call yourself an LV2 Synth Plugin and you will be able to work cleanly with every host that calls itself an LV2 Synth Host. + Freely use extensions A, B, and C. If you use any extra LV2 extensions, try to make them optional. Otherwise, please simply call yourself an LV2 Plugin, because you won't work with every LV2 Synth Host. + Provide several MIDI in-ports for note data, and several audio out-ports. + All configuration will be done with the events extension. (This does not prohibit you from also doing the same over MIDI) + All feedback will be done with the events extension. + You are encouraged to create a GUI for your plugin. Its width shall be 200, 400, 600, or 800 pixels. Its height shall be a multiple of 100 pixels. Would somthing like this be *so* bad? There's still room for innovation. There's still room for plugin authors and host authors to get together and say, We all want to start supporting extension D. And that would still be cool because all the old plugins will still work. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
On 11/08/2009 03:31 PM, Gabriel M. Beddingfield wrote: On Sun, 8 Nov 2009, Patrick Shirkey wrote: Would a set of reference template code written for the various languages that we have at our disposal be of any use here? I don't think so. ATM, there's plenty of high-quality reference code... especially with Lars's tutorial. This is a different issue. Is it just me that feels that the existing examples are too obscure and set the entry level too high for the average developer as well as miss out important use cases specific to different languages? On another tangent is LV2 supposed to be a new standard and therefore provide an accessible documentation codebase for all potential users or is LV2 designed as a theoretical system which only advanced developers are given insight into and the rest have to fend for themselves. It's clear that we need to better define the plugin publishing and dependency system for LV2? Not quite (though that would be a Good Thing). What you have written below could also be considered a definition of a set of rules for publishing and specifying dependencies. However it doesn't completely address the dependency issue. Even if this standard was followed how would we define the categories such as LV2 Synth Plugin? Is that something that would be handled as someone else has suggested on a yearly basis by a committee? More like a standard that says something like.. FOR SYNTH HOSTS: If you follow these guidelines, you may call yourself an LV2 Synth Host and you will be able to work cleanly with every synth that calls itself an LV2 Synth Plugin. + Support (at least) extensions A, B, and C. + The synths will have several MIDI input ports (for note data) and several audio output ports. + All configuration will be done with the events extension. + All feedback will be done with the events extension. + The plugins may provide a GUI interface. Its width will be 200, 400, 600, or 800 pixels. Its height will be a multiple of 100 pixels. FOR SYNTH PLUGINS: -- If you follow these guidelines, you may call yourself an LV2 Synth Plugin and you will be able to work cleanly with every host that calls itself an LV2 Synth Host. + Freely use extensions A, B, and C. If you use any extra LV2 extensions, try to make them optional. Otherwise, please simply call yourself an LV2 Plugin, because you won't work with every LV2 Synth Host. + Provide several MIDI in-ports for note data, and several audio out-ports. + All configuration will be done with the events extension. (This does not prohibit you from also doing the same over MIDI) + All feedback will be done with the events extension. + You are encouraged to create a GUI for your plugin. Its width shall be 200, 400, 600, or 800 pixels. Its height shall be a multiple of 100 pixels. Would somthing like this be *so* bad? There's still room for innovation. There's still room for plugin authors and host authors to get together and say, We all want to start supporting extension D. And that would still be cool because all the old plugins will still work. -gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] How to develop guis for LV2?
insert obligatory GMPI joke here -dr GMPI is quietly and successfully in use as the new native plugin format of SynthEdit. I've so far written 70 plugins with it, and others are writing more. SynthEdit's previous plugin format has about 1000 plugins available, hopefully also will be ported to GMPI (aka SEM V3)... so GMPI can't really be called vaporware any more. Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
