Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7448 discussions

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

9 years, 1 month

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)

9 years, 1 month

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)

9 years, 1 month

Strange Jack1 problem

by Fons Adriaensen

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

9 years, 2 months

[ANN] Qtractor 0.7.0 - The Muon Base is out!

by Rui Nuno Capela

Ahoy! Stepping up to Summer'15 release frenzy stage scene, in it's fourth and hopefully last act, Qtractor 0.7.0 (muon base beta) is out! Qtractor [1] is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework [2]. Target platform is Linux, where the Jack Audio Connection Kit (JACK [3]) for audio and the Advanced Linux Sound Architecture (ALSA [4]) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio. As a major highlight to this release, there's the advent of regular MIDI controllers mapping/assignment to main application menu command actions, just like normal PC-keyboard shortcuts, is being introduced (cf. main menu Help/Shortcuts...). Have a 'hotta' Summer'15 ;) Enjoy. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: http://sourceforge.net/projects/qtractor/files - source tarball: http://www.rncbc.org/archive/qtractor-0.7.0.tar.gz - source package (openSUSE 13.2): http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.src.rpm - binary packages (openSUSE 13.2): http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.i586.rpm http://www.rncbc.org/archive/qtractor-0.7.0-18.rncbc.suse132.x86_84.rpm - wiki (help wanted!): http://sourceforge.net/p/qtractor/wiki/ Weblog (upstream support): http://www.rncbc.org License: Qtractor [1] is free, open-source Linux Audio [6] software, distributed under the terms of the GNU General Public License (GPL [5]) version 2 or later. Change-log: - Complete rewrite of Qt4 vs. Qt5 configure builds. - Revised MIDI Controlllers catch-up algorithm. - Mixer multi-row layout gets a little bit of a fairness fix. - Non-continuous MIDI Controllers now have their Hook and Latch options disabled as those are found not applicable, - As an alternative to PC-keyboard shortcuts, MIDI controllers are now also assignable and configurable for any of the main menu command actions, all from the same old configuration dialog (Help/Shortcuts...). - Fixed missing Track and Clip sub-menus from Edit/context-menu that were found AWOL ever since after the Lazy Tachyon beta release (> 0.6.6). - An off-by-one bar position (as in BBT, bar, beat and ticks) has been purportedly fixed as long as LV2 Time/Position atom event transfer goes. - French (fr) translation line to desktop file added (patch by Olivier Humbert, thanks). - A new top-level widget window geometry state save and restore sub-routine is now in effect. - Improved MIDI clip editor resilience across tempo and time-signature changes. - Keyboard shortcuts configuration (Help/Shortcuts...) now lists complete menu/action path where available. - Fixed in-flight VST plugin editor (GUI) resizing. - Added support to LV2UI_portMap extension, found really handy for the cases where you have multiple plugins with different port configurations and a single common UI to drive them all (pull request by Hanspeter Portner aka. ventosus, thanks). References: [1] Qtractor - An audio/MIDI multi-track sequencer http://qtractor.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development http://qt.io/ [3] JACK Audio Connection Kit http://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [5] GPL - GNU General Public License http://www.gnu.org/copyleft/gpl.html [6] http://linuxaudio.org See also: http://www.rncbc.org/drupal/node/917 Enjoy && keep the fun. -- rncbc aka. Rui Nuno Capela

9 years, 2 months

[ANN] Vee One Suite 0.7.0 - Seventh beta release

by Rui Nuno Capela

Hi everyone, The 'Vee One Suite' of 'old-school' software instruments, aka. the 'gang of three' have gone through yet another milestone: synthv1 [1], as one polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1 [3], as one drum-kit sampler, are now part of the Summer'15 release frenzy :) Still 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. Common change-log follows: - Complete rewrite of Qt4 vs. Qt5 configure builds. - Reset ramps after LV2 control port reconnection; small fixes to LV2.ttl (pull-requests by Hanspeter Portner aka. ventosus, on synthv1, thanks). - MIDI Controllers/Programs is now an optional feature on the LV2 plugin forms, as some LV2 hosts might enforce the purity restriction to input control ports as being absolutely read-only parameter values from a plugin's instance perspective. - MIDI Controller mapping/learn is now possible on all parameter control knobs; with global configuration also available on the Help/Configure dialog. - French (fr) translation line to desktop file added (by Olivier Humbert, thanks). 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. Here they go! **synthv1 - an old-school polyphonic synthesizer [1]** synthv1 0.7.0 (sixth official beta) is out! 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://www.rncbc.org/archive/synthv1-0.7.0.tar.gz - source package: http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.src.rpm - binary packages: http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.i586.rpm http://www.rncbc.org/archive/synthv1-0.7.0-23.rncbc.suse132.x86_84.rpm **samplv1 - an old-school polyphonic sampler [2]** samplv1 0.7.0 (sixth official beta) is out! 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://www.rncbc.org/archive/samplv1-0.7.0.tar.gz - source package: http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.src.rpm - binary packages: http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.i586.rpm http://www.rncbc.org/archive/samplv1-0.7.0-23.rncbc.suse132.x86_84.rpm **drumkv1 - an old-school drum-kit sampler [3]** drumkv1 0.7.0 (sixth official beta) is out! 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://www.rncbc.org/archive/drumkv1-0.7.0.tar.gz - source package: http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.src.rpm - binary packages: http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.i586.rpm http://www.rncbc.org/archive/drumkv1-0.7.0-19.rncbc.suse132.x86_84.rpm 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/916 Enjoy && keep the fun ;) -- rncbc aka. Rui Nuno Capela

