Linux-audio-dev February 2015

linux-audio-dev@lists.linuxaudio.org

12 participants
12 discussions

by Tim Goetze

http://quitte.de/dsp/caps.html The latest release of the caps audio plugin suite contains a number of bug fixes and improvements as well as changes intended to make it more suitable for low-power systems. http://quitte.de/dsp/caps.html#CHANGES Most notably, support for a variety of little-used features has been dropped, reducing the binary size by roughly a third. There's also a new plugin implementing simplistic linear emulation of several guitar amplifier loudspeaker cabinets with reduced computational complexity: http://quitte.de/dsp/caps.html#CabinetIII The compressor plugins now report current gain reduction: http://quitte.de/dsp/caps.html#Compress http://quitte.de/dsp/caps_0.9.24.tar.bz2 Cheers, Tim

5 years, 1 month

OPEN CONTROL ARCHITECTURE

by Len Ovens

Has anyone looked at OCA as a method of service discovery/remote control for Linux audio? This is supposed to end up as another aes* "real soon now" but the current spec is available at: http://ocaalliance.com/technology/specifications/ For the downloading and there are some products out there that use it now. (well at least one anyway) Some background: I have been looking at AoIP and reading what I could. AES67 has the biggest complaint that it has poor service discovery (well none actually). I have been reading product manuals for various AoIP formats and what I have found is that some of the other ones do not have very good/any discovery either. I do not know if this is the protocols fault of the product but the setup for a Ravenna AoIP DAC/ADC box to a Ravenna PCIe card requires the user to know what the IP for both units are and then log in to both units via HTTP(s) to set them up in some sort of static configuration. This sounds no better than raw AES67. (Some other AoIP things might be better) So along the way I stumbled on OCA. This is not another OSC, though it could do that job too. I will put this in terms of Linux/ALSA/Jack because that is what I know. As an example assume two linux boxes, one with an Audio IF and another with audio SW, A and B. Box A is headless, boots up with jack running. Box B has no Audio IF because it is new and only has PCIe sockets, other than that has everything a normal Desktop would have as a DAW. The way OSC works would be for the user on Box B to open a window something like the "Connections" window on qjackctl. It would show all local connections the same as Qjackctl does now... System on both sides that can be expanded, it would also show "Box A"... but when clicked to expand, a box would pop up showing what lines are local there on Box A's Jack. There would be a dropdown/whatever that allowed the user to set the number of lines to set up between the boxes in which direction. SO the user does that. Now the user can connect whatever Box A internals to these I/O lines and the BOX A on the local window will now expand to show those lines which will be labeled the same as on BOX A. All of this in one app. But there would be more. Next we want to set the actual ALSA device levels, so we open an ALSA mixer, one of the devices will be Box A's ALSA card and the levels can be set. Now because Box A really isn't doing too much, we want to run a soft synth on there as well, So long as the OCA server already understands tha SW, it would already show as a capablility of that box. The I/Os would show up as if they were already available on the jack graph, but the app would not yet be running (because there may be a number of different ones available) but as soon as one of those connects was connected, the OCA server would start that synth and make the connections when it was started (MIDI and audio). Clicking on any of that synths i/o's would give the user a control interface with that synth. This to me is the way remote discovery/control should work. Does that make sense? Does this look like I have read the OCA spec right? Does this sound worth while? I have only scratched the surface to give some idea what we are talking about. OCA would not replace MIDI or OSC, but it could find them and connect them from one box to another. Some of the kinds of controls OCA has might be better for remote control of mixer kinds of things like faders, sends, eq and such because these things are defined already and where not, any other controls are discoverable/query-able and could be set up on the fly in SW (not so much for HW). This is the same thing that already happens with ALSA controls and ALSA mixer. Anyway, I am going to try making a server and client based on this spec. -- Len Ovens www.ovenwerks.net

8 years, 9 months

Fw: Re: [maybe OT] question regarding the FIL equalizer

by Fons Adriaensen

