Re: [Rosegarden-user] Transport problem
The results:
music@devuan:~$ uname -a
Linux devuan 6.1.0-3-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.8-1 (2023-01-29)
x86_64 GNU/Linux
music@devuan:~$ grep -i preempt_voluntary /boot/config-$(uname -r)
# CONFIG_PREEMPT_VOLUNTARY is not set
music@devuan:~$ grep -i preempt_dynamic /boot/config-$(uname -r)
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
music@devuan:~$ grep -i preempt /etc/default/grub
music@devuan:~$
I see exactly the same on the Intel machine.
Everything software-wise is identical as far as I can tell.
I'm rather thinking now that Rosegarden may be an innocent victim of something
going right back to the machine firmware, although I don't have anything else
ALSA based as a double-check. Things like qtractor take their timing from the
audio backend.
The situation isn't fatal, as the non-preempt kernel seems to behave perfectly.
On Mon, 20 Feb 2023 05:20:50 -0500
Ted Felix wrote:
> Thanks, Will. Here's a slightly newer set of steps based on what
>I've learned this morning...
>
>
>Boot into your real-time kernel.
>
>Confirm that it is a preemptible kernel.
>
> $ grep -i config_preempt= /boot/config-$(uname -r)
> CONFIG_PREEMPT=y
>
>If you don't see "CONFIG_PREEMPT=y" then you need to install a
>preemptible kernel.
>
>Check for voluntary preemption. Ideally this should be "y". However,
>I've had no problems with it "not set", so "y" might be the default.
>Some more digging into the kernel code is in order here.
>
> $ grep -i preempt_voluntary /boot/config-$(uname -r)
> # CONFIG_PREEMPT_VOLUNTARY is not set
>
>Check for dynamic preemption. This allows the preemption mode to be
>specified on the kernel command line.
>
> $ grep -i preempt_dynamic /boot/config-$(uname -r)
> CONFIG_PREEMPT_DYNAMIC=y
> CONFIG_HAVE_PREEMPT_DYNAMIC=y
>
>If both of those are set to "y", then we need to check the grub
>configuration to make sure the kernel command line is asking for full
>preemption (or nothing at all).
>
> $ grep -i preempt /etc/default/grub
>
>You should either see nothing or "preempt=full" along with possibly
>other options. Anything else might mean trouble and requires a change
>to your grub config.
>
>
>Ted.
>
>On 2/20/23 4:10 AM, Will Godfrey wrote:
>>
>> I'll try this today.
>>
>> On Sun, 19 Feb 2023 12:19:53 -0500
>> Ted Felix wrote:
>>
>>>Will, can you go through this first draft series of steps on the
>>> problematic box and let me know if it finds the issue? Thanks.
>>>
>>> Boot into the problematic kernel.
>>>
>>> Confirm that it is a preemptible kernel.
>>>
>>> $ grep -i config_preempt= /boot/config-$(uname -r)
>>> CONFIG_PREEMPT=y
>>>
>>> If you don't see "CONFIG_PREEMPT=y" then you need to install a
>>> preemptible kernel.
>>>
>>> Check the grub configuration to make sure nothing is specified on the
>>> kernel command line related to preemption.
>>>
>>> $ grep -i preempt /etc/default/grub
>>>
>>> You should either see nothing or "preempt=full" along with possibly
>>> other options. Anything else might mean trouble and requires a change
>>> to your grub config.
>>>
>>> Check for voluntary preemption. (Not sure how this fits into
>>> everything, but it might cause problems and need some further
>>> investigation.)
>>>
>>> $ grep -i preempt_voluntary /boot/config-$(uname -r)
>>> # CONFIG_PREEMPT_VOLUNTARY is not set
>>>
>>> Ted.
>>
>
>
>___
>Rosegarden-user mailing list
>Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
>https://lists.sourceforge.net/lists/listinfo/rosegarden-user
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
Thanks, Will. Here's a slightly newer set of steps based on what I've learned this morning... Boot into your real-time kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check for voluntary preemption. Ideally this should be "y". However, I've had no problems with it "not set", so "y" might be the default. Some more digging into the kernel code is in order here. $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Check for dynamic preemption. This allows the preemption mode to be specified on the kernel command line. $ grep -i preempt_dynamic /boot/config-$(uname -r) CONFIG_PREEMPT_DYNAMIC=y CONFIG_HAVE_PREEMPT_DYNAMIC=y If both of those are set to "y", then we need to check the grub configuration to make sure the kernel command line is asking for full preemption (or nothing at all). $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Ted. On 2/20/23 4:10 AM, Will Godfrey wrote: I'll try this today. On Sun, 19 Feb 2023 12:19:53 -0500 Ted Felix wrote: Will, can you go through this first draft series of steps on the problematic box and let me know if it finds the issue? Thanks. Boot into the problematic kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check the grub configuration to make sure nothing is specified on the kernel command line related to preemption. $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Check for voluntary preemption. (Not sure how this fits into everything, but it might cause problems and need some further investigation.) $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Ted. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Transport problem
Kernel in a Nutshell answers my question about preempt voluntary in chapter 11: -- PREEMPT_VOLUNTARY Voluntary kernel preemption (desktop) This option reduces the latency of the kernel by adding more “explicit preemption points” to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, which provides faster response to applications at the cost of slightly lower throughput. This option speeds up reaction to interactive events by allowing a low-priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to appear to run more smoothly even when the system is under load. Select this if you are building a kernel for a desktop system. -- -- http://www.kroah.com/lkn/ So, for audio we want voluntary "y". I have it "not set" in my kernel from Ubuntu. But I've had no problems. No idea what the default is for an otherwise preemptible kernel. Ted. On 2/19/23 12:19 PM, Ted Felix wrote: Will, can you go through this first draft series of steps on the problematic box and let me know if it finds the issue? Thanks. Boot into the problematic kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check the grub configuration to make sure nothing is specified on the kernel command line related to preemption. $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Check for voluntary preemption. (Not sure how this fits into everything, but it might cause problems and need some further investigation.) $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Ted. On 2/19/23 11:48 AM, Ted Felix wrote: On second thought... We've been here before. From my Linux MIDI Guide: Note: There are variations on PREEMPT that are less than ideal. "DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the kernel command line options (preempt=full). You'll need to check your GRUB configuration to make sure this is either set to "preempt=full" or not set at all (the default is "full") in "GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY which is somewhere between "NONE" and "PREEMPT". You'll want to avoid this as audio requires the best possible real-time performance. I should probably make that a bit more prominent now that we are running into it for real. Like move it up to the "things you'll need" section at the very top. Ted. On 2/19/23 8:52 AM, Ted Felix wrote: We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performanc
Re: [Rosegarden-user] Transport problem
/etc/default/grub either needs to *not* mention preempt (default is full) or have preempt=full. If you aren't experiencing any timing glitches then you should be ok. Ted. On 2/19/23 8:53 PM, chuck elliot wrote: I haven't noticed any problems but the current standard kernel in Fedora 36 has: CONFIG_PREEMPT_DYNAMIC=y CONFIG_PREEMPT_VOLUNTARY=y in /boot/config-$(uname -r) does this need to be overridden in /etc/default/grub or in a kernel rebuild ? On 19/02/2023 5:19 pm, Ted Felix wrote: Will, can you go through this first draft series of steps on the problematic box and let me know if it finds the issue? Thanks. Boot into the problematic kernel. Confirm that it is a preemptible kernel. $ grep -i config_preempt= /boot/config-$(uname -r) CONFIG_PREEMPT=y If you don't see "CONFIG_PREEMPT=y" then you need to install a preemptible kernel. Check the grub configuration to make sure nothing is specified on the kernel command line related to preemption. $ grep -i preempt /etc/default/grub You should either see nothing or "preempt=full" along with possibly other options. Anything else might mean trouble and requires a change to your grub config. Check for voluntary preemption. (Not sure how this fits into everything, but it might cause problems and need some further investigation.) $ grep -i preempt_voluntary /boot/config-$(uname -r) # CONFIG_PREEMPT_VOLUNTARY is not set Ted. On 2/19/23 11:48 AM, Ted Felix wrote: On second thought... We've been here before. From my Linux MIDI Guide: Note: There are variations on PREEMPT that are less than ideal. "DYNAMIC_PREEMPT" allows PREEMPT to be turned on and off in the kernel command line options (preempt=full). You'll need to check your GRUB configuration to make sure this is either set to "preempt=full" or not set at all (the default is "full") in "GRUB_CMDLINE_LINUX_DEFAULT=". You can check the setting after boot with "sudo dmesg | grep preempt". There is also PREEMPT_VOLUNTARY which is somewhere between "NONE" and "PREEMPT". You'll want to avoid this as audio requires the best possible real-time performance. I should probably make that a bit more prominent now that we are running into it for real. Like move it up to the "things you'll need" section at the very top. Ted. On 2/19/23 8:52 AM, Ted Felix wrote: We rely completely on ALSA for timer stuff. The key routine for setting the timer in RG is: AlsaDriver::setCurrentTimer() Unless there is a bug in there (which there may very well be, the ALSA documentation is incomplete and in many cases incorrect), the problems tend to be due to bugs in ALSA or the kernel. They usually get sorted over time by the ALSA folks. If they notice them. This one seems like an interesting combination of requirements to reproduce and thus might fly under their radar. I recommend building the latest kernel and seeing if that fixes the issue. My three-year-old Debian/Ubuntu oriented notes are here if you need: http://www.tedfelix.com/linux/kernel-build.html In general, it's really easy to do. If it's still there, a bug report for the ALSA folks seems like the way to go. They can help find the issue in ALSA, or even in Rosegarden if that's where the problem is. Ted. On 2/11/23 4:42 AM, Will Godfrey wrote: Recently I found Rosegarden was losing the timer source, and the transport was freezing - sometimes for nearly a second after which it would send a bunch of notes, then carry on as normal. It was some time before I realised it only happened on my Ryzen 5 machine (the one I use for music) and not on my office Intel one. I hadn't made any changes to the system and got sidetracked into thinking maybe I'd somehow managed to get infected with some malware. However I eventually remembered I'd done a normal devuan update. The only significant change was the Linux kernel V5.10 to V 6.1. Rolling that back cured the problem. Asking some questions on-line identified the problem. First off, I use the RT-Preemt kernel - the 'normal' one doesn't have the issue at all. Secondly, the Ryzen has the AMD equivalent of hyper-threading, my older Intel doesn't. Finally, since Linux V5.12 the scheduler has been modified to allow dynamic preemption. Disabling this in the BIOS cures the problem, albeit with a very small loss of performance. I wonder if there should be another look at how Rosegarden does it's timing. I did try to set the timing source to the audio hardware. It seemed to recognise it, but actually totally ignored it. Saving and reloading showed no time source at all, yet still ran as if it was on System Timer. ___ Rosegarden-user mailing list Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-user ___ Rosegarde
Re: [Rosegarden-user] Transport problem
I'll try this today.
On Sun, 19 Feb 2023 12:19:53 -0500
Ted Felix wrote:
> Will, can you go through this first draft series of steps on the
>problematic box and let me know if it finds the issue? Thanks.
>
>Boot into the problematic kernel.
>
>Confirm that it is a preemptible kernel.
>
> $ grep -i config_preempt= /boot/config-$(uname -r)
> CONFIG_PREEMPT=y
>
>If you don't see "CONFIG_PREEMPT=y" then you need to install a
>preemptible kernel.
>
>Check the grub configuration to make sure nothing is specified on the
>kernel command line related to preemption.
>
> $ grep -i preempt /etc/default/grub
>
>You should either see nothing or "preempt=full" along with possibly
>other options. Anything else might mean trouble and requires a change
>to your grub config.
>
>Check for voluntary preemption. (Not sure how this fits into
>everything, but it might cause problems and need some further
>investigation.)
>
> $ grep -i preempt_voluntary /boot/config-$(uname -r)
> # CONFIG_PREEMPT_VOLUNTARY is not set
>
>Ted.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
Re: [Rosegarden-user] Any plans to support LV2 plug-ins?
On Sun, 19 Feb 2023 20:19:15 -1000
david wrote:
>Well, I've made a couple of attempts to use Ardour. It's a very powerful
>tool of audio engineers.
>
>For someone more ordinary, like me, who doesn't do much with recorded
>audio, it's way beyond me.
>
>Rosegarden does the MIDI and scoring I need. For a final, complete,
>beautiful score, I use MuseScore.
>
>On 2/19/23 20:06, Mike Broughton wrote:
>> Not to steal a thread, but rather than rosegarden supporting all these
>> formats, have you considered rosegarden becoming a plugin so that you
>> can use it in say, ardour.
>>
>> Keep rosegarden a special notation piece, and let others worry about
>> the extra fluff.
>>
>> Sorry if this has been considered before.
>>
>> Mike
>>
>> On 18 Feb 2023 11:06, Lorenzo Sutton wrote:
>>
>> On 18/02/2023 04:57, david wrote:
>> > I was wondering about that. With RG already supporting ALSA
>> MIDI, what's
>> > the showstopper with similarly supporting JACK MIDI?
>>
>> Actually, I feel that the uncertainty Pipewire it bringing to the
>> Linux
>> Pro Audio world (see discussions on LAD for example), and the risk
>> JACK
>> is in the longer term, I feel link bumping up LV2 support in
>> Rosegarden.
>>
>> Then JACK MIDI as Carla for example only supports JACK MIDI.
>>
>> Unfortunately it seems that the modular approach of 'an app does
>> something well' philosophy is at risk if JACK is at risk...
>>
>> Just a quick guts feeling here, and I totally understand the kind of
>> endeavor LV2 would be...
>> In an ideal world I'd be happy for Rosegarden to do 'just' MIDI
>> (maybe
>> JACK Midi), and then have external software do the plugins. I've
>> written
>> a lot about e.g. rendering with jack freewheel etc. but I think the
>> trend now is to go on Linux to the one-DAW-does-it-all probably
>> because
>> of commercial software like Bitwig or Reaper now available for
>> Linux and
>> having that approach and Ardour trying to follow on that (albeit IMHO
>> still lacking to much in the MIDI department).
>>
>> Enough rambling there, just my 2 cents :-)
>> Lorenzo
>>
>> >
>> > Let us continue to ignore those that might pipe up, "Why support
>> either
>> > of those when you could just support Pipewire instead?" ;)
>> >
>> > On 2/17/23 17:38, Ted Felix wrote:
>> >> No plans. I would love to do it, though. Along with JACK MIDI.
>> >> Need to find some more time.
>> >>
>> >> Ted.
>> >>
>> >> On 2/17/23 10:05 PM, david wrote:
>> >>> Inspired by a question from Paul Davus on the
>> Linux-Users-Audio list,
>> >>> when he replied to my request that Yoshimi add DSSI support:
>> "Why do
>> >>> you want DSSI instead of LV2?"
>> >>>
>> >>> I replied that Rosegarden doesn't support LV2.
>> >>>
>> >>> I see this feature request:
>> >>>
>> >>> https://sourceforge.net/p/rosegarden/feature-requests/462/
>> >>>
>> >>> The last item on that list quotes someone else saying:
>> >>>
>> Rosegarden does not need native LV2. Carla should have all the
>> plugin support needed for a project. We don't need several
>> programs
>> all doing the same thing.
>> >>> Only issue with that for me is, I went to my Debian 11
>> repository -
>> >>> and Carla isn't there. It's not available in Debian.
>> Apparently only
>> >>> through KXStudio repository?
>> >>>
>> >>> I would still prefer RG having LV2 support built-in, instead of
>> >>> having to install yet another program.
>> >>>
>> >>> Ideas?
>> >
>>
>
I would add that Yoshimi in Ardour *at least* doubles the CPU load compared
with Yoshimi with Rosegarden.
Ardour is an audio processor with some MIDI facilities added on.
Rosegarden is a MIDI processor with some audio facilities added on.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user
