AV Linux... continue with Openbox, or not?
Re: AV Linux... continue with Openbox, or not?
so here's what I did in a nutshell.... in the end, these procedures completely messed up JACK and it failed to connect to server. Removing Openbox is a nightmare for a newbie.
I fail to understand how a windows manager can have any effect on the AVlinux JACK setup. It doesn't make sense, unless the user's home directory houses some important configuration files and they got obliterated somehow.
use synaptic package manager to remove Openbox and all dependencies
use startup session manager to uncheck all references to starting Openbox
go into session manager and remove all cached sessions
reinstall XCFE desktop environment
sudo apt --reinstall install qt5-style-plugins
echo "export QT_QPA_PLATFORMTHEME=gtk2" >> ~/.profile
go into keyboard settings and restore shortcuts to default in order to make logout button work again.
go into mxtweak and reset panel to default panel to bring back the default panel look
sudo apt-get --reinstall install xfwm4
I fail to understand how a windows manager can have any effect on the AVlinux JACK setup. It doesn't make sense, unless the user's home directory houses some important configuration files and they got obliterated somehow.
use synaptic package manager to remove Openbox and all dependencies
use startup session manager to uncheck all references to starting Openbox
go into session manager and remove all cached sessions
reinstall XCFE desktop environment
sudo apt --reinstall install qt5-style-plugins
echo "export QT_QPA_PLATFORMTHEME=gtk2" >> ~/.profile
go into keyboard settings and restore shortcuts to default in order to make logout button work again.
go into mxtweak and reset panel to default panel to bring back the default panel look
sudo apt-get --reinstall install xfwm4
Re: AV Linux... continue with Openbox, or not?
Well,
I truly understand what you're saying.. but on the other hand would you install an integrated Studio OS on another platform and just start ripping out fundamental system parts? Yes, we have freedom of choices in Linux and yes things are usually pretty modular and things can be uniquely combined and interchanged however something like AV Linux is designed to be more integrated for a focused purpose and I've designed things to work together as smoothly as possible and this often means more scripting and hidden features and other 'glue' that may not be there on a generic Linux Desktop system. I don't think substituting a Window Manager is something to be taken on lightly especially if you are new to Linux. If everything else works as it should is the framing around the Windows that dire of a concern?
All that said this thread is basically an acknowledgement of some of your points... in these modern times and with the amount of Users that AV Linux has gained Openbox for all it's longevity, lightness and utility was probably a misstep on my part and I'm working on fixing it properly.
I have absolutely no idea why your JACK setup isn't working and it shares no direct dependencies with Openbox but perhaps the rip fest targeted some other mortar and glue or got tangled up with other AV Linux utility packaging. For JACK and related applications to work properly you should have these installed:
You also need a custom non-Repo package especially for AV Linux found here:
http://bandshed.net/packages/AV_LINUX_M ... -1_all.deb
To get things working I strongly suggest reading the Menu-->Accessories-->AVL-MXE User Manual section on Audio and MIDI on Page 51 to see how it all works together..
I truly understand what you're saying.. but on the other hand would you install an integrated Studio OS on another platform and just start ripping out fundamental system parts? Yes, we have freedom of choices in Linux and yes things are usually pretty modular and things can be uniquely combined and interchanged however something like AV Linux is designed to be more integrated for a focused purpose and I've designed things to work together as smoothly as possible and this often means more scripting and hidden features and other 'glue' that may not be there on a generic Linux Desktop system. I don't think substituting a Window Manager is something to be taken on lightly especially if you are new to Linux. If everything else works as it should is the framing around the Windows that dire of a concern?
All that said this thread is basically an acknowledgement of some of your points... in these modern times and with the amount of Users that AV Linux has gained Openbox for all it's longevity, lightness and utility was probably a misstep on my part and I'm working on fixing it properly.
I have absolutely no idea why your JACK setup isn't working and it shares no direct dependencies with Openbox but perhaps the rip fest targeted some other mortar and glue or got tangled up with other AV Linux utility packaging. For JACK and related applications to work properly you should have these installed:
You also need a custom non-Repo package especially for AV Linux found here:
http://bandshed.net/packages/AV_LINUX_M ... -1_all.deb
To get things working I strongly suggest reading the Menu-->Accessories-->AVL-MXE User Manual section on Audio and MIDI on Page 51 to see how it all works together..
You do not have the required permissions to view the files attached to this post.
Re: AV Linux... continue with Openbox, or not?
Hey @AVLinux I am now on MX Linux XFCE, now I know why you chose it as a base...well, I would like to set it up as AVL MXE, any directions?
do I compulsorily need Liquorix Kernel? And why did you choose Liquorix over Xanmod?
For the life of me, I have not been able to set up qjackctl with pajackconnect, can you help? I had to enable jackd bus when I wanted to make use of qjackctl yesterday
Re: AV Linux... continue with Openbox, or not?
@ AVLinux, I saw your post where you said pipwire is the future but you see no need to integrate it now, good, but just as you made deb files for avl pajackconnect, essential plugins, etc, could you make pipewire deb files for those whonwould like to use it now?
Re: AV Linux... continue with Openbox, or not?
I don't know why AVLinux does that, but there are a few people here who play with the latest kernels.
So the native 6.xx Debian and MX and also the Liquorix and Xanmod.
For normal applications (for me image and video editing) there is a clear order, both in pure ram consumption (which is uninteresting on modern systems with 8 GB and more) and in speed.
Liquorix wears the crown, then Xanmod and then debian/mx.
The difference in speed is in the range of 1-2% in comparison to the next
This affects last few kernels from the 5 branch, as well as the current ones from the 6 branch.
Depending on the application, this may be different, but you can try it out pretty easily (at least under MX, where installing and removing kernels via mxpi and mx cleanup is initially easy).
Translated with www.DeepL.com/Translator (free version)
So the native 6.xx Debian and MX and also the Liquorix and Xanmod.
For normal applications (for me image and video editing) there is a clear order, both in pure ram consumption (which is uninteresting on modern systems with 8 GB and more) and in speed.
Liquorix wears the crown, then Xanmod and then debian/mx.
The difference in speed is in the range of 1-2% in comparison to the next
This affects last few kernels from the 5 branch, as well as the current ones from the 6 branch.
Depending on the application, this may be different, but you can try it out pretty easily (at least under MX, where installing and removing kernels via mxpi and mx cleanup is initially easy).
Translated with www.DeepL.com/Translator (free version)
my working horse Desktop AMD Ryzen 9 3900x, 32GB Ram // SSD ... enough
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
Re: AV Linux... continue with Openbox, or not?
Liquorix wins, really...then why does it perform, woefully I would say, in this phoronix comparism? https://www.phoronix.com/review/hp-devone-kernels/8wdscharff wrote: Mon Nov 14, 2022 4:30 am I don't know why AVLinux does that, but there are a few people here who play with the latest kernels.
So the native 6.xx Debian and MX and also the Liquorix and Xanmod.
For normal applications (for me image and video editing) there is a clear order, both in pure ram consumption (which is uninteresting on modern systems with 8 GB and more) and in speed.
Liquorix wears the crown, then Xanmod and then debian/mx.
The difference in speed is in the range of 1-2% in comparison to the next
This affects last few kernels from the 5 branch, as well as the current ones from the 6 branch.
Depending on the application, this may be different, but you can try it out pretty easily (at least under MX, where installing and removing kernels via mxpi and mx cleanup is initially easy).
Translated with www.DeepL.com/Translator (free version)
Re: AV Linux... continue with Openbox, or not?
I do not use a test suite, but the programs I use.
For a very quick overview, mx-snapshot.
Otherwise Pitivi (1x 4k video + 1 HD video +80JPG in FHD format +2 music tracks cut together and export as HD movie).
Convert 20 ARW (RAW files) from my Sony A7III to 95% JPG in batch with Rawterapee.
I don't care what any test suites claim since Windows 386, I test with what I use on the hardware I use.
And my results (also since Windows 386) are rarely the same as ANY testsuit ;-}
So, good advice from me, just test it on YOUR hardware.
For a very quick overview, mx-snapshot.
Otherwise Pitivi (1x 4k video + 1 HD video +80JPG in FHD format +2 music tracks cut together and export as HD movie).
Convert 20 ARW (RAW files) from my Sony A7III to 95% JPG in batch with Rawterapee.
I don't care what any test suites claim since Windows 386, I test with what I use on the hardware I use.
And my results (also since Windows 386) are rarely the same as ANY testsuit ;-}
So, good advice from me, just test it on YOUR hardware.
my working horse Desktop AMD Ryzen 9 3900x, 32GB Ram // SSD ... enough
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
Re: AV Linux... continue with Openbox, or not?
what version of liquorix kernel are you on?wdscharff wrote: Mon Nov 14, 2022 6:24 am I do not use a test suite, but the programs I use.
For a very quick overview, mx-snapshot.
Otherwise Pitivi (1x 4k video + 1 HD video +80JPG in FHD format +2 music tracks cut together and export as HD movie).
Convert 20 ARW (RAW files) from my Sony A7III to 95% JPG in batch with Rawterapee.
I don't care what any test suites claim since Windows 386, I test with what I use on the hardware I use.
And my results (also since Windows 386) are rarely the same as ANY testsuit ;-}
So, good advice from me, just test it on YOUR hardware.
Re: AV Linux... continue with Openbox, or not?
current 6.0.0-8.2
my working horse Desktop AMD Ryzen 9 3900x, 32GB Ram // SSD ... enough
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
mx-fluxbox, what else?
In nature there are neither rewards nor punishments.
There are consequences.
my wallpaper gallery
Re: AV Linux... continue with Openbox, or not?
@Aceediq
Wait, so you've installed MX XFCE and want me to tell you how to make it into AV Linux MX Edition..? Why would you do that when it's quite obvious that I'm working on releasing an ISO built on MX with the complete XFCE4 Desktop (no Openbox) within the next week or so? I'm already taking all of my spare time to do exactly that..
As far as PipeWire, it's already in the MX Test Repo ready to install, feel free but it is currently absolutely of no benefit for Audio work, a significant number of Linux Audio enthusiasts have tried it and uninstalled it and went back to JACK (for now).
https://forum.mxlinux.org/viewtopic.php?t=71995
To be clear, I package my own UI utilities and scripts, I package outside Plugin binaries and closed-source stuff that cannot be put it Debian or MX Repos and I package bundled software like Ardour that I have permission to Distribute but is also not encouraged to be put in Distribution Repos, in the example of Ardour the source code is openly provided but they don't give tech support to self-compiled or Distro-packaged versions and Debian/MX will never Package stuff like Reaper, Harrison Mixbus 32C and commercial Plugin Demos. Lastly I wrap AppImages in Debs for the ISO because for a handful of apps it is the most expedient way to get the latest self-contained versions without hogging all the MX Packagers time on very complicated applications.
I'm not going to package fundamental parts and pieces of the OS like an Audio server, that is the beauty of building on top of something like MX where it is done properly with their expertise.
@wdscharff
On top of what you've said Liquorix has low latency preemption that allows use with the 'threadirqs' boot parameter which prioritizes the Audio IRQ's on the system and is an important piece of the puzzle to reduce the Audio latency for Audio recording, that is the main reason I prefer it. I truly wish a special preempt Kernel was not required as it is another customization and complication to be continually dealt with..
Wait, so you've installed MX XFCE and want me to tell you how to make it into AV Linux MX Edition..? Why would you do that when it's quite obvious that I'm working on releasing an ISO built on MX with the complete XFCE4 Desktop (no Openbox) within the next week or so? I'm already taking all of my spare time to do exactly that..