Date: Thu, 26 Feb 2015 22:04:39 +0000 From: Fons Adriaensen <fons(a)linuxaudio.org> To: Cedric Roux <sed(a)free.fr> On Wed, Feb 25, 2015 at 11:46:37PM +0100, Cedric Roux wrote: > can someone explain to me what this bandwidth computation means? There is nothing magical about it, it's just a pragmatic approximation that results in the 3dB BW (for high + or - gain) being expressed in octaves. Expressing the BW in a logarithmic unit (such as octaves) make sense because the magnitude response of a second order parametric is symmetric on a log(f) scale but not on a linear one. An absolute value in Hz or even a relative one (the same divided by center frequency) is informative only for small BW, where the linear distance to the -3dB points left and right would be more or less equal. For large BW values (as often used in sound engineering) this is no longer true. For example for a center frequency of 1 kHz and two octaves BW the -3dB points are at 500 Hz and 2 kHz. For four octaves that would be 250 Hz and 4 kHz, giving a -3dB BW in Hz that is larger than twice the center frequency, which is somewhat counter-intuitive. The 'mathematical' way to define the BW of an second order allpass would be at the +/- 90 degree phase points. This also corresponds to the -3 dB points for an infinite notch, as used by M & R. But keeping this value fixed in a parametric results in curves that are not even symmetric for + and - gains. The 'bumps' would be much wider than the 'notches'. The sqrt (gain) factor restores this symmetry. But using this means that there is no longer any simple relation to what looks like bandwidth on a frequency response plot and the actual 'mathematical' value. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ----- End forwarded message ----- -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

8 years, 9 months

Detecting 'ready' status of JACK-aware applications in Python

by Jonathan E. Brickman

What are good ways to pull a list of JACK ports in python and detect their readiness to accept connections? And/or, is there a better way to detect 'ready' status of JACK-aware applications? -- Jonathan E. Brickman | jeb(a)ponderworthy.com | (785)233-9977 Ponderworthy | http://ponderworthy.com Music of compassion; fire, and life!!!

8 years, 9 months

[maybe OT] question regarding the FIL equalizer

by Cedric Roux

