Re: [Rosegarden-user] Transport problem

2023-02-20 Thread Will Godfrey
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

2023-02-20 Thread Ted Felix
  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

2023-02-20 Thread Ted Felix
  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 

Re: [Rosegarden-user] Transport problem

2023-02-20 Thread Ted Felix
  /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



___

Re: [Rosegarden-user] Transport problem

2023-02-20 Thread Will Godfrey


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] Transport problem

2023-02-19 Thread chuck elliot

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



___
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

2023-02-19 Thread Ted Felix
  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



___
Rosegarden-user mailing list
Rosegarden-user@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user



___
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

2023-02-19 Thread Ted Felix

  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



___
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

2023-02-19 Thread Patrick May
Hello,

> the
ALSA documentation is incomplete and in many cases incorrect

Do you happen to remember off hand which parts are incorrect? I think we
should report them to the ALSA project.

- PM

On Sun, 19 Feb 2023, 13:53 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
>
___
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

2023-02-19 Thread Ted Felix
  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