Live mixing with Linux - State of the art 2018

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

User avatar
JamesPeters
Established Member
Posts: 21
Joined: Fri Jun 29, 2018 6:35 pm
Contact:

Re: Live mixing with Linux - State of the art 2018

Postby JamesPeters » Thu Dec 13, 2018 10:40 pm

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. :D 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. :lol:

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.
http://petersamplification.com
Core i3-6300 - MSI B150M Mortar - 8 GB RAM - Asus Xonar DX - MX Linux (MX-18_x64) - REAPER for Linux

folderol
Established Member
Posts: 770
Joined: Mon Sep 28, 2015 8:06 pm
Location: Here, of course!
Contact:

Re: Live mixing with Linux - State of the art 2018

Postby folderol » Fri Dec 14, 2018 12:07 am

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!

User avatar
JamesPeters
Established Member
Posts: 21
Joined: Fri Jun 29, 2018 6:35 pm
Contact:

Re: Live mixing with Linux - State of the art 2018

Postby JamesPeters » Fri Dec 14, 2018 12:51 am

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!


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).

I did this with ALSA though. I don't use JACK.
http://petersamplification.com
Core i3-6300 - MSI B150M Mortar - 8 GB RAM - Asus Xonar DX - MX Linux (MX-18_x64) - REAPER for Linux

User avatar
Nuri
Established Member
Posts: 32
Joined: Mon Oct 29, 2018 10:27 am

Re: Live mixing with Linux - State of the art 2018

Postby Nuri » Mon Dec 17, 2018 3:06 pm

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?!? :shock: Debian Stretch?!? What are you doin'?!? it's a commonplace i7 processor with integrated graphic!!! :x
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... :cry:

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?!? :shock:
Ok... I give up with Ubuntu Sudio...

Then, I was a bit disappointed...
:cry: :cry: :cry:

But I've still installed a stock Xubuntu 18.04. And guess what?
I get the best results with this distro!!! :mrgreen:
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!

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 3:49 pm

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!
FZ - Does humor belongs in Music?
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.

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 4:54 pm

@Nuri @https://forum.cockos.com/showpost.php?p=2071102&postcount=6

Code: Select all

$ hdsp
hdspconf    hdsploader  hdspmixer

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.

Try alsactl and alsamixer. If you can do the right settings there, do it as root again so it is finally saved.
root:

Code: Select all

alsactl store

@ https://forum.cockos.com/showpost.php?p ... ostcount=7
Maybe a lack in the ALSA driver of the RayDAT.

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 ... ;-)

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
    I don't care about the freedom of speech because I have nothing to say.

User avatar
JamesPeters
Established Member
Posts: 21
Joined: Fri Jun 29, 2018 6:35 pm
Contact:

Re: Live mixing with Linux - State of the art 2018

Postby JamesPeters » Mon Dec 17, 2018 6:05 pm

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.
http://petersamplification.com
Core i3-6300 - MSI B150M Mortar - 8 GB RAM - Asus Xonar DX - MX Linux (MX-18_x64) - REAPER for Linux

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 6:35 pm

JamesPeters wrote:monitoring through your hardware

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) Image
http://manual.ardour.org/synchronization/latency-and-latency-compensation/
FZ - Does humor belongs in Music?
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.

merlyn
Established Member
Posts: 80
Joined: Thu Oct 11, 2018 4:13 pm

Re: Live mixing with Linux - State of the art 2018

Postby merlyn » Mon Dec 17, 2018 7:18 pm

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.

Yes, there's a bug. Never use that command.

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! :)

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 7:32 pm

merlyn wrote:Never use that command.

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]
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
    I don't care about the freedom of speech because I have nothing to say.

merlyn
Established Member
Posts: 80
Joined: Thu Oct 11, 2018 4:13 pm

Re: Live mixing with Linux - State of the art 2018

Postby merlyn » Mon Dec 17, 2018 7:58 pm

khz wrote:With a Debian stable I never had problems with "apt autoremove".

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.

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.

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 8:13 pm

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

Code: Select all

apt-get -f -y install
afterwards, too
FZ - Does humor belongs in Music?
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.

User avatar
Nuri
Established Member
Posts: 32
Joined: Mon Oct 29, 2018 10:27 am

Re: Live mixing with Linux - State of the art 2018

Postby Nuri » Mon Dec 17, 2018 9:14 pm

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:
Why are you choosing to monitor through Reaper instead of monitoring through your hardware?

Read my 2 or 3 first posts in this thread (yeah, it's much blabla...).
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


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. :mrgreen:
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?

User avatar
khz
Established Member
Posts: 930
Joined: Thu Apr 17, 2008 6:29 am
Location: German

Re: Live mixing with Linux - State of the art 2018

Postby khz » Mon Dec 17, 2018 9:32 pm

Nuri wrote:As you can see, hdspconf does not work with the RayDAT.

Yeah. Not even with an AIO. But there is alsamixer/alsactl if it goes with what you want to set.
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 ... ;-)

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?

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.
FZ - Does humor belongs in Music?
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.

User avatar
Nuri
Established Member
Posts: 32
Joined: Mon Oct 29, 2018 10:27 am

Re: Live mixing with Linux - State of the art 2018

Postby Nuri » Wed Jan 02, 2019 11:29 am

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. :x

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.


Return to “System Tuning and Configuration”

Who is online

Users browsing this forum: No registered users and 1 guest