Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

by Fons Adriaensen

Some updates on <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> zita-ajbridge-0.6.0 - Added -S option, disables resampling but of course requires word-clock sync. - Auto selection of best resampler filter lenght. - Cleanup and bug fixes. zita-mu1-0.2.2 - Bugfix: will now exit when zombified or when jackd terminates. - Added proper license headers and GPL3 copy. I also completely replaced the code in Jack1 that calculates the proper running order of clients. The previous algorithm failed to do this in some cases. It could not be 'fixed' easily as it was basically using the wrong algorithm. Affected files are modified: include/engine.h modified: include/internal.h modified: jackd/clientengine.c modified: jackd/clientengine.h modified: jackd/engine.c There seems to be no interest from the Jack devs, but if anybody wants to test this I can either provide the modified files or a patch against git commit 5af5815c47630b77cc71c91a460f8aa398017cf7 (current HEAD). 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)

10 years

JACK latency compensation on USB audio devices

by Joakim Hernberg

I've run across a phenomena that puzzles me. It appears that each time I start the jack server on an usb card, jack_iodelay will report a different "extra loopback latency". I've seen this phenomena on a behringer x32, and just verified it on a rme babyface. For instance with jack1 at 64/2 on the babyface, I come up with values of 232,233,234, and 266. With jack2 I saw 231, 233, 248, 318, 335. A run with jack1 at 2048/3 came up with 2589, 2590, 2633, 2634, and 2667. I also tested with jack_delay, which also comes up with different values when I restart the server. Note that on consequent invocations without restarting the server the values stay the same for the 2 utilities. Maybe not a huge problem and I suppose I'll set the latency compensation somewhere in the middle of the results, but still I'm curious of the mechanism behind this phenomena. FWIW, I don't think I've ever seen this on my pci cards, but I'll run some tests when I get to the hardware and find some extra time. -- Joakim

10 years

ladspa: what does LADSPA_PROPERTY_REALTIME mean?

by IOhannes m zmölnig

hi richard, paul, stefan and fellow LADders, the Debian folks currently are a bit at a loss of the proper interpretation of the LADSPA_PROPERTY_REALTIME property. ladspa.h says: > /* Property LADSPA_PROPERTY_REALTIME indicates that the plugin has a > real-time dependency (e.g. listens to a MIDI device) and so its > output must not be cached or subject to significant latency. */ the discussion started about a year ago (see [760758]), and it seems that there are two opposing interpretations of that property: #1 setting the property indicates to the host, that the plugin must not be used in a non-realtime environment. this means that a plugin that has this property set, must not be used for batch processing, e.g. because it uses wall-clocked input (like MIDI-devices) that simply won't deliver proper input when running at a speed that is decoupled from wall clock. OR #2 setting the property indicates to the host, that the plugin can be run at a lower (timing) priority; so the host can deliberately add latency without compromising the usefulness of the full processing chain. that would be mostly for plugins that do not do any input -> output processing, but only take input (e.g. metering, recording). that's just a quick summary. there's more arguments in the bugreport [760758]. personally i lean towards #1 (as i don't see much use cases for the second interpretation), but given that someone as deeply involved into linux audio as fons favours #2, i would like to ask the creators of LADSPA for their canonical view. thanks for your insights, gfmadsr IOhannes [760758] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760758

10 years

[ANN] Musical Artifacts: new release with updated design

by lucas z

Hello again! I come back to you all with a *kind of* new release of the website, because the project doesn't really have releases, it just stays there... https://musical-artifacts.com/ is a place to collect free 'musical artifacts', that is, pre-sets, configuration files, soundfonts, etc. make them searchable and taggable and give credit to authors. This **release** features a new redone design which encourages browsing through all the tags, apps, and categories. So give it a try! The site currently has ~100 artifacts, but it's growing steadily as I add them and the first people are starting to contribute! The full changelog is here: https://diasporabr.com.br/posts/799925 The code and more info is here: https://github.com/lfzawacki/musical-artifacts As always, feedback and contributions are welcome!

10 years

Last call to contribute to GSequencer for implementing accessibility

by Joël Krähemann

Hi all, I'm currently doing accessibility features to GSequencer the resulted code will be published as GSequencer v0.6.0. If you want to contribute feel free to contact me by email. http://gsequencer.org https://github.com/gsequencer bests Joël

10 years

