Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

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, 5 months

[LAD] 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, 5 months

[LAD] [ANN] Vee One Suite 0.7.1 - A seventh-bis beta release

by Rui Nuno Capela

Hello again, The 'Vee One Suite' aka. 'the gang of three old-school' software instruments, featuring synthv1 [1], as one polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1 [3], as one drum-kit sampler, which is getting a small but pertinent bug-fix, are all making up for the so called 'Summer'15 release frenzy (extended edition;))'. All made available in dual form: - a pure stand-alone JACK [4] client with JACK-session, NSM [5] (Non Session management) and both JACK MIDI and ALSA [6] MIDI input support; - a LV2 [7] instrument plug-in. Change-log: - Fixed a recent bug/mistake that was causing a complete reset/revert of all element parameters to prior values upon loading an element sample file. (applies to drumkv1 [3] only) - Improved Qt4 vs. Qt5 configure builds (via qmake). The Vee One Suite are free and open-source Linux Audio [9] software, distributed under the terms of the GNU General Public License (GPL) [8] version 2 or later. And here they go again! **synthv1 - an old-school polyphonic synthesizer [1]** synthv1 0.7.1 (seventh-bis official beta) is released! synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx. LV2 URI: http://synthv1.sourceforge.net/lv2 website: http://synthv1.sourceforge.net downloads: http://sourceforge.net/projects/synthv1/files - source tarball: http://download.sourceforge.net/synthv1/synthv1-0.7.1.tar.gz - source package: http://download.sourceforge.net/synthv1/synthv1-0.7.1-24.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/synthv1/synthv1-0.7.1-24.rncbc.suse132.i586… http://download.sourceforge.net/synthv1/synthv1-0.7.1-24.rncbc.suse132.x86_… **samplv1 - an old-school polyphonic sampler [2]** samplv1 0.7.1 (seventh-bis official beta) is released! samplv1 is an old-school polyphonic sampler synthesizer with stereo fx. LV2 URI: http://samplv1.sourceforge.net/lv2 website: http://samplv1.sourceforge.net downloads: http://sourceforge.net/projects/samplv1/files - source tarball: http://download.sourceforge.net/samplv1/samplv1-0.7.1.tar.gz - source package: http://download.sourceforge.net/samplv1/samplv1-0.7.1-24.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/samplv1/samplv1-0.7.1-24.rncbc.suse132.i586… http://download.sourceforge.net/samplv1/samplv1-0.7.1-24.rncbc.suse132.x86_… **drumkv1 - an old-school drum-kit sampler [3]** drumkv1 0.7.1 (seventh-bis official beta) is released! drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx. LV2 URI: http://drumkv1.sourceforge.net/lv2 website: http://drumkv1.sourceforge.net downloads: http://sourceforge.net/projects/drumkv1/files - source tarball: http://download.sourceforge.net/drumkv1/drumkv1-0.7.1.tar.gz - source package: http://download.sourceforge.net/drumkv1/drumkv1-0.7.1-20.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/drumkv1/drumkv1-0.7.1-20.rncbc.suse132.i586… http://download.sourceforge.net/drumkv1/drumkv1-0.7.1-20.rncbc.suse132.x86_… References: [1] synthv1 - an old-school polyphonic synthesizer http://synthv1.sourceforge.net/ [2] samplv1 - an old-school polyphonic sampler http://samplv1.sourceforge.net/ [3] drumkv1 - an old-school drum-kit sampler http://drumkv1.sourceforge.net/ [4] JACK Audio Connection Kit http://jackaudio.org/ [5] NSM, Non Session Management http://non.tuxfamily.org/nsm/ [6] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [7] LV2, Audio Plugin Standard, the extensible successor of LADSPA http://lv2plug.in/ [8] GNU General Public License http://www.gnu.org/copyleft/gpl.html [9] http://linuxaudio.org See also: http://www.rncbc.org/drupal/node/923 Enjoy && have (lots of) fun ;) -- rncbc aka. Rui Nuno Capela

10 years, 5 months

[LAD] [ANN] A website for pre-sets, soundfonts, and more

by lucas z

Hey everyone, this is a project I've been working on for some months now and now I think it's ready for some beta testing. 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. For example here are some soundfonts, zyn pre-sets and guitarix tones: https://musical-artifacts.com/artifacts?tags=soundfont https://musical-artifacts.com/artifacts?apps=guitarix https://musical-artifacts.com/artifacts?apps=zynaddsubfx I've started populating the application with some artifacts and will continue doing so in the future. Also the application is in BETA right, so new features are coming and some bugs are to be expected! You can look at the source, contribute or file bugs via github https://github.com/lfzawacki/musical-artifacts That's it!

10 years, 5 months

[LAD] Spectral envelope code

by Gerald Mwangi