As far as PipeWire, it's already in the MX Test Repo ready to install, feel free but it is currently absolutely of no benefit for Audio work, a significant number of Linux Audio enthusiasts have tried it and uninstalled it and went back to JACK (for now).
https://forum.mxlinux.org/viewtopic.php?t=71995
To be clear, I package my own UI utilities and scripts, I package outside Plugin binaries and closed-source stuff that cannot be put it Debian or MX Repos and I package bundled software like Ardour that I have permission to Distribute but is also not encouraged to be put in Distribution Repos, in the example of Ardour the source code is openly provided but they don't give tech support to self-compiled or Distro-packaged versions and Debian/MX will never Package stuff like Reaper, Harrison Mixbus 32C and commercial Plugin Demos. Lastly I wrap AppImages in Debs for the ISO because for a handful of apps it is the most expedient way to get the latest self-contained versions without hogging all the MX Packagers time on very complicated applications.
I'm not going to package fundamental parts and pieces of the OS like an Audio server, that is the beauty of building on top of something like MX where it is done properly with their expertise.
@wdscharff
On top of what you've said Liquorix has low latency preemption that allows use with the 'threadirqs' boot parameter which prioritizes the Audio IRQ's on the system and is an important piece of the puzzle to reduce the Audio latency for Audio recording, that is the main reason I prefer it. I truly wish a special preempt Kernel was not required as it is another customization and complication to be continually dealt with..
Last edited by AVLinux on Mon Nov 14, 2022 10:36 am, edited 1 time in total.