Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Len Ovens

Focusrite's RedNet series of interfaces uses Dante as the transport protocol. Going to the Dante home page I find that an audio driver (mac/win) is available for $30 or so (there is apparently a linux version available from another party). Yet Focusrite sells a RedNet PCIe card for around $800... one hopes it has more on it than an ethernet port :) That looks like a sound card to the computer. This card does not look like it has a special plug on it (like the locking ones some of the snake/mixing boxes have). I am wondering what other processing might be happening on this card to make it worth Focusrite's effort to produce. Routing to be sure, but the Interface boxes all have that anyway. DSP? Effects? maybe, but not useful on a Linux box I am sure. I realize a big part of the cost is scale (lack of scale in this case), but can't help but think that the money would be better spent on a better mother board. For example moving from an i5/7 to a Xeon based board. Reading more about the RedNet PCIe card. It is 4 lane, but the recomend installing in an 8 lane slot. They also recomend using a GB switch to which both the PCIe audio card as well as the MB native Ethernet port is connected. They are suggesting that all the audio will go through PCIe AI card and that control will go through the native enet port. This all may be to do with 128 channels at 192khz at 3ms. The native enet port has the dante driver on it too. I am not suggesting that the Linux world embrace Dante as a protocol so much as learning from its implementation. I am not sure that building for 192k is the way to go though. Some numbers... if they are talking 192k with a 32sample buffer (like jack with 16/2?) it would seem there is a lot of extra latency built in as at 48k and 16/2 the raw latency from card to jack is only .6ms and at 192k it would be less than .2ms... .3ish for return trip. So the network and ADC together take a lot longer. Considering my USB IF at 48k has an ADC time of ~.5ms, most of that is network. I am looking forward to testing Fons' n2jbridge jack backend. I will not be using 192k however. I generally use 48k, but may try 96k to test differences in latency. My own low level protocol is way down the road, if it ever happens. -- Len Ovens www.ovenwerks.net

11 years, 2 months

using libsndfile to write signed short

by Joël Krähemann

Does someone know about writing WAV using libsndfile? My file becomes 174M big as using sf_writef_short() within 8s please take a look at http://ags.sf.net

11 years, 3 months

Writing to an eventfd from a realtime thread

by William Light

Hey everybody, I've got this audio app I'm writing which uses message passing to communicate between threads (similar to the actor model). A message channel consists of a ring-buffer for the actual message storage, and then an eventfd so that a thread can block on its channel (or, importantly, several). At the moment, when the audio thread (the JACK callback) needs to send a message over a channel to another thread, it follows the common codepath of appending the message to the channel's ring-buffer and then write()ing to the eventfd. I suspect this is not real-time safe, but is it something I should lose sleep over? -w

11 years, 3 months

QMidiArp-0.5.2 released

by Frank Kober

Hi, QMidiArp 0.5.2 has just seen the light of the day. It brings mainly two improvements. One is a comeback, that of tempo changes on the fly, and that now includes also tempo changes of a potential Jack Transport master. Also the Jack Transport starting position is finally taken into account, so that QMidiArp should be in sync also when starting the transport master not at zero. The second one is Non Session Manager support, mainly thanks to the work done by Roy Vegard Ovesen! Note that for compiling in NSM support you will now need liblo as dependency. Enjoy, and enjoy LAC in Graz this year Frank ________________________________ QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO. Everything is on http://qmidiarp.sourceforge.net qmidiarp-0.5.2 (2013-05-09) New Features o Tempo changes are again possible while running, both manually or by a Jack Transport Master o Jack Transport position is now taken into account when starting, QMidiArp used to start always at zero o Muting and sequencer parameter changes can be deferred to pattern end using a new toolbutton o Modules in the Global Storage window have mute/defer buttons o Global Storage location switches can be set to affect only the pattern o Non Session Manager support with "switch" capability (thanks to Roy Vegard Ovesen) General Changes o NSM support requires liblo development headers (liblo-dev package)

11 years, 3 months

[ANN] Super Announcement - All MOD software for your PC

by Gianfranco Ceccolini

