Live mixing with Linux - State of the art 2018
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 188
- Joined: Fri Jun 29, 2018 6:35 pm
- Has thanked: 8 times
- Been thanked: 15 times
Re: Live mixing with Linux - State of the art 2018
Good luck!
Yes, a bad cable has given me problems many times, with many systems (hard drives, USB, audio, etc.)! That's always a possibility. I try to keep extra cables just in case.
As for the amount of latency you'll notice: it will vary depending on how sensitive you are, how fast of a response you expect. I'm generally ok with up to approximately 12ms total latency. If I'm playing fast guitar parts though, sometimes my timing is affected by it a little bit and it's challenging to compensate.
Something else to consider: monitoring "through hardware" won't have the same latency as monitoring "through Reaper". If you can monitor from the audio device itself (instead of using monitoring on the track) during recording, that will be effectively "zero latency" (it's actually a few samples of latency, but nothing you'd notice). Reaper will record the part in sync with the other tracks, compensating for any latency during recording. If you are using guitar amp sims in Reaper (or are using MIDI synthesizers in Reaper), you'd need to monitor through Reaper. But you mentioned using a Kemper, so that should be something you can monitor in realtime through hardware. Check your settings of the RME card for its "input monitoring" (and/or "zero latency monitoring"). If you use that, your project can have 2 seconds of latency and it won't affect your performance during recording. During recording, your system's latency (of the input) would still be determined by the latency of the Kemper and the Behringer, but the latency of the RME wouldn't be noticed.
About buffer sizes: with my audio card, I initially chose 256 samples and 3 buffers (total = 768 samples). If I used 2 buffers of 256 samples (total = 512 samples), I would have problems. Later I realized I hadn't tried smaller block sizes but more blocks. I was able to make the system work correctly with a block size of 64 samples x5 blocks (320 samples), which is less than 2 buffers of 256 samples (total = 512 samples)! So the smaller size of the block wasn't as important as the number of blocks.
At 32 samples though, my system doesn't perform well with any number of blocks.
So remember that the total number of samples (block size in samples x number of blocks) isn't as important to keeping the system running correctly. There will be a minimum number of samples, of course. But maybe a smaller block size is ok, if you use more blocks. Also using larger blocks maybe is ok with fewer blocks.
Yes, a bad cable has given me problems many times, with many systems (hard drives, USB, audio, etc.)! That's always a possibility. I try to keep extra cables just in case.
As for the amount of latency you'll notice: it will vary depending on how sensitive you are, how fast of a response you expect. I'm generally ok with up to approximately 12ms total latency. If I'm playing fast guitar parts though, sometimes my timing is affected by it a little bit and it's challenging to compensate.
Something else to consider: monitoring "through hardware" won't have the same latency as monitoring "through Reaper". If you can monitor from the audio device itself (instead of using monitoring on the track) during recording, that will be effectively "zero latency" (it's actually a few samples of latency, but nothing you'd notice). Reaper will record the part in sync with the other tracks, compensating for any latency during recording. If you are using guitar amp sims in Reaper (or are using MIDI synthesizers in Reaper), you'd need to monitor through Reaper. But you mentioned using a Kemper, so that should be something you can monitor in realtime through hardware. Check your settings of the RME card for its "input monitoring" (and/or "zero latency monitoring"). If you use that, your project can have 2 seconds of latency and it won't affect your performance during recording. During recording, your system's latency (of the input) would still be determined by the latency of the Kemper and the Behringer, but the latency of the RME wouldn't be noticed.
About buffer sizes: with my audio card, I initially chose 256 samples and 3 buffers (total = 768 samples). If I used 2 buffers of 256 samples (total = 512 samples), I would have problems. Later I realized I hadn't tried smaller block sizes but more blocks. I was able to make the system work correctly with a block size of 64 samples x5 blocks (320 samples), which is less than 2 buffers of 256 samples (total = 512 samples)! So the smaller size of the block wasn't as important as the number of blocks.
At 32 samples though, my system doesn't perform well with any number of blocks.
So remember that the total number of samples (block size in samples x number of blocks) isn't as important to keeping the system running correctly. There will be a minimum number of samples, of course. But maybe a smaller block size is ok, if you use more blocks. Also using larger blocks maybe is ok with fewer blocks.
-
- Established Member
- Posts: 2083
- Joined: Mon Sep 28, 2015 8:06 pm
- Location: Here, of course!
- Has thanked: 232 times
- Been thanked: 400 times
- Contact:
Re: Live mixing with Linux - State of the art 2018
Just want to clarify some terms.
Jack works in terms of frames. A frame is 1 sample of mono, 2 of stereo, 5/7 surround etc. these being all in parallel.
You then have n frames per period and x periods per buffer. You can't have less than two periods per buffer as you can't read and write the same period - maybe in some esoteric environments you can, but not here
The original recommendation to use 3 periods per buffer was made in the days of USB1 which (for audio) has a granularity of 1mS. The later USB2 versions introduced 'microframes' having a granularity of 1/8th of that. i.e. 125uS .
Personally, I use 2 periods per buffer for everything and don't seem to have any problems. If I have X-runs the only parameter I change is the frames per period - KISS principle!
Jack works in terms of frames. A frame is 1 sample of mono, 2 of stereo, 5/7 surround etc. these being all in parallel.
You then have n frames per period and x periods per buffer. You can't have less than two periods per buffer as you can't read and write the same period - maybe in some esoteric environments you can, but not here
The original recommendation to use 3 periods per buffer was made in the days of USB1 which (for audio) has a granularity of 1mS. The later USB2 versions introduced 'microframes' having a granularity of 1/8th of that. i.e. 125uS .
Personally, I use 2 periods per buffer for everything and don't seem to have any problems. If I have X-runs the only parameter I change is the frames per period - KISS principle!
The Yoshimi guy {apparently now an 'elderly'}
-
- Established Member
- Posts: 188
- Joined: Fri Jun 29, 2018 6:35 pm
- Has thanked: 8 times
- Been thanked: 15 times
Re: Live mixing with Linux - State of the art 2018
You can see in my previous post that I'd done just that, and I had a problem. Reducing the size of the block, and using more blocks, resolved the problem (allowing me to use significantly lower latency).folderol wrote: Personally, I use 2 periods per buffer for everything and don't seem to have any problems. If I have X-runs the only parameter I change is the frames per period - KISS principle!
I did this with ALSA though. I don't use JACK.
Re: Live mixing with Linux - State of the art 2018
Results of the tests of last Sunday.
ONLY WINDOWS 10 FOR THE MOMENT!!!
Hardware check:
I connected the RayDAT in a small 1x PCIe slot (before it was in a large 16x PCIe slot).
--> no noticeable improvement
One of the two Behringer ADA8200 was wrong set as sync master (there is a small hardware switch on the back side that I previously overseen). Now both ADA8200 are synced over ADAT IN. The RME software of the RAYDAT displays that ADAT sync is now right. Indeed...
--> no noticeable improvement (clicks and pops remain at low latency settings).
Human perception of latency through in-ear monitoring:
The singer/guitarist was there and I asked him to say when latency becomes uncomfortable to play the guitar or to sing.
Results of his perception:
128 samples --> no go! To much latency
64 samples --> somehow perceptible but does not really interfere with playing/singing
32 samples --> not perceptible at all, nice!
Don't forget I'm speaking about latency perception OVER IN-EAR MONITORING!
Software optimizations:
PDC producing plugins were removed from the Reaper project and some settings were changed in the UEFI/BIOS of the PC.
Instead of Reaper's built-in plugins I load some Waves plugins (the lightweight ones, without PDC: SSLEQ, API-2500...). I does not seem to have a big impact on the general performance.
If I remove all plugins, all clicks and pops are gone (but I forgot the audio settings, sorry, should try again).
System check with Latency Monitoring (from https://resplendence.com/latencymon):
Latencymon reports "your system seems to have problems handling real-time audio blablabla..."
Something is wrong in the system but I don't know why and what...
ON THE LINUX SIDE:
I've made some new tests with Linux.
A long night of downloading, dd'ing to usb stick, installing, tuning, tweaking... Interesting...
(only "dry runs", without real audio input/output, only looking at the messages of Qjackctl)
1.
I've installed AV Linux 2018
--> to much xruns at 32, 64 and even 128 samples (thousands in a minute)
I give up with AV Linux. And with KXStudio which produces exactly the same results.
2.
Then I've installed Debian Stretch proposed by khz (netinstall including firmware, plus non-free repos).
It couldn't recognize the Intel graphic card and the resolution stucked at 1024x... WTF?!? Debian Stretch?!? What are you doin'?!? it's a commonplace i7 processor with integrated graphic!!!
I've checked the md5sum of the iso. Was right. I've reinstalled the same iso and I got the same problem.
?!?
Ok... I give up with the stock Debian...
3.
Then I've installed Ubuntu Studio 18.10. Installation ran fine and the hardware has been correctly recognized.
As everything was set up, I've run "sudo apt autoremove" to clean up the system and... Guess what?!?
Ubuntu Studio removes also Thunar, xfwm4, etc and a lot of fundamental packages so that after reboot, the system was almost dead.
Never had something like that on Linux! WTF?!?
Ok... I give up with Ubuntu Sudio...
Then, I was a bit disappointed...
But I've still installed a stock Xubuntu 18.04. And guess what?
I get the best results with this distro!!!
Of course, I've installed the low-latency kernel, set the cpu governor to performance, etc. Every package from the official Ubuntu repos.
I got about hundred of xruns per minute at 32 samples and 2 periods (jack) always with the same Reaper test project.
At this setting, latency displayed by Reaper is 1,9ms (total, sum of 0,6ms(in)/1,3ms(out)).
It's interesting to note that I got less xruns at 32 samples/2 periods than at 64 samples/4 periods.
At 128 samples, I got 0 xrun. No matter how much periods (2, 4, 6...). Even with 12 instances of ReaVerbate and 40 other plugins.
0 xrun.
Ok. Further testing and tweaking results coming soon...
Liquorix RT Kernel, rtirq tuning, disabling unused services, etc.
I want this system to work at 32 samples / 2 periods without clicks and pops!
ONLY WINDOWS 10 FOR THE MOMENT!!!
Hardware check:
I connected the RayDAT in a small 1x PCIe slot (before it was in a large 16x PCIe slot).
--> no noticeable improvement
One of the two Behringer ADA8200 was wrong set as sync master (there is a small hardware switch on the back side that I previously overseen). Now both ADA8200 are synced over ADAT IN. The RME software of the RAYDAT displays that ADAT sync is now right. Indeed...
--> no noticeable improvement (clicks and pops remain at low latency settings).
Human perception of latency through in-ear monitoring:
The singer/guitarist was there and I asked him to say when latency becomes uncomfortable to play the guitar or to sing.
Results of his perception:
128 samples --> no go! To much latency
64 samples --> somehow perceptible but does not really interfere with playing/singing
32 samples --> not perceptible at all, nice!
Don't forget I'm speaking about latency perception OVER IN-EAR MONITORING!
Software optimizations:
PDC producing plugins were removed from the Reaper project and some settings were changed in the UEFI/BIOS of the PC.
Instead of Reaper's built-in plugins I load some Waves plugins (the lightweight ones, without PDC: SSLEQ, API-2500...). I does not seem to have a big impact on the general performance.
If I remove all plugins, all clicks and pops are gone (but I forgot the audio settings, sorry, should try again).
System check with Latency Monitoring (from https://resplendence.com/latencymon):
Latencymon reports "your system seems to have problems handling real-time audio blablabla..."
Something is wrong in the system but I don't know why and what...
ON THE LINUX SIDE:
I've made some new tests with Linux.
A long night of downloading, dd'ing to usb stick, installing, tuning, tweaking... Interesting...
(only "dry runs", without real audio input/output, only looking at the messages of Qjackctl)
1.
I've installed AV Linux 2018
--> to much xruns at 32, 64 and even 128 samples (thousands in a minute)
I give up with AV Linux. And with KXStudio which produces exactly the same results.
2.
Then I've installed Debian Stretch proposed by khz (netinstall including firmware, plus non-free repos).
It couldn't recognize the Intel graphic card and the resolution stucked at 1024x... WTF?!? Debian Stretch?!? What are you doin'?!? it's a commonplace i7 processor with integrated graphic!!!
I've checked the md5sum of the iso. Was right. I've reinstalled the same iso and I got the same problem.
?!?
Ok... I give up with the stock Debian...
3.
Then I've installed Ubuntu Studio 18.10. Installation ran fine and the hardware has been correctly recognized.
As everything was set up, I've run "sudo apt autoremove" to clean up the system and... Guess what?!?
Ubuntu Studio removes also Thunar, xfwm4, etc and a lot of fundamental packages so that after reboot, the system was almost dead.
Never had something like that on Linux! WTF?!?
Ok... I give up with Ubuntu Sudio...
Then, I was a bit disappointed...
But I've still installed a stock Xubuntu 18.04. And guess what?
I get the best results with this distro!!!
Of course, I've installed the low-latency kernel, set the cpu governor to performance, etc. Every package from the official Ubuntu repos.
I got about hundred of xruns per minute at 32 samples and 2 periods (jack) always with the same Reaper test project.
At this setting, latency displayed by Reaper is 1,9ms (total, sum of 0,6ms(in)/1,3ms(out)).
It's interesting to note that I got less xruns at 32 samples/2 periods than at 64 samples/4 periods.
At 128 samples, I got 0 xrun. No matter how much periods (2, 4, 6...). Even with 12 instances of ReaVerbate and 40 other plugins.
0 xrun.
Ok. Further testing and tweaking results coming soon...
Liquorix RT Kernel, rtirq tuning, disabling unused services, etc.
I want this system to work at 32 samples / 2 periods without clicks and pops!
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
Through your patience and pioneering spirit you learn a lot about Linux and audio.
I hope you achieve what you want!
For Debian and graphics the package "firmware-linux-nonfree" is decisive.
I am happy that it worked best with Xubuntu.
That's just open source: thousands of possibilities .....
Don't give up!
I hope you achieve what you want!
For Debian and graphics the package "firmware-linux-nonfree" is decisive.
I am happy that it worked best with Xubuntu.
That's just open source: thousands of possibilities .....
Don't give up!
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
@Nuri @https://forum.cockos.com/showpost.php?p ... ostcount=6
root:
@ https://forum.cockos.com/showpost.php?p ... ostcount=7
We (a friend and me, (first time 2011 in 2.6.39 kernel, 2013 Tested/Bugfixes in 3.12 kernel)) bought a RME AIO and analyzed the sound card with the ALSA RME maintainer via ssh and created a driver based on the data. Or so ...
Code: Select all
$ hdsp
hdspconf hdsploader hdspmixer
Try alsactl and alsamixer. If you can do the right settings there, do it as root again so it is finally saved.The Hammerfall PCI cards of RME are good supported and can be configured using the tool HDSPconf.
This tool does not work with the RayDAT (which is PCI express). It even does not want to start because it's designed for the PCI cards, I presume.
HDSPMixer works with the RayDAT, no problem.
root:
Code: Select all
alsactl store
This is not a bug but what was feasible from the ALSA RME maintainer. Unfortunately this is partly related to RME, but it's great that so much of the good hardware works under Linux.Maybe a lack in the ALSA driver of the RayDAT.
We (a friend and me, (first time 2011 in 2.6.39 kernel, 2013 Tested/Bugfixes in 3.12 kernel)) bought a RME AIO and analyzed the sound card with the ALSA RME maintainer via ssh and created a driver based on the data. Or so ...
Code: Select all
man alsactl
Code: Select all
ALSACTL(1) General Commands Manual ALSACTL(1)
NAME
alsactl - advanced controls for ALSA soundcard driver
SYNOPSIS
alsactl [options] [store|restore|init] <card # or id or device>
alsactl monitor <card # or id>
DESCRIPTION
alsactl is used to control advanced settings for the ALSA soundcard
drivers. It supports multiple soundcards. If your card has features
that you can't seem to control from a mixer application, you have come
to the right place.
COMMANDS
store saves the current driver state for the selected soundcard to the
configuration file.
restore loads driver state for the selected soundcard from the configu‐
ration file. If restoring fails (eventually partly), the init action is
called.
nrestore is like restore, but it notifies also the daemon to do new
rescan for available soundcards.
init tries to initialize all devices to a default state. If device is
not known, error code 99 is returned.
daemon manages to save periodically the sound state.
rdaemon like daemon but restore the sound state at first.
kill notifies the daemon to do the specified operation (quit, rescan,
save_and_quit).
monitor is for monitoring the events received from the given control
device.
If no soundcards are specified, setup for all cards will be saved,
loaded or monitored.
OPTIONS
-h, --help
Help: show available flags and commands.
-d, --debug
Use debug mode: a bit more verbose.
-v, --version
Print alsactl version number.
-f, --file
Select the configuration file to use. The default is
/var/lib/alsa/asound.state.
-l, --lock
Use the file locking to serialize the concurrent access to the
state file (this option is default for the global state file).
-L, --no-lock
Do not use the file locking to serialize the concurrent access
to the state file (including the global state file).
-O, --lock-state-file
Select the state lock file path.
-F, --force
Used with restore command. Try to restore the matching control
elements as much as possible. This option is set as default
now.
-g, --ignore
Used with store and restore commands. Do not show 'No soundcards
found' and do not set an error exit code when soundcards are not
installed.
-P, --pedantic
Used with restore command. Don't restore mismatching control
elements. This option was the old default behavior.
-I, --no-init-fallback
Don't initialize cards if restore fails. Since version 1.0.18,
alsactl tries to initialize the card with the restore operation
as default. But this can cause incompatibility with the older
version. The caller may expect that the state won't be touched
if no state file exists. This option takes the restore behavior
back to the older version by suppressing the initialization.
-r, --runstate
Save restore and init state to this file. The file will contain
only errors. Errors are appended with the soundcard id to the
end of file.
-R, --remove
Remove runstate file at first.
-E, --env #=#
Set environment variable (useful for init action or you may
override ALSA_CONFIG_PATH to read different or optimized config‐
uration - may be useful for "boot" scripts).
-i, --initfile
The configuration file for init. By default, PRE‐
FIX/share/alsa/init/00main is used.
-p, --period
The store period in seconds for the daemon command.
-e, --pid-file
The pathname to store the process-id file in the HDB UUCP format
(ASCII).
-b, --background
Run the task in background.
-s, --syslog
Use syslog for messages.
-n, --nice
Set the process priority (see 'man nice')
-c, --sched-idle
Set the process scheduling policy to idle (SCHED_IDLE).
FILES
/var/lib/alsa/asound.state (or whatever file you specify with the -f
flag) is used to store current settings for your soundcards. The set‐
tings include all the usual soundcard mixer settings. More impor‐
tantly, alsactl is capable of controlling other card-specific features
that mixer apps usually don't know about.
The configuration file is generated automatically by running alsactl
store. Editing the configuration file by hand may be necessary for some
soundcard features (e.g. enabling/disabling automatic mic gain, digital
output, joystick/game ports, some future MIDI routing options, etc).
SEE ALSO
amixer(1), alsamixer(1), aplay(1), alsactl_init(7)
BUGS
None known.
AUTHOR
alsactl is by Jaroslav Kysela <perex@perex.cz> and Abramo Bagnara
..
Code: Select all
man alsamixer
Code: Select all
ALSAMIXER(1) General Commands Manual ALSAMIXER(1)
NAME
alsamixer - soundcard mixer for ALSA soundcard driver, with ncurses interface
SYNOPSIS
alsamixer [options]
DESCRIPTION
alsamixer is an ncurses mixer program for use with the ALSA soundcard drivers. It supports multiple soundcards with multiple devices.
OPTIONS
-h, --help
Help: show available flags.
-c, --card <card number or identification>
Select the soundcard to use, if you have more than one. Cards are numbered from 0 (the default).
-D, --device <device identification>
Select the mixer device to control.
-V, --view <mode>
Select the starting view mode, either playback, capture or all.
-g, --no-color
Toggle the using of colors.
MIXER VIEWS
The top-left corner of alsamixer is the are to show some basic information: the card name, the mixer chip name, the current view mode and the currently selected mixer item. When
the mixer item is switched off, [Off] is displayed in its name.
Volume bars are located below the basic information area. You can scroll left/right when all controls can't be put in a single screen. The name of each control is shown in the
bottom below the volume bars. The currently selected item is drawn in red and/of emphasized.
Each mixer control with volume capability shows a box and the current volume filled in that box. The volume percentages are displayed below the volume bar for left and right
channels. For a mono control, only one value is shown there.
When a mixer control is turned off, M (mute) appears below the volume bar. When it's turned on, O in green appears instead. You can toggle the switch via m key.
When a mixer control has capture capability, the capture flag appears below the volume bar, too. When the capture is turned off, ------- is shown. CAPTURE in red appears when
the capture switch is turned on. In addition, L and R letters appear in left and right side to indicate that left and the right channels are turned on.
Some controls have the enumeration list, and don't show boxes but only texts which indicate the currently active item. You can change the item via up/down keys.
VIEW MODES
alsamixer has three view modes: playback, capture and all. In the playback view, only the controls related with playback are shown. Similarly, only the controls for capture
(recording) are shown in the capture view. The all view mode shows all controls. The current view mode is displayed in the top-left position together with the mixer name, etc.
The default view mode is the playback view. You can change it via -V option.
Each view mode can be switched via keyboard commands, too. See the next section.
KEYBOARD COMMANDS
alsamixer recognizes the following keyboard commands to control the soundcard. Commands shown here in upper case can also be given in lower case. To be reminded of these key‐
strokes, hit the h key.
General Controls
The Left and right arrow keys are used to select the channel (or device, depending on your preferred terminology). You can also use n ("next") and p ("previous").
The Up and Down Arrows control the volume for the currently selected device. You can also use + or - for the same purpose. Both the left and right signals are affected. For inde‐
pendent left and right control, see below.
The B or = key adjusts the balance of volumes on left and right channels.
M toggles muting for the current channel (both left and right). If the hardware supports it, you can mute left and right independently by using , (or <) and . (or >) respec‐
tively.
SPACE enables recording for the current channel. If any other channels have recording enabled, they will have their recording function disabled first. This only works for valid
input channels, of course.
L re-draws the screen.
View Mode Controls
Function keys are used to change view modes. You can switch to the help mode and the proc info mode via F1 and F2 keys, respectively. On terminals that can't use function keys
like gnome-terminal, ? and / keys can be used alternatively for help and proc modes.
F3, F4 and F5 keys are used to switch to playback, capture and all view mode, respectively. TAB key toggles the current view mode circularly.
Quick Volume Changes
PageUp increases volume by 5.
PageDown decreases volume by 5.
End sets volume to 0.
You can also control left & right levels for the current channel independently, as follows:
[Q | W | E ] -- turn UP [ left | both | right ]
[Z | X | C ] -- turn DOWN [ left | both | right ]
If the currently selected mixer channel is not a stereo channel, then all UP keys will work like W, and all DOWN keys will work like X.
The number keys from 0 to 9 are to change the absolute volume quickly. They correspond to 0 to 90% volume.
Selecting the Sound Card
You can select another sound card by pressing the F6 or S keys. This will show a list of available sound cards to choose from, and an entry to enter the mixer device name by
hand.
Exiting
Quit the program with ALT Q, or by hitting ESC. Please note that you might need to hit ESC twice on some terminals since it's regarded as a prefix key.
VOLUME MAPPING
In alsamixer, the volume is mapped to a value that is more natural for a human ear. The mapping is designed so that the position in the interval is proportional to the volume as
a human ear would perceive it, i.e. the position is the cubic root of the linear sample multiplication factor. For controls with a small range (24 dB or less), the mapping is
linear in the dB values so that each step has the same size visually.
Only for controls without dB information, a linear mapping of the hardware volume register values is used (this is the same algorithm as used in the old alsamixer).
SEE ALSO
amixer(1), aplay(1), arecord(1)
BUGS
Some terminal emulators (e.g. nxterm) may not work quite right with ncurses, but that's their own damn fault. Plain old xterm seems to be fine.
...
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
-
- Established Member
- Posts: 188
- Joined: Fri Jun 29, 2018 6:35 pm
- Has thanked: 8 times
- Been thanked: 15 times
Re: Live mixing with Linux - State of the art 2018
Why are you choosing to monitor through Reaper instead of monitoring through your hardware? Does your guitarist use virtual amp plugins in Reaper? Why would your singer need to monitor through Reaper instead of through hardware?
If you can monitor through hardware, that's your solution.
If you can monitor through hardware, that's your solution.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
Yes. Hardware https://www.rme-audio.de/english/techinfo/lola_lomo.htm (German: https://www.rme-audio.de/techinfo/lola_lomo.htm) != Software (and +/- 50 effects in real time)JamesPeters wrote:monitoring through your hardware
http://manual.ardour.org/synchronizatio ... pensation/
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Live mixing with Linux - State of the art 2018
Yes, there's a bug. Never use that command.Nuri wrote:As everything was set up, I've run "sudo apt autoremove" to clean up the system and... Guess what?!?
Ubuntu Studio removes also Thunar, xfwm4, etc and a lot of fundamental packages so that after reboot, the system was almost dead.
You could have brought the system back from that state. But if you're getting results with Xubuntu, that's good. Just don't type that again!
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
With a Debian stable I never had problems with "apt autoremove". Especially since it lists all packages it wants to uninstall and asks you if you want to do this. [Yes/No]merlyn wrote:Never use that command.
With a *buntu this can be different of course.
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
-
- Established Member
- Posts: 1392
- Joined: Thu Oct 11, 2018 4:13 pm
- Has thanked: 168 times
- Been thanked: 247 times
Re: Live mixing with Linux - State of the art 2018
Ok. I had used autoremove on KX Studio several times without a problem. It did exactly as you described, listing what it was going to remove, then one time when I answered 'y' a huge list of software started rolling up the screen. Half the system. I was disturbed, but I thought they might be old versions. They weren't, and I ended up with a bare bones system. Not a huge problem, I re-installed everything I needed.khz wrote:With a Debian stable I never had problems with "apt autoremove".
I looked it up, and somehow packages that come with the distribution get marked as 'automatically installed'.
So to be on the safe side on Ubuntu, I would think it's better not to use autoremove. I'm surprised that it hasn't been sorted by now.
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
Yes with a *buntu you should not execute this command just like that. With a Debian stable was problem-free so far, fortunately. But I always do afterwards, too
Code: Select all
apt-get -f -y install
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
Re: Live mixing with Linux - State of the art 2018
I'm using Ubuntu since 2008 and I never got any problem with "apt autoremove". Never mind...
It seems that Xubuntu 18.04 does the job.
@JamesPeters:
Because I want that Reaper does the job of a live mixing engineer!
Our songs are always played the same (fixed structure) and, this way, it's easy to automate level, pan, effects... of each track depending of what song and what part of the song is played.
Some use a Behringer X32 to do the job.
I want to do it with a PC.
@khz
As you can see, hdspconf does not work with the RayDAT.
About latency:
our last real tests on Sunday have shown that 32 samples or even 64 samples would be good to play live.
At 32 samples, you cannot notice anything. It's really nice!
I don't further need any calculation or estimation since I now have a real experience on this subject.
New discovers and experiences today:
I've installed the Liquorix RT Kernel on Xubuntu 18.04 and it SIGNIFICANTLY reduces xruns.
I now get between 0 and 5 xruns per minute at 32 samples / 2 periods.
But they are only "dry runs", without audio, so I don't know how much clicks and pops are produced.
I'm currently at home with the i7-8700K workstation. On next Thursday, I will be in rehearsal again and I will test there with real audio inputs/outputs.
In Qjackctl, if I set the RT prio of Jack at 98, it almost get no xruns at all.
Could this setting an issue for system stability? Or can I use it safely?
It seems that Xubuntu 18.04 does the job.
@JamesPeters:
Read my 2 or 3 first posts in this thread (yeah, it's much blabla...).Why are you choosing to monitor through Reaper instead of monitoring through your hardware?
Because I want that Reaper does the job of a live mixing engineer!
Our songs are always played the same (fixed structure) and, this way, it's easy to automate level, pan, effects... of each track depending of what song and what part of the song is played.
Some use a Behringer X32 to do the job.
I want to do it with a PC.
@khz
Code: Select all
mk7@mk7kiste:~$ hdsploader
hdsploader - firmware loader for RME Hammerfall DSP cards
Looking for HDSP + Multiface or Digiface cards :
Card 0 : RME RayDAT S/N 0xf184c1 at 0xa1100000, irq 17
Card 1 : HDA Intel PCH at 0xa1310000 irq 127
Code: Select all
mk7@mk7kiste:~$ hdspconf
HDSPConf 1.4 - Copyright (C) 2003 Thomas Charbonnel <thomas@undata.org>
This program comes WITH ABSOLUTELY NO WARRANTY
HDSPConf is free software, see the file copying for details
Looking for HDSP cards :
Card 0 : RME RayDAT S/N 0xf184c1 at 0xa1100000, irq 17
Card 1 : HDA Intel PCH at 0xa1310000 irq 127
No Hammerfall DSP card found.
Code: Select all
mk7@mk7kiste:~$ hdspmixer
HDSPMixer 1.11 - Copyright (C) 2003 Thomas Charbonnel <thomas@undata.org>
This program comes with ABSOLUTELY NO WARRANTY
HDSPMixer is free software, see the file COPYING for details
Looking for RME cards:
Card 0: RME RayDAT S/N 0xf184c1 at 0xa1100000, irq 17
RME RayDAT found!
Card 1: HDA Intel PCH at 0xa1310000 irq 127
1 RME cards card found.
Initializing default presets
About latency:
our last real tests on Sunday have shown that 32 samples or even 64 samples would be good to play live.
At 32 samples, you cannot notice anything. It's really nice!
I don't further need any calculation or estimation since I now have a real experience on this subject.
New discovers and experiences today:
I've installed the Liquorix RT Kernel on Xubuntu 18.04 and it SIGNIFICANTLY reduces xruns.
I now get between 0 and 5 xruns per minute at 32 samples / 2 periods.
But they are only "dry runs", without audio, so I don't know how much clicks and pops are produced.
I'm currently at home with the i7-8700K workstation. On next Thursday, I will be in rehearsal again and I will test there with real audio inputs/outputs.
In Qjackctl, if I set the RT prio of Jack at 98, it almost get no xruns at all.
Could this setting an issue for system stability? Or can I use it safely?
- khz
- Established Member
- Posts: 1648
- Joined: Thu Apr 17, 2008 6:29 am
- Location: German
- Has thanked: 42 times
- Been thanked: 92 times
Re: Live mixing with Linux - State of the art 2018
Yeah. Not even with an AIO. But there is alsamixer/alsactl if it goes with what you want to set.Nuri wrote:As you can see, hdspconf does not work with the RayDAT.
We hadn't managed to get hdspctl to work with these cards back then. Adrian (ALSA RME Support) is not an RME employee but an employee(?) of a university.
Unfortunately RME does not provide drivers for Linux directly. That's sad, I think, too, but unfortunately that's how it is.
khz wrote:This is not a bug but what was feasible from the ALSA RME maintainer.
Unfortunately this is partly related to RME, but it's great that so much of the good hardware works under Linux.
We (a friend and me, (first time 2011 in 2.6.39 kernel, 2013 Tested/Bugfixes in 3.12 kernel)) bought a RME AIO and analyzed the sound card with the ALSA RME maintainer via ssh and created a driver based on the data. Or so ...
Anything under 100 is fine. The system and hardware should always have more than the audio. So 98 would be maximum for audio. IMHO Test it.Nuri wrote:In Qjackctl, if I set the RT prio of Jack at 98, it almost get no xruns at all.
Could this setting an issue for system stability? Or can I use it safely?
. . . FZ - Does humor belongs in Music?
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
. . GNU/LINUX@AUDIO ~ /Wiki $ Howto.Info && GNU/Linux Debian installing >> Linux Audio Workstation LAW
- I don't care about the freedom of speech because I have nothing to say.
Re: Live mixing with Linux - State of the art 2018
Ok... I give up again with Linux since I get the same results with Win10.
On both systems, I can run glitch free with a 128 samples buffer size.
At 32 and 64 samples I get (a lot of) clicks and pops on both Win10 and Linux. Nothing has improved, no matter what I'm tuning in the OS's or in the UEFI-BIOS.
The only difference between Win10 and Linux is that the performance meter of Reaper reports xruns in Linux and no xrun at all in Win10.
But what you hear out of the audio is the same at 32 and 64 samples with both systems: krkkr, kzzz, shrshr...
For 2 weeks, we made some real tests with the whole band processed over the PC, playing 3 hours in rehearsal, and it seems that we can play at 128 samples (48kHz, 24bit), but latency is slightly noticeable. However, no one complained since the overall sound was really clean and nice...
32 or even 64 samples would be of course a better choice but it actually does not work without glitches.
On Win10, I run LatencyMon 6.70 about 30 minutes and it says something like: "your system is able to process real time audio bla bla bla..."
The first results with LatencyMon were not good because it was an old version of the utility that does not support Win10.
With the last version, everything is reported as fine, but it doesn't solve my glitches problems.
We also decided to stick with Win10 since we can use our Waves plugins natively.
Thank you all for your support and for your tips!
Maybe next try with Linux in 2 years since things are changing quickly now in the right direction.
On both systems, I can run glitch free with a 128 samples buffer size.
At 32 and 64 samples I get (a lot of) clicks and pops on both Win10 and Linux. Nothing has improved, no matter what I'm tuning in the OS's or in the UEFI-BIOS.
The only difference between Win10 and Linux is that the performance meter of Reaper reports xruns in Linux and no xrun at all in Win10.
But what you hear out of the audio is the same at 32 and 64 samples with both systems: krkkr, kzzz, shrshr...
For 2 weeks, we made some real tests with the whole band processed over the PC, playing 3 hours in rehearsal, and it seems that we can play at 128 samples (48kHz, 24bit), but latency is slightly noticeable. However, no one complained since the overall sound was really clean and nice...
32 or even 64 samples would be of course a better choice but it actually does not work without glitches.
On Win10, I run LatencyMon 6.70 about 30 minutes and it says something like: "your system is able to process real time audio bla bla bla..."
The first results with LatencyMon were not good because it was an old version of the utility that does not support Win10.
With the last version, everything is reported as fine, but it doesn't solve my glitches problems.
We also decided to stick with Win10 since we can use our Waves plugins natively.
Thank you all for your support and for your tips!
Maybe next try with Linux in 2 years since things are changing quickly now in the right direction.