Hi Can anyone point me out to code that extracts the spectral envelope of a signal. Due to my tight time constraints I can't dig much into the topic to develope such an extractor, so somewhat working C/C++ code is appreciable. Thanks Gerald

10 years, 5 months

Re: [LAD] Strange Jack1 problem

by Stéphane Letz

> > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 8 Aug 2015 16:48:45 +0000 > From: Fons Adriaensen <fons(a)linuxaudio.org> > To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org> > Subject: [LAD] Strange Jack1 problem > Message-ID: <20150808164845.GA7139(a)linuxaudio.org> > Content-Type: text/plain; charset=us-ascii > > Hello all, > > I've been testing some new features of zita-njbridge. The test > setup was: > > zita-n2j -> jack_delay -> zita-j2n > > with the loop closed via the network. The purpose of the test was to > verify the added latency. It produced the expected result - until I > started another (unrelated) Jack app. Suddenly the delay increased > by one period. Stopping the other app had no effect. Restarting it > made the measured delay return to its original value. Then each > time another app (no matter which one) was started or any ports > were connected or disconnected, the delay switched been these two > values. > > First I suspected some bug in zita-njbridge - it has some logic to > detect skipped cycles etc. and handle them gracefully. But I found > no error there, and the problem also occured when no cycles were > skipped. > > The I let n2j write the jack usecs time at the start of its process() > to shared memory, and j2n read it and print the difference with its > own process() time. This confirmed what I suspected: when the delay > increased, the order of execution of n2j and j2n was reversed. > > Note that as far as Jack is concerned there is no loop in the > graph, and hence no ambiguity as to the correct order. > > So the conclusion seems that Jack1 is doing something unexpected > each time the graph order is recalculated. > > This seems to depend on how many apps or ports are active before > the test is started. When the test apps are the first ones all > seems to be OK. > > I could not reproduce the problem with Jack2. > > Has anyone noticed similar things ? > > Ciao, > > -- > FA > I am surprised also JACK1 does no do topological sort which obviously is the needed way... Note that JACK2 does not need to do topological sort of the client graph, since it's client activation system is based on a "data flow" model. Client "order" is found out with this "activation token" model that goes progressively from inputs to outputs during a given cycle. It means that for instance the following graph : IN ==>A ==> OUT IN ==> B ==> OUT where A and B are connected to IN and OUT, and that would be topologically sorted to 2 correct activation sequences (either IN ==> A ==> B ==> OUT) (or IN ==> B ==> A ==> OUT) would be activated in parallel in JACK2, so A can possibly run before B, or the contrary, or both at the same time on 2 different cores…. Stéphane

10 years, 6 months

Re: [LAD] Strange Jack1 problem

by Fons Adriaensen

On Sat, Aug 15, 2015 at 05:14:12PM +0100, Simon SD1 wrote: > > > On 15 Aug 2015, at 16:06, Fons Adriaensen <fons(a)linuxaudio.org> wrote: > > > 'Delayed' connections (those that create a cycle) can be > > reverted to normal ones as soon as possible (the current > > implementation does this only when the entire graph has > > becomes cycle-free). > > The options discussed in 2004 were to revert those connections > when the entire graph became cycle-free, or never to revert them > so long as they existed. Waiting for all cycles (if there were ever more than one) to be broken seems IMHO no better than reverting ASAP. In both cases the changes are probably not anticipated by the user. My personal preference would be to never revert such connections. > The rationale for never reverting them was that a pair of connected > clients would suddenly be running in a different order — and a buffer’s > worth of data between them would vanish But that can happen anyway in Jack1 if a cycle is skipped. > The rationale for reverting them was lower latency, and to prevent > pathological cases where a chain of clients could be running in entirely > the wrong order because of cycles that used to exist but don’t any more. Seems rather unlikely. If such things are a real problem, then the clean solution is to make things explicit to the user, but this requires a change of the API: when a connection is made, you could have the options - don't care (default), but return result, - must be normal, fail if not possible, - must be delayed, fail if not possible. I've done this in a multithreaded single-process framework (for things like softsynths, mixers, etc.) It allows to set up feedback connections in a controlled way. With the algorithm I have in mind, never reverting is the easiest, doing so ASAP comes next, and reverting only if the result would be completely cycle free would be the hardest. 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, 6 months

[LAD] job opportunity at CCRMA (take 2)

by Fernando Lopez-Lezcano