Hello Linux Audio Users and Developers In less than an our the MOD Duo Kickstarter campaign will go live and so it is with great pleasure that the MOD Team makes the announcement of the desktop versions for our entire software suite. Some of this software has already been announced in the past but, as part of our Kickstarter campaign, we put the necessary effort to have them running in a regular Linux environment and not just inside the MOD. All instructions in Github were also updated in order to yield working elements when followed. Most of this software has been under development for almost two years and their history is related to the development of the MOD itself. Being so, they carry some differences in workflow when compared to other LV2 programs and our current effort is being put on correcting those differences. The softwares are: MOD Client - run your LV2 plugins using the MOD interface. https://github.com/portalmod/mod-client —————————————————————————————————————————— MOD SDK - plugin interface creator Use this program to create the HTML interface required by the MOD Client. If you don’t create an interface the plugins still work, but their icons will be a tuna fish can with just the ON/OFF button. When you click on the gear symbol on the upper right side of the icon you have access to the Plugin Settings Screen in which all parameters are visible. The MOD SDK is Python based and can be installed by typing “pip install modsdk” As the MOD Client, it runs on your browser and requires a mod-workspace folder (or link) in which you place your LV2 bundles. Just run “modsdk" in your terminal and point your browser to localhost:9000 There is also post on our blog about the SDK: http://portalmod.com/blog/2014/09/the-mod-sdk —————————————————————————————————————————— LV2BM - tool for analyzing and benchmarking LV2 plugins Allows to select which URIs to test Uses minimum, maximum and default control values to run the plugins Uses several controls combinations in the full test mode The output shows the JACK load percent —————————————————————————————————————————— Plugins - CAPS-LV2 LV2 port of the CAPS suite of LADSPA plugins. - TAP-LV2 - LV2 port of the TAP suite of LADSPA plugins. - Pitch shifters - http://github.com/portalmod/mod-pitchshifter Capo - up to 7 semitones up pitch shifting SuperCapo - up to 24 semitones up pitch shifting Drop - up to 12 semitones down pitch shifting SuperWhammy - continuous pitch shifting from -12 to 24 semitones Harmonizer - scale interval generator - Utilities - https://github.com/portalmod/mod-utilities Switchbox - A/B box for audio signal routing SwitchTrigger - 4 excluding channel selector ToggleSwitch - 4 non-excluding channel selector Gain (mono and stereo) Filters (LP, HP and BP) - 1st, 2nd and 3rd order Two way mono crossover - 1st, 2nd and 3rd order Three way mono crossover - 1st, 2nd and 3rd order - Distortions - mathematical simulations of classic distortion circuits BigMuff DS-1 Muff Fuzz - SopoperLooper LV2 simplified port of the SooperLooper. All plugins from our repository have the HTML MOD GUI included. In our Github repository - www.github.com/portalmod - we also have plugins that were forked from the original repositories. One of our aims is to trigger a dialogue with the developers, deprecate our forks and add the MOD interface to the original plugins but that depends on the developers and creators and shall be discussed in a one-to-one basis. Wish you all the best Kind regards Gianfranco The MOD Team

11 years, 3 months

[ANN] Qtractor 0.6.3 - The Armed Hadron beta release!

by Rui Nuno Capela

Ah, the equinox... Twice a year a cherished planetary alignment checks in on schedule, once again. The little rock gets another round from its warmy solar furnax, from which were forged. The pale blue dot gets yet another round and to no surprise, another tinier dot gets here around: Qtractor 0.6.3 (armed hadron beta) is now released! Release highlights: * Revamped mixer (un)dockable panels (NEW) * Plugin preset selection sub-menu (NEW) * LV2 Time position/transport event support (NEW) * Constrained plugin multi-instantiation (FIX) * Automation curve node resolution (FIX) Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt4 framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. nb. Despite the old Qt4 stance, but still recommended, Qtractor does build, runs and does it all on Qt5 for quite some time now. However, the former recommendation prevails as the despicable LV2 plugin GUI X11/embedding support through libSUIL just does NOT work on modern Qt5. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: http://sourceforge.net/projects/qtractor/files - source tarball: http://download.sourceforge.net/qtractor/qtractor-0.6.3.tar.gz - source package (openSUSE 13.1): http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.sr… - binary packages (openSUSE 13.1): http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.i5… http://download.sourceforge.net/qtractor/qtractor-0.6.3-13.rncbc.suse131.x8… - quick start guide & user manual (still outdated, see wiki): http://download.sourceforge.net/qtractor/qtractor-0.5.x-user-manual.pdf - wiki (help wanted!): http://sourceforge.net/p/qtractor/wiki/ Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Make the mouse-wheel to scroll the plugin list views, when not hovering a direct-access parameter slider. - Mixer widget gets (un)dockable Inputs and Outputs panels, also with their respective title captions. - Plugin instantiation is now constrained as much to prevent any audio channel output overriding. - Existing plugin presets may now be selected right(-click) from plugin list context-menu (ticket by Harry van Haaren, thanks). - So-called "painting" over multiple selected event values, while on the MIDI clip editor view pane below the main piano-roll (eg. note velocities, controller values, etc.) is now split into two similar painting modes, whether the sub-menu Edit/Select Mode/Edit Draw is set on (free-hand) or off (linear). - Drag-and-copy of plug-in instances across tracks or buses (ie. cloning) now also copies the direct access parameter setting (ticket by Holger Marzen, thanks). - File/Save As... now prompts and suggests an incremental backup name for existing sessions files. - Zooming in/out increment is now augmented by whether shift /ctrl keyboard modifiers are set (on a ticket request by Holger Marzen, thanks). - LV2 Time position event messages for plugin atom ports that support it is now being implemented. - Attempt to break extremely long audio file peak generation on session close or program exit (as reported by EternalX, thanks again). - MIDI Controllers Hook and Invert properties are now properly saved for tracks (after bug report by Nicola Pandini, thanks). - A segmentation fault when closing with VST plugins open has been hopefully fixed (after a patch by EternalX, thanks). - Messages standard output capture has been slightly improved as for non-blocking i/o, whenever available. - Automation curve node editing has been slightly improved in regard to time positioning and resolution. See also: http://www.rncbc.org/drupal/node/818 Enjoy && have fun. -- rncbc aka. Rui Nuno Capela

