Linux-audio-user August 2019

linux-audio-user@lists.linuxaudio.org

39 participants
50 discussions

Audio performance in guest VM (MS-Win) on Linux host

by bdutta

Hi, Is anyone aware of any comparative study of various hypervisors (KVM, VMware, Virtualbox) running Windows guests, on Linux hosts -- in respect of quality of audio software, in terms of latency, jitter, glitches etc. Based on my reading, I've understood that accuracy and reliability of the timer interrupt available to guest kernel (in VM) should not be expected to be equal to same on bare-metal. However, are there some hypervisors (workstation oriented), that are better than others in this regard ? The question is in context of need to run some Windows software which doesn't work well under WINE (even with WineASIO, various recommended WINE tricks applied), and I find the need to setup/maintain a dual-boot environment too cumbersome, as I do 90% of my work in Linux. regards, BD -- Sent from: http://linux-audio.4202.n7.nabble.com/linux-audio-user-f5.html

5 years, 3 months

jack2 help?

by Matt Zagrabelny

The JACK (1) page [0] references this mailing list for possible dialog about jack usage. I am using the jack2 daemon. I am launching a jack aware application (OBS), but the connection to jack is not being made automatically, so I use jack_connect to make the connection between the two ports (system mic and OBS reader). Is there a "jack_FOO" CLI tool that can be used to query what available ports there are? The reason being is I need to put a sleep into my script to connect the jack ports: /usr/bin/obs & sleep 10 jack_connect system:out_1 OBS:jack_in I'd like to eliminate the sleep command and poll jack to see if OBS has any port available. What do you think? Thanks! -m [0] http://jackaudio.org/community.html

5 years, 3 months

A step-by-step tutorial for live audio streaming with Roc

by Victor Gaydov

Hi! I've prepared a tutorial explaining how to set up Roc[1] to perform live streaming between Ubuntu and macOS desktops, Raspberry Pi boards, and Android devices. https://gavv.github.io/articles/roc-tutorial/ [1] https://roc-project.github.io/ -- Victor

5 years, 3 months

Re: [LAU] rtirq configuration with external USB DAC?

by Chris Caudle

On Tue, August 13, 2019 10:11 am, al3xu5 / dotcommon wrote: >> The timer "rtc" and the keyboard "i8042" should be removed from the >> list, years back they where added, but today this isn't done anymore. > > Can you tell me why they should be removed now, please? The RT prioritization should be based on what devices and software should always be serviced in a timely manner. In the context of this audio group that would mean the audio device driver(s), jackd if that is used, and then anything else which might be critical. The jackd server will set priority independently, so the only entries which need to be in rtirq are the hardware device drivers which need realtime priority. There is no current software that I am aware of which could require realtime access to the hardware realtime clock (despite the name it is not related to realtime behavior in this context). Including that device in the rtirq list just wastes processor time servicing a device with no use for audio. The i8042 is the emulated legacy keyboard controller. I do not think it is necessary, but I could accept the argument that you don't want to miss any user interaction. It should definitely be last in the list, so the i8042 is at the lowest realtime priority. Probably as a practical concern there is no reason to keep i8042 in the list, user interaction is slow enough that unless the RT software is not behaving correctly the key input should still be serviced, and if the RT software is behaving in a way which uses too much processor time it will probably not respond properly to user key presses, so in either case having the keyboard controller driver serviced with realtime priority does not seem to offer benefit. -- Chris Caudle

5 years, 3 months

Re: [LAU] rtirq configuration with external USB DAC?

by al3xu5 / dotcommon

Il giorno martedì 13/08/2019 19:23:12 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> ha scritto: > "you can work around some of these TSC shortcomings by configuring > additional kernel boot parameters. For instance, the idle=poll > parameter forces the clock to avoid entering the idle state, and the > processor.max_cstate=1 parameter prevents the clock from entering > deeper C-states. Note however that in both cases there would be an > increase on energy consumption, as the system would always run at top > speed." - > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_… > Very interesting. Thanks again Regards -- al3xu5 Say NO to copyright, patents, trademarks and any industrial design restrictions. ________________________________________________________________________________ Public GPG/PGP key block ID: 4096 bit RSA key 69C5977BF94CFE23 Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23

5 years, 3 months

Re: [LAU] rtirq configuration with external USB DAC?

by al3xu5 / dotcommon

