Linux-audio-user April 2016

linux-audio-user@lists.linuxaudio.org

71 participants
54 discussions

by jonetsu＠teksavvy.com

Hello, This is a soft piece recorded in Ardour. The mix on the master bus sits at around -15dB. That's how it is recorded and it sounds currently nice like this. There's room, nothing is pushed forward in the ears of the listener. After exporting, it sounds like heavy metal, so to speak. So much that there's distortion in the same monitors, at the same volume, that were playing the piece so nicely a minute ago. No more room, no more breathing. Smack. I used jack_capture instead. That kept it as is. 1) Is -15dB on the master bus something completly silly ? 2) If so, how to remediate the currnt recording ? 3) The export stats are: Normalization gain: -14.06 dB Integrated loudness: -12.5 LUFS Loudness Range: 7.6 LU What does it mean when taking into account that the listener will play other tunes and then this one ? Are the numbers telling anything about how it will fit in between other tunes ? The current jack_capture export is at: https://soundcloud.com/nominal6/c2016-05 Cheers.

8 years, 8 months

Re: [LAU] metering, mixing levels was Re: Ardour: exporting woes

by Chris Caudle

On Tue, April 12, 2016 3:58 am, Thorsten Wilms wrote: > Now if only broadcasters and streamers could agree > on a single reference level for music ... Not sure if you saw this reference I posted previously: The AES has published a recommendation for streaming normalization which could, if adopted, help reduce the desire to make recordings seem louder by extreme compression (the recommendation would result in such recordings having gain reduced while streaming). http://www.aes.org/technical/documents/AESTD1004_1_15_10.pdf EBU in Europe and ATSC in the United States have published recommendations for digital television broadcast. I find that HDTV broadcasts in the states are pretty good, at least on the Dolby Digital stream. The two channel down mix stream is hit or miss, often the two channel mix is anywhere from 3dB to 6dB louder. TC put together a list of references to some of the relevant standards: http://www.tcelectronic.com/loudness/broadcast-standards/ -- Chris Caudle

8 years, 8 months

MPD and JACK

by Raffaele Morelli