9 years, 2 months

RtAudio on archlinux

by Marc Nostromo [M-.-n]

Hi ! This is is my first post to the list, I hope the topic is appropriate. I'm an application developer and I've been using RtAudio/RtMidi for years as cross-platform backend for audio and MIDI. It never failed to work on me beautifully... until last week. I've recently installed a raspberry pi 2 with the latest arch linux distribution available and, for some reason, RtMidi doesn't report connected interfaces. However, amidi does show them which makes me think that alsa is properly configured. [root@piewzei tests]# amidi -l Dir Device Name IO hw:1,0,0 MS-20 Controller MIDI 1 [root@piewzei tests]# ./midiprobe Compiled APIs: Linux ALSA Current input API: Linux ALSA There are 1 MIDI input sources available. Input Port #1: Midi Through 14:0 Current output API: Linux ALSA There are 1 MIDI output ports available. Output Port #1: Midi Through 14:0 I could bother the nice people at McGill but I guess there's something very specific to my setup and I'd like to debug it myself. Would anyone have an idea of what could lead to this behavior ? Thanks for any pointers, Marc. -- http://marc-nostromo.com

9 years, 2 months

PyNSMClient 2.0 - Non Session Manager support for your python program in one file

by Nils Gey

Hello list, I just put PyNSMClient 2.0 on my github page. https://github.com/nilsgey/pynsm2 It is a Non Session Manager Client-Library in one file with no dependencies except Python3 (and NSMd of course). It is designed to make it easier for your program to support non session management. There is an example file which is a complete program with a PyQt5 GUI and a JACK noise generator output. Both the example and the lib-file are documented. Additionally there is a small README.md License is LGPL. The client is largely untested and there are some NSM-API features missing, but it should be easier to use and be more stable than version 1. Real testing and a proper release will begin once I use my own lib with Laborejo2 ( in development behind the scenes). Have a nice day, Nils http://www.nilsgey.de irc: #laborejo on freenode.

9 years, 2 months

AVB not so dead after all

by Reuben Martin

I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_… So make of it what you will. :) I just found it to be interesting. -Reuben

9 years, 2 months

Details about Mackie Control or Mackie Human User Interface

by Takashi Sakamoto

Hi all, I'm a ALSA developer. I currently focus on developing sound drivers for devices on IEEE 1394 bus. In this developing period for Linux 4.3, I'm working for TASCAM FireWire series such as FW-1884 and FW-1082. Well, are there some developers who have enough knowledgement about MIDI messaging rule for Mackie Control or Mackie Human User Interface(HUI)? As long as investigating FW-1082 and FW-1884, these two models transfer control messages over IEEE 1394 isochronous packets, The shape of these messages is similar to bitmap. In detail, see my RFC on alsa-devel: [alsa-devel] [RFC][PATCH 26/37] ALSA: firewire-tascam: add MMAP support to show status and control message http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html To enable userspace applications to handle these messages, a converter to MIDI messages is required, as Windows/OS X drivers did. In my original plan, I off-load this task to userspace driver applications by adding mmap(2)ed page. While, due to some reasons, it's better to implement the converter into kernel driver. As long as I know, for these models, there're three types of the converter; usual MIDI messages such as Control Change (CC), Mackie Control and Mackie Human User Interface, while I have a little knowledgement about the latter two types. For this occasion, I want to know the details. If a cost to implement one of these two types, I'll use it for the converter. Else, I use usual MIDI messages for my patchset to ALSA upstream. Thanks Takashi Sakamoto

9 years, 2 months

Jump to page:

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