Il giorno martedì 13/08/2019 19:06:33 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> ha scritto: > you need to do your own research or wait that somebody else does chime in. As I suspected... ;) > However, here are my guesses, no hard facts: > > On Tue, 2019-08-13 at 17:11 +0200, al3xu5 / dotcommon wrote: > > Can you tell me why they shoud be removed now, please? > > https://www.rncbc.org/drupal/comment/6553#comment-6553 Thank you. Also I have read at: https://www.rncbc.org/drupal/comment/6561#comment-6561 ...and now thinga are clear enough. > Regarding timer usage there are anyway a lot of myths and no clear source of > information. RTC vs HPET (HR timer) vs TSC. While TSC should be the best > source, some information claims that TSC could suffer from pitfalls that > render it useless. I know it is a mess... I should have the cpu governor set to performance (no idle): me@arrakis:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance performance performance and timers: me@arrakis:~$ ls -l /dev/rtc0 crw-rw---- 1 root audio 253, 0 ago 13 18:15 /dev/rtc0 me@arrakis:~$ ls -l /dev/hpet crw-rw---- 1 root audio 10, 228 ago 13 18:15 /dev/hpet That should be ok I think. > I set up Qtractor to use the default timer as the MIDI queue timer, so it > should be TSC. MIDI is independent from audio, but I suspect it's better, if > audio and MIDI are using the same timer. Not using MIDI... I am using a audio workstation to record (so I need low latencies with possibly no xruns), plus a playback audio server for my hifi system, with a an external USB2 DAC (here I need a clear audio signal with a "precise" clock timing...) > IIRC the keyboard driver was added, since some people experienced the > keyboard being unresponsive, but I might be mistaken. Ah, yes this seems a good explaination... > > Also, consider now I am using rtirq-init version 20150216-2... There is a > > newer (better) version I should use with a sysv-init (NO systemd) machine? > > I don't know. In the paste some versions of rtirq didn't fit to some kernel > versions. There were mismatches with the names in the RTIRQ_NAME_LIST, when > using a brand-new kernel with some of that time current rtirq scripts years > back, when the rtirq scripts were written for previous kernel releases of > that time. Thanks again. I have found this new release: https://www.rncbc.org/drupal/node/1979 I have manually extracted and installed the sysv-init script on my system (4.6.0-0.bpo.1-rt-amd64) and it seems to work fine. Finally I have simply set: RTIRQ_NAME_LIST="rtc0 usb1" and priorities are as expected. Thank you a lot. Regards -- al3xu5 Say NO to copyright, patents, trademarks and any industrial design restrictions. ________________________________________________________________________________ Public GPG/PGP key block ID: 4096 bit RSA key 69C5977BF94CFE23 Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23

5 years, 3 months

Re: [LAU] rtirq configuration with external USB DAC?

by al3xu5 / dotcommon

Il giorno martedì 13/08/2019 16:22:13 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> ha scritto: > >RTIRQ_NAME_LIST="rtc ehci_hcd snd_usb i8042" > > Hi, > > the list should either be > > RTIRQ_NAME_LIST="usb" > > or in case it should make a difference > > RTIRQ_NAME_LIST="usb1" > > assuming the port where the USB audio device is attached should be USB1. > It could make a difference, but not necessarily does make a difference. Ok. I will try both. > The timer "rtc" and the keyboard "i8042" should be removed from the > list, years back they where added, but today this isn't done anymore. Indeed rtc and i8042 are in this (old) "rtirq usage" post by rncbc: https://www.rncbc.org/drupal/node/107 Can you tell me why they shoud be removed now, please? Also, consider now I am using rtirq-init version 20150216-2... There is a newer (better) version I should use with a sysv-init (NO systemd) machine? Thanks again Regards -- al3xu5 Say NO to copyright, patents, trademarks and any industrial design restrictions. ________________________________________________________________________________ Public GPG/PGP key block ID: 4096 bit RSA key 69C5977BF94CFE23 Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23

5 years, 3 months

Re: [LAU] [off-list ] rtirq configuration with external USB DAC?

by al3xu5 / dotcommon

Il giorno lunedì 05/08/2019 12:05:21 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> ha scritto: > On Mon, 5 Aug 2019 11:37:21 +0200, al3xu5 / dotcommon wrote: > >I am in doubt as to how the rtirq configuration should be at best, in > >particular the entries: > > > >RTIRQ_NAME_LIST= > >RTIRQ_NON_THREADED= > >RTIRQ_HIGH_LIST= > > Hi, > > it depends, just "usb" might not be enough, you might make the used usb > port head of the list. Those are the settings I'm using: > > $ grep -eNAME_LIST -eNON_THREADED -eHIGH_LIST /etc/rtirq.conf | grep -v > \# RTIRQ_NAME_LIST="usb snd_hdsp snd_ice1" > RTIRQ_NON_THREADED="rtc snd" Hi Ralf Thank you for the advices, and sorry for the delay in replying. Having: ~~~ $ cat /proc/asound/modules 0 snd_usb_audio ~~~ ~~~ $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 ... 23: 15168 19473 344933 10188 IO-APIC 23-fasteoi ehci_hcd:usb1 ... ~~~ (where is my external USB2 DAC attached) I am using: RTIRQ_NAME_LIST="rtc ehci_hcd snd_usb i8042" which seems to be working. Regards -- al3xu5 Say NO to copyright, patents, trademarks and any industrial design restrictions. ________________________________________________________________________________ Public GPG/PGP key block ID: 4096 bit RSA key 69C5977BF94CFE23 Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23

5 years, 3 months

"A complete guide of and debunking of audio on Linux, ALSA and Pulse"

by Max

I stumbled upon this post on Reddit, might be of interest here: "A complete guide of and debunking of audio on Linux, ALSA and Pulse" https://www.reddit.com/r/linux/comments/coi4dt/a_complete_guide_of_and_debu…

5 years, 3 months

What does period_size mean in dmix parameters?

by crocket

Is it bytes per period or frames per period? https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html says it's bytes per period. aplay --dump-hw-param -D dmix /path/to/wav_file says it's frames per period. Which one is right?

5 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-user August 2019