Thank you!
I will look into that.
I have 'fumbled around' «.asoundrc» quite a bit earlier, and I have absolutely not comprehended it all.

Thanks,
Olav

PS
Browser are but one thing, I need to reassure the functionality as a whole

Thanks for answering.
I think I understood, hence the search wasn't exactly too sublime.

I'm trying too have browsers use JACK as sound-server, this, using alsa_out, was one approach I was exploring.

I had a look at the thread mentioned above, and it is now marked as solved. Couple of new threads which i didn't really read through, but if you're still at it it may be worthwhile.

Cheers,
Olav

Hello

Maybe worth a try perhaps: https://www.nvidia.com/Download/Find.aspx?lang=en-uk, downgrade driver version?

Olav

PS
What desktop environment are you on by the way?

Audio-wise there is nothing PulseAudio or PipeWire can do which ALSA can't, they totally depend on it; the potentiality of PA and PW are limited by ALSA's.

PA and PW act as sound-servers and wish to route every audio instance through (whichever chosen) them (including OSSs btw), so to have a uniformed interface/framework for users as well as APIs for programmers' software to interact with. Dealing (users) with multiple audio-devices, concurrent I/O audio events, various and different audio libraries simultaneously, various frequencies ... and so on; this is not always easy when interacting 'directly' with ALSA as it may involve creating and/or editing configuration files which may end up very complex, say ~,asoundrc; PA (I guess) was an effort to address this moving forwards towards user-friendliness and, as mentioned, consistency.

For me ALSA without any intermediate layer works well; however, as things has evolved, more and more software are written expecting a sound-server dealing with the various applications' audio-instances in mind, hence decrease in support for ALSA 'only'. APulse seems to work alright though(?).

As I used to work on and with DAWs, for me, therefore! , PA (and probably PW which I don't know) is just a bloody potter about interfering (JACK) and drawing resources from the system. I ditched PA early on so I should be a bit humble with regard the present status (all though not quite), but however you look at it, it basically is a layer which provides no extra potential, just an easier configuration and management path.

Olav

I have now achieved what I wanted to do, i.e. I can change between languages within the individual GTK package; just to mention, I tested languages which weren't enabled on the system, en_GB and nn_NO are the system languages, and they worked as well.

olav@DDAmt:~$ gsettings set org.gnome.system.locale region en_GB.UTF-8

I find this very strange but setting a specific language code with the command above changed everything. The «org.gnome.system.locale» string used to be empty, as shown in an earlier post, setting it to en.GB, or any language-code other than empty I presume, just made it possible to swap between them. Furthermore, even though I had set en_GB as default language (system-wide and KDE locales), after a re-login GIMP started using the nn_NO.

I'll stop now, too much speculations and I haven't got the energy nor the capacity probably to dig deeper to find the, obvious, logic behind this behaviour.

One thing I'm quite sure of though is that the output of «gsettings get org.gnome.system.locale region» command can't show an empty string, for whatever reason, if it does you, or at least I wasn't (on two different computers in fact), won't be able to change the locale setting for GTK apps in accordance with your preference in KDE nor swap between translations from within the individual applications, GIMP and Inkscape tested in this case.

Some premises seeing the above to be (fairly)valid:
- Devuan Beowulf
- KDE
- everything up to date
- no repositories other than the official ones (apart from some application specific repoes which should not interfere with the system in any way)

Thanks for your help Head_on_a Stick!
(you have my vote if you wish to have it back on your shoulders)

Olav

Okay

OK, I'll try to remember that.

And thanks so far!

It says nothing in fact

olav@DDAmt:~$ gsettings get org.gnome.system.locale region
''

I have two locales enabled: en_GB and nn_NO, in that priority order.

[color=green]olav@DDAmt:~$ locale -a[/color]
C
C.UTF-8
en_GB.utf8
nn_NO.utf8
POSIX
[color=green]olav@DDAmt:~$ echo $LANG[/color]
nn_NO.UTF-8
[/quote]
As you may see, the latter command shows just Norwegian (nynorsk) as available.

If I disable nn_NO (dpkg-reconfigure locales), some of the «LC_ ...» parameters will state «not available» (those not set specifically as appropriate from a Norwegian and personal point of view: monetary, numeric, time etc.).
[quote][color=green]olav@DDAmt:~$ locale[/color]
LANG=nn_NO.UTF-8
LANGUAGE=en_GB:nn
LC_CTYPE="nn_NO.UTF-8"
LC_NUMERIC="nn_NO.UTF-8"
LC_TIME="nn_NO.UTF-8"
LC_COLLATE="nn_NO.UTF-8"
LC_MONETARY="nn_NO.UTF-8"
LC_MESSAGES="nn_NO.UTF-8"
LC_PAPER="nn_NO.UTF-8"
LC_NAME="nn_NO.UTF-8"
LC_ADDRESS="nn_NO.UTF-8"
LC_TELEPHONE="nn_NO.UTF-8"
LC_MEASUREMENT="nn_NO.UTF-8"
LC_IDENTIFICATION="nn_NO.UTF-8"
LC_ALL=
[color=green]olav@DDAmt:~$ locale[/color]
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=nn_NO.UTF-8
LANGUAGE=en_GB:nn
LC_CTYPE="nn_NO.UTF-8"
LC_NUMERIC="nn_NO.UTF-8"
LC_TIME="nn_NO.UTF-8"
LC_COLLATE="nn_NO.UTF-8"
LC_MONETARY="nn_NO.UTF-8"
LC_MESSAGES="nn_NO.UTF-8"
LC_PAPER="nn_NO.UTF-8"
LC_NAME="nn_NO.UTF-8"
LC_ADDRESS="nn_NO.UTF-8"
LC_TELEPHONE="nn_NO.UTF-8"
LC_MEASUREMENT="nn_NO.UTF-8"
LC_IDENTIFICATION="nn_NO.UTF-8"
LC_ALL=

As I see it, this has to be some locale settings stuck from before a dist-upgrade/reinstall.