Hi all, The Center for Computer Research in Music and Acoustics (CCRMA) at Stanford University is a multi-disciplinary facility where composers and researchers work together using computer-based technology both as an artistic medium and as a research tool (https://ccrma.stanford.edu/about). We are (still) currently looking for a great person to help lovingly take care of and feed our servers, workstations, and multichannel audio setups. The right person will be working with and helping a diverse community of interdisciplinary students (ranging from undergrads to DMAs and PhDs, studying Music, EE, CS, and many other fields), researchers, and faculty from all over the world. Our computers mostly run GNU/Linux but there are Macs in the studios and even a couple of Windows machines in the NeuroMusic lab. We do complex multichannel audio setups in our studios and for concert diffusion (3D sound in up to 25.8 channels), we maintain all our own servers and backups, and we package our own software (and other developers' open source free software) in repositories so that anyone can install it easily. All this is quite a lot of work and we need help! Qualities sought: curious, tenacious, responsible, self-motivated, tech-savvy, willing to learn, artist- and wizard-compatible, strong team player who can work independently. Full details about the job are here: https://stanfordcareers.stanford.edu/job-search?jobId=66452 -- Fernando

10 years, 6 months

Re: [LAD] Strange Jack1 problem

by Fons Adriaensen

On Mon, Aug 10, 2015 at 04:43:01PM -0400, Paul Davis wrote: > it provides output indicating the logic decisions that lead to the > execution order. I spent most of the day trying to convinve myself that I was overlooking something. But in the end the conclusion of all that work is this: * The algorithm used by Jack1 to determine the order of * running clients in each cycle is fundamentally flawed. The reason in mathematical terms is quite simple. Both the relations 'A feeds B' and its transitive closure 'A feeds B, maybe indirectly' define only a *partial order* on the set of clients. Now all classical sorting algorithms, including the merge sort used in this case, assume a *total order* of the set to be sorted, and may not produce the correct result if only a partial order is defined. It's easy to see this in a less abstract way. All classical sorting algos are designed to reduce the number of compare() calls. For example, if they find that a == b and a == c they will in most cases avoid testing b against c, since under total order it must be true that b == c. Now if a '0' return from the compare() function does not mean equality but rather 'not connected' things change. Using the example above, you *can not* conclude that b and c are not connected. So all it takes is a few unconnected clients or two or more independent chains to increase the probability that a classical sort algorithm will fail to produce a correct sequence. I actually worked out the example I posted yesterday with pencil and paper, including all the merge sorts. This produced exactly the results posted. So there is no bug in the current code, it is just the wrong algorithm. To find a linear sequence preserving the order of a partially ordered set you need what is known as 'topological sorting'. It's usually implemente using depth-first search (DFS) with post-order output. 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, 6 months

[LAD] Fw: Re: Strange Jack1 problem

by Fons Adriaensen

----- Forwarded message from Fons Adriaensen <fons(a)linuxaudio.org> ----- Date: Mon, 10 Aug 2015 19:46:15 +0000 From: Fons Adriaensen <fons(a)linuxaudio.org> To: Paul Davis <paul(a)linuxaudiosystems.com> Some new evidence which may be useful. It seems the problem occurs only if at least one client is running before zita-*2* and jack_delay are started. In the logfile added below, the lines between the '----' are the ouput of some printf() added to jack_rechain_graph(). The name of each client is printed as the list is traversed, (near to top of the main loop) and a '*' is printed when a new chain is started. fons@erc-linux1:~> /usr/bin/jackd -P70 -p1024 -u -dalsa -dhw:UA22,0 -r48000 -p256 -n2 jackd 0.124.1 Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. loading driver .. apparent rate = 48000 creating alsa driver ... hw:UA22,0|hw:UA22,0|256|2|48000|0|0|nomon|swmeter|-|32bit configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 24bit little-endian ALSA: use 2 periods for playback ------------------------------ ------------------------------ # 1. Start Qjackctl ------------------------------ ------------------------------ # 2. Start japa ------------------------------ japa * ------------------------------ # 3. Start zita-j2n ------------------------------ japa * zita-j2n ------------------------------ # 4. Start zita-n2j ------------------------------ zita-j2n * japa zita-n2j ------------------------------ # 5. Start jack_delay ------------------------------ zita-n2j * japa zita-j2n jack_delay ------------------------------ # 6. Connect zita-n2j -> jack_delay ------------------------------ jack_delay * zita-j2n japa zita-n2j ------------------------------ # This looks already wrong... jack_delay # can't be first. # 7. Connect jack_delay -> zita-j2n ------------------------------ zita-n2j * japa jack_delay zita-j2n ------------------------------ # Correct delay is measured. # 8. Connect system:capture_1 -> japa_in_1 ------------------------------ jack_delay * zita-j2n japa zita-n2j ------------------------------ # The order of execution is wrong and # measured delay increases by one period. # 9. Connect system:capture_2 -> japa_in_2 ------------------------------ zita-n2j * japa jack_delay zita-j2n ------------------------------ # Correct delay measured again. # 10. Disconnect system:capture_1 ------------------------------ jack_delay * zita-j2n japa zita-n2j ------------------------------ # Wrong again. # 11. Disconnect system:capture_2 # ------------------------------ zita-n2j * japa jack_delay zita-j2n # ------------------------------ # OK etc. etc. -- 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)

10 years, 6 months

Jump to page:

2026

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