Hi there, anyone having troubles with MPD playing happily through jack? I have jack up and running with a loopback device all the time and got MPD working but it stopped working, ie. no sound but the player is going on with no errors in mpd.log This is my audio conf snippet from mpd.conf, just added device parameter for my loopback device: audio_output { type "alsa" name "My ALSA Device" device "hw:1,0" # optional } Any hints? -- «My mama said to get things done You'd better not mess with Major Tom»

8 years, 8 months

Commercial synthesizer for Linux released: Monique

by Monoplugs | Thomas Arndt

Hallo Linux Audio User, a few days ago Monoplugs has released Monique - a unique monophonic synthesizer made for bass and lead sounds. Available as standalone and native Linux VST 32 & 64 bit. You can test this synthesizer for free, but note, it is a commercial project. More you can find on the Monique website: http://Monique.Monoplugs.com Here the trailer video: https://www.youtube.com/watch?v=yPsa-3aAFms More videos and tutorials you can find here: http://magazine.monoplugs.com/category/monique-synthesizer/ If you like you can join the discussion on the LinuxMusicians forum: https://linuxmusicians.com/viewtopic.php?f=24&t=15558 Or on KVR forum: http://www.kvraudio.com/forum/viewtopic.php?t=459681 Or gearslutz forum: https://www.gearslutz.com/board/new-product-alert/1077291-monoplugs-release… Sincerly, Thomas Arndt Monoplugs

8 years, 8 months

A new approach

by Will Godfrey

As part of our quest for the best possible sound we are planning an enhancement that passes bits through a grading process (the well known 'Enharmonic Bit Comparator' - version 33)* thus ensuring that any bit asymmetry is removed. In laymans terms, this has a heater to agitate the bits, then an amplifier to highlight the errors, and rectifiers to remove them. Symmetrical bits produce significantly less quantum noise so reduce the possibility of alignment boundary collisions, giving a much warmer, smoother presentation. Such advanced technology has a cost of course, so to gain the greatest benefit from this process it is necessary for Yoshimi to now use only audiophile grade bits, rather than the standard ones and zeros present in ordinary programs. Bit quality is heavily dependent on the source so we recently did a line-by-line review of the code, feeding it to our Delta Orthogonal Grader. Finally, there is the open-source BitShine engine (BS). This 'clarifies' individual zeroes and ones passing through it, making them sharper, so should give greater precision when passed on to the DA converter. This is available under the 'Multi User Grant' license. As it appears to be GPL compatible we are looking at it for possible inclusion. I should point out that there is only a narrow window for discussion as we expect to be committed by lunch time today. * EBC33 - Mullard -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

8 years, 8 months

Recorded in Linux: c2016-11a : test

by jonetsu＠teksavvy.com

Greetings, This is an improv-based track. Still fighting with trying to get decent levels and dynamics in mixing. This one can be basically acoustic guitar over a synth bass and drums. With some extras characterized as loops. Whoa. Am listening to the soundcloud upload now. It is incredible how much processing goes behind the scenes. The soundcloud version sounds much more "upfront" (for better and/or for worse) than what I have locally here. The lineup is: as always, Shiraki acoustic guitar. Bass is u-he ACE init patch. Played drums consists of a bass drum and a snare samples. That would be basically it and captures the spirit of the improv. But then, other elements were added as decorations. Amongst these there is a u-he Zebra patches from The Unfinished and Colin Neff, a u-he Bazille patch, and loops from Perimeter Sound, Mode Audio and Earth Moments. All recorded in the Mixbus variation of Ardour with good help of Robin Gareus x42 meter plugins. Again, the struggle is to get decent dynamics and mixing levels that brings life to a piece with confidence that it will not overload a listener's audio system or require drastic change from the previous pieces that were listened to, taking into account genres. https://soundcloud.com/nominal6/c2016-11a Cheers.

8 years, 8 months

New AV Linux Kernel Repository now public!

by Glen MacArthur

Hi, Just passing along that we are making our AV Linux RT kernel repository public. Current users of AV Linux 2016 have this set up by default, it may be of interest to users of Debian Jessie and up and perhaps Ubuntu users although we haven't tested Ubuntu specifically so feedback is needed. Full story here: http://bandshed.net/forum/index.php?topic=3719.0 Thanks! Glen

8 years, 8 months

Re: [LAU] Linux-audio-user Digest, Vol 110, Issue 9

by Stéphane Letz

> > Message: 13 > Date: Thu, 7 Apr 2016 09:24:14 +0200 > From: Alexandre DENIS <contact(a)alexandredenis.net> > To: linux-audio-user(a)lists.linuxaudio.org > Subject: Re: [LAU] multiJACK patch management: the first glimmerings > Message-ID: <20160407092414.1c634add(a)pointvirgule.bordeaux.inria.fr> > Content-Type: text/plain; charset="utf-8" > > On Wed, 6 Apr 2016 11:41:25 +0200 > St?phane Letz <letz(a)grame.fr> wrote: > >> jackd2 has a ? loopback ? driver implemented since day 1 (OK maybe >> day 2?.) >> >> - the code is in common/JackLoopbackDriver.cpp, h >> >> - it can be activated using the -L parameter like : jackd -L 4 -d >> also xxxxxx to add 4 loopback ports. > > I never noticed it, it is not mentioned in the man! Was a bit experimental at that time, test and patch welcome. > > With a quick look at the code, it looks like it does a direct copy from > its input to its output, without buffering nor decoupling. How can it > help to cut the dependency graph so as to spread DSP load on multiple > cores? Or am I missing something? > > -a. This component is a *driver* that is going to be run a the beginning to each cycle: - inputs of the driver (= outputs from clients connected to it) from the *previous* cycle will indeed be copied to the outputs of the driver (= inputs from clients connected to it) - you should try... Stéphane

8 years, 8 months

multiJACK patch management: the first glimmerings of success

by Jonathan E. Brickman

For those who may be interested, I am seeing the first small glimmering of what looks like real success, in running multiple JACK servers on one box for the purpose of distributing DSP load. I can now reliably have two netjack1 slaves connect to one netjack1 master, the master running ALSA to hardware, all within one Linux box under one kernel and one filesystem. The way that this works is "containerization" or "sandboxing", which can give an IP to anything ranging from one running binary to a large collection. I started the current effort using Docker containerization, but its standard setups require a lot of filesystem recreation, each Docker container has an entire working OS filesystem apart from the kernel; but during the studies for Docker, I blundered into something else called firejail, and firejail appears to be just what the doctor ordered, it seems to do just about everything while using the existing filesystem, and one can very easily turn off the features one doesn't need. To cut to the chase, after boot and system prep, first one creates an IP bridge: sudo brctl addbr br0 sudo ifconfig br0 10.99.99.1/24 and then starts JACK in the sandboxes: # The master hardware sandbox is named MASTER, the QJackCTL profile is named MASTER, # the JACK server is named MASTER. nohup firejail --name=MASTER --noprofile --net=br0 --ip=10.99.99.10 \ /usr/bin/jackd -n MASTER -m -dalsa -r48000 -p256 -n2 -Xseq -D -Chw:NVidia -Phw:NVidia \ > ~/LOGS/jack-master.log & # The SRO hardware sandbox is named SRO, the QJackCTL profile for it is named SRO, # the JACK server is named SRO. nohup firejail --name=SRO --noprofile --net=br0 --ip=10.99.99.15 \ /usr/bin/jackd -n SRO -dnetone \ > ~/LOGS/jack-sro.log & # Ditto for STRINGS. nohup firejail --name=STRINGS --noprofile --net=br0 --ip=10.99.99.20 \ /usr/bin/jackd -n STRINGS -dnetone \ > ~/LOGS/jack-strings.log & And then connects the JACK servers, by adding jack_netsource processes into the existing MASTER sandbox: #!/bin/bash # SRO nohup firejail --join=MASTER jack_netsource -s MASTER -H 10.99.99.15 > ~/LOGS/netsource-sro.log & # STRINGS nohup firejail --join=MASTER jack_netsource -s MASTER -H 10.99.99.20 > ~/LOGS/netsource-strings.log & I have not tested further yet, no clients -- am working on something closer to production now -- but this is looking very good, the connections are reported successful, zero xruns, and on this prototyping box -- 2.6GHz AMD quad, ten-plus years old -- 0.8% DSP in use on all three JACK servers and very low memory usage. This is considerably better than I had hoped. The sandboxed binaries above, cannot reach outside the one box as written above, but the excellent and very responsive developer of Firejail has provided a method <https://github.com/netblue30/firejail/issues/372>. As a result this could all be done box-independently -- for instance, if one's "monolith is the building" (going to have to remember that, Patrick), one could have all indicated motherboards NFS or SMB to one file server, and then use a central control GUI machine to run all firejails on whichever hardware was proven most appropriate, and testing could become much easier. Along the way I also found 'xpra' likely to be a very good way to setup such a central control, am going to test that as a side project. I tried using netjack2 first, but ran into mystery behavior, xruns started piling huge when the second slave connected. So I went with netjack1, especially because Patrick Shirkey already proved the above paradigm in multibox mode using netjack1. I am currently using netjack1 under jackd2, but will change to netjack under jackd1 if a reason to do so appears. I am now working on a working dual-JACK prototype, in a near-production design, as a next step towards a generally transportable MultiJACK Patch Management methodology and the next big build of my Box of No Return :-) Cheers, and thanks everyone!!!! -- Jonathan E. Brickman jeb(a)ponderworthy.com (785)233-9977 Hear us at http://ponderworthy.com -- CDs and MP3 now available! <http://ponderworthy.com/ad-astra/ad-astra.html> Music of compassion; fire, and life!!!