[ANN] Qsynth 0.4.0 - Summer'15 release frenzy continued...

by Rui Nuno Capela

So, this Summer'15 release frenzy is not over, yet. Qsynth 0.4.0 is now released. Qsynth [1] is a FluidSynth [2] GUI front-end application written in C++ around the Qt framework [3] using Qt Designer. Website: http://qsynth.sourceforge.net Project page: http://sourceforge.net/projects/qsynth Downloads: http://sourceforge.net/projects/qsynth/files - source tarball: http://download.sourceforge.net/qsynth/qsynth-0.4.0.tar.gz - source package: http://download.sourceforge.net/qsynth/qsynth-0.4.0-6.rncbc.suse132.src.rpm - binary packages: http://download.sourceforge.net/qsynth/qsynth-0.4.0-6.rncbc.suse132.i586.rpm http://download.sourceforge.net/qsynth/qsynth-0.4.0-6.rncbc.suse132.x86_64.… License: Qsynth [1] is free, open-source Linux Audio [4] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [5]. Change-log: - Desktop environment session shutdown/logout management has been also adapted to Qt5 framework. - Single/unique application instance control adapted to Qt5/X11. - Output meter scale text color fixed on dark color schemes. - Prefer Qt5 over Qt4 by default with configure script. - Complete rewrite of Qt4 vs. Qt5 configure builds. - A new top-level widget window geometry state save and restore sub-routine is now in effect. - Fixed for some strict tests for Qt4 vs. Qt5 configure builds. - German (de) translation update (by Guido Scholz, thanks). See also: http://www.rncbc.org/drupal/node/933 References: [1] http://qsynth.sourceforge.net [2] http://www.fluidsynth.org [3] http://qt.io [4] http://linuxaudio.org [5] http://www.gnu.org/copyleft/gpl.html Have fun, always! -- rncbc aka. Rui Nuno Capela

10 years

The authors of Horgand

by W.Boeke

Hi, I am trying to contact the authors of Horgand, who are Nick Holborn and Krzysztof Foltman. The reason is that Horgand is an organ with an exceptional beautyful sound that uses an algorithm that is nowhere described in books etc. They call it FM synthesis but it is'nt. Another reason: there are some bugs in their code (version 1.15) that cause an immedient crash if one compiles the program from source code, whereas if installed directly from the Ubuntu repository it works correctly. So the code base used by Ubuntu must be different from the source code at Github. The reasons of the crash are some buffer overflows, easily found using valgrind. Does somebody know where I can find these guys? My own email address is: w dot boeke at upcmail dot nl. Wouter Boeke

10 years

The authors of Horgand

by W.Boeke

Hi Ralf, thanks for the info. So Ubuntu uses Horgand version 1.14, not the recent version 1.15. Also, I found some more buffer overflows. However my main problem remains: I would like to find those authors. Their email adresses in the README alas don't work. Wouter Boeke

10 years

libsoundio 1.0.0 released today

by Andrew Kelley

libsoundio is a C library providing cross-platform audio input and output for real-time & consumer software. It supports JACK, PulseAudio, ALSA, CoreAudio, and WASAPI. It is an alternative to PortAudio, RtAudio, and SDL audio. http://libsound.io/

10 years

jack2: issues w. 32bit clients in 64bit jackd since Fedora 22

by anders.vinjar＠bek.no

Hi all. After upgrading to fc22 during summer, I'm having issues with 32bit jack clients running in my 64bit jackd. I'd be thankful for any clues to what's going on, and ways to debug this. And if others would care to check, and confirm/disprove the same behavior, please tell me what you get. Here's what happens: The 32bit clients connect well, but the callbacks never seem to return, making jackd send out a steady stream of xruns and errors: JackEngine::XRun: client = simple_client was not finished, state = Triggered I'm checking with jack2 installed (jack-1.9.10), with .i686 and .x86_64 versions installed using the standard fedora packages. The same 32bit clients work well in fc21, fc20, and ubuntu 14.04 (in a vm on the same hardware). Afaik, nothing has changed vs. the -mixed flag in jackd, and would expect 32bit clients to run well inside a 64bit jackd. Checking with example-clients/simple-client.c from the jack sources: $ gcc -m32 -g -O -lm -ljack simple_client.c -o simple_client $ ./simple_client - results in the noted behavior. Without -m32 everything's fine. Thanks, -anders

10 years

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