Hi LAD, I have a technical question regarding the FIL equalizer (by Fons Adriaensen). The code uses Mitra-Regalia lattice filter (as described in [1]). After reordering things here and there I see it's indeed the case (surprise!). [1] might be hard to get, but there is [2] with a lot of details too, especially for bandwidth. The only remaining point that I don't get is the bandwidth manipulations. [1] uses for its parameter 'a' ('_s2' in FIL) the formula: a = (1 - tan(Omega/2)) / (1 + tan(Omega/2)) 'Omega' being I don't really know what (-3dB notch bandwidth for a gain of 0 maybe, if I read the paper correctly). FIL uses bandwith expressed in octave and does: _s2 = (1-b)/(1+b) with: b = bandwidth * 7 * (f0/fs) / sqrt(gain) ('f0' is the center frequency of the equalizer, 'fs' is the sampling rate) Reading [2] we see the factor 'sqrt(gain)' ('gain' is 'K') that we find in the FIL's formula (specifically the formula for k2 at page 13, after equation (17)). But the "bandwidth * 7 * (f0/fs)" remains a total mistery to me. It seems to be 'gamma' as found in [2], but 'gamma' is way more complicated than what we see in FIL's code. So the questions are: - can someone explain to me what this bandwidth computation means? - how it is derived starting from a bandwidth expressed in octave? - And if we use the notations of [1] and [2] how do we relate it to Omega or the various versions found in [2]? (which one is it by the way? I thought it was the "at the bandedge frequencies the gain is 'gain/2 dB'" one but it's not the case) (I wrote a little program to plot things and as far as my program is correct bandedge frequencies don't have a gain of 'gain/2 dB') Regards, Cédric. [1] P. A. Regalia and S. K. Mitra, “Tunable Digital Frequency Response Equalization Filters,” IEEE Trans. Acoust., Speech, Signal Process., vol. ASSP-35 (1987 Jan.). [2] http://www.musicdsp.org/files/EQ-Coefficients.pdf

8 years, 9 months

ams-lv2 1.1.0

by Aurélien Leblond

Hello all, The version 1.1.0 of ams-lv2 is now available: The two main "features" of this version are: - Ported tons of additional plugins from AMS (VCEnv & VCEnv II, Multiphase LFO, VC Organ, etc.) - Ported the changes from version AMS 2.1.1 (Bit Grinder, Hysteresis, the bug fixes, etc.) In addition, this release sees a lot of bug fixes or optimization. As a reminder, ams-lv2 are plugins to create modular synthesizers ported from Alsa Modular Synth. Here is a demo of an older version of these plugins. http://www.youtube.com/watch?v=LWfF71NerkQ ams-lv2 1.1.0 can be downloaded here: https://github.com/blablack/ams-lv2/releases/tag/v1.1.0 enjoy :) Aurélien

8 years, 9 months

Re: [LAD] [LAU] Graphic designer wanted

by Hermann Meyer

Thanks, I've created a job-page on the github job-board now. Sounds like it be a good place. regards hermann Am 13.02.2015 um 12:44 schrieb Cillian de Róiste: > Hi, > > You could try posting the details on: > https://github.com/opensourcedesign/job-board or asking on freenode > #opensourcedesign > > Good luck! > Cillian > > 2015-02-12 7:13 GMT+01:00 Hermann Meyer <brummer-(a)web.de>: >> Hi >> >> The topic say’s it all, any Graphic designer around here, who like to create >> a new, overall design for the guitarix project? >> If so, please contact me. >> >> regards >> hermann >> >> _______________________________________________ >> Linux-audio-user mailing list >> Linux-audio-user(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-user > >

8 years, 9 months

Graphic designer wanted

by Hermann Meyer

Hi The topic say’s it all, any Graphic designer around here, who like to create a new, overall design for the guitarix project? If so, please contact me. regards hermann

8 years, 9 months

Problems with time-scaling on records

by Álvaro Canelo Noriega

Hi! My name's Álvaro, from Barcelona [it's my first post to this list, so I say hello :) ]. I'm dealing with some issues with time-scaling and I'm a little bit lost trying to find the problem. I'm trying to record an analog audio input using *arecord*, in order to do some fingerprinting (features extraction). The problem is that after every reboot of the recording machine, the record has a different time scale so, as the fingerprint algorithm works with the relative position of energy peaks for different frequencies and the time them happen, the algorithm sometimes works, but sometimes fails. Could you give me any guidance to know where to search a possible solution for the time-scaling issue? Thank you very much in advance! Álvaro --- Forza saluti a tutti bacioni auguri in boca di lupo arrivederci ea presto pino

8 years, 10 months

a LAD survey (I need you !)

by e-rouge

Hello guys, I've followed this community for a while now and this is my contribution : a survey about LAD. *Why ?* I've made this survey to get a snapshot of what LAD community is, and to help understand how it works. This community has always worked in an informal way with ups and downs, and I thought it would be really useful to look at it with objectivity. *Who ?* It is open to any contributors of any Linux Audio Sofwares. *Who/What's for**?* This study aims to stay within LAD community and to provide very practical information. It does not intend to be part of a essay or any academic work. Actually its only purpose will be to provide a solid ground for further discussion about LAD's future. I've already started to gather qualitative data (as some of you know) an, while you answer this, I'll collect some more data about the projects themselves. Once all put together, we should get a very precise overview of what this community actually is. *How ?* *The survey itself takes around 30minuts to complete and they will be anonymized *before any publication (if you wonder why I ask for your name : it's to help me to build a projects-interactions graph as well as few other things). *When ?* Hopefully, I hope to get most answers within 2 or 3 months. After that it'll take a couple of weeks to analyze the data and write something about them. I'll keep you informed. . *Where ?* *Here's the link : * http://tumulte.me/lime/index.php/survey/index/sid/174631/token/bcdqg4tww7n6… I've made my best to think about the most relevant questions and possible answers, but if you thinks something is missing, wrong or whatever please contact me Thanks in advance, Etienne/Tumulte

8 years, 10 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev February 2015