8 years, 8 months

Re: [LAU] multiJACK patch management: the first glimmerings

by Stéphane Letz

> > Message: 11 > Date: Wed, 6 Apr 2016 00:26:32 +0200 > From: Alexandre DENIS <contact(a)alexandredenis.net> > To: linux-audio-user(a)lists.linuxaudio.org > Subject: Re: [LAU] multiJACK patch management: the first glimmerings > of success > Message-ID: <20160406002632.19d7ee47@cocalight> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, 5 Apr 2016 22:27:46 +0200 > J?rn Nettingsmeier <nettings(a)stackingdwarves.net> wrote: > >> I have never used a graph as complex as Jonathan's, but I don't see >> how adding virtual machine and networking overhead could improve >> throughput when JACK2 should already parallelize everything that can >> be parallelized... Wouldn't the time be better spent to analyze >> JACK2's scheduling behaviour and catch bugs if there are any? > > Hi, > > Jack2 cannot parallelize processing if the graph is a pipeline: since > every stage depends on the data from previous stage, they must be run > in sequence. > > However, a pipeline may be parallelized if you trade parallelism > against latency. You can run each stage in parallel if they process > data from different periods. Jack2 doesn't do that by itself since it > would introduce uncontrolled latency. > > When you run multiple jackd and link them with netjack, you introduce > latency in the pipeline, which explains why you can have more > parallelism. However, it looks completely overkill to me and > introduces lots of overhead. > > I think it should be doable to write a simple client that connects as > two unrelated clients to jack, and feeds its outputs with its inputs > with one period of delay. It will make jack2 run the client connected > to its inputs and to its outputs in parallel, since jackd doesn't see > it as a dependency; but the latency of one period is unavoidable, since > we cannot predict whether jackd will invoke first the callback for the > inputs or for the output (or maybe at the same time on different > cores). Such a client should be no more than a few hundred lines of > code. > > -a. jackd2 has a « loopback » driver implemented since day 1 (OK maybe day 2….) - the code is in common/JackLoopbackDriver.cpp, h - it can be activated using the -L parameter like : jackd -L 4 -d also xxxxxx to add 4 loopback ports. Stéphane

8 years, 8 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 April 2016