11 years, 3 months

Some questions about the Jack callback

by Will Godfrey

Just trying to get a clearer understand so hope these aren't too noob-ish. If you have several processes wanting to send audio, does the callback go to all of them at (essentially) the same time, or does Jack poll them? If the former, is it the quickest to complete that gets processed first? If the latter, does Jack maintain the same order (assuming none stop) or might it change between buffers? I've a few more questions but they depend on whether either of these scenarios is correct! -- 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.

11 years, 3 months

Fw: Re: Some questions about the Jack callback

by Fons Adriaensen

On Sat, Sep 20, 2014 at 04:10:13PM -0400, Mark D. McCurry wrote: > On 09-20, Fons Adriaensen wrote: > > Having to do 256 1024-point FFTs just to start a note is insane. > > It almost certainly means there is something fundamentally wrong > > with the synthesis algorithm used. > > I agree with that notion. > In typical patches something between 2-10 IFFTs is expected and even this > cost strikes me as too high (zero IFFTs for pure PAD/SUB synth based). > In terms of worst case scenarios ZynAddSubFX can have some rather insane > characteristics given multiple parts, kits, voices, etc. > For instance if a user decided to use all padsynth instances at max quality, > they would need 12GB of memory just to store the resulting wavetables. > > Such extremes are not really seen in practice, but things are slowly getting > optimized to avoid them when possible. You should really look at this from an information theory POV, combined with some psycho-acoustics. Suppose you have to deliver 256 samples in a period when a note starts. That amounts to around 5.3 ms at 48 kHz. That time limits the amount of spectral detail that can be detected given the output from the first period. Which means that there is no point in generating more detail in the first period of a note. Even on sustained notes the amount of spectral detail that can be detected by a human listener is limited by the critical bandwidth of human hearing (which increases with frequency). That means that any set of harmonics that fall within a critical bandwidth can be replaced by a single one with the same energy and nobody would be able to hear the difference. All this means that you *never* need 256 harmonics, not even on bass notes below Fs / (2 * 256). And if the final output is a weighted sum of those IFFT outputs you can as well compute the weighted sum of the inputs and then do a single IFFT - it's a linear transform after all. 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)

11 years, 3 months

Re: [LAD] Some questions about the Jack callback

by Mark D. McCurry

On 09-20, Fons Adriaensen wrote: > Having to do 256 1024-point FFTs just to start a note is insane. > It almost certainly means there is something fundamentally wrong > with the synthesis algorithm used. I agree with that notion. In typical patches something between 2-10 IFFTs is expected and even this cost strikes me as too high (zero IFFTs for pure PAD/SUB synth based). In terms of worst case scenarios ZynAddSubFX can have some rather insane characteristics given multiple parts, kits, voices, etc. For instance if a user decided to use all padsynth instances at max quality, they would need 12GB of memory just to store the resulting wavetables. Such extremes are not really seen in practice, but things are slowly getting optimized to avoid them when possible. The biggest flaw in the algorithm besides the current high cost of initialization is the use of some adaptive harmonics routines which do some frequency dependent spectral modifications before the IFFT. More or less that chunk of math will end up resulting in some inaccuracies when converting to any normal wavetable representation which will avoid the IFFT. Changing over to a wavetable approach will make other parts of the algorithm more correct than they currently are, but there's tradeoffs between correctness and consistency between versions. --Mark (Oops, it looks like I missed the ML the first time I sent this)

11 years, 3 months

Production release 0.4.2 planed of Advanced Gtk+ Sequencer

by Joël Krähemann

Hi, as mentioned in subject: Production release 0.4.2 planed of Advanced Gtk+ Sequencer. Now, comes your part I would like you to test functionality. I'll do for you a wiki page of aspects to test. Please visit http://ags.sf.net and wiki page https://sourceforge.net/p/ags/wiki/testing-cheatsheet/ Happy to hear of you pretty soon! Joël

11 years, 3 months

Jump to page:

2025

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-dev