Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7502 discussions

io GNU/Linux 2015.01 released

by Manu Kebab

Hi, io GNU/Linux 2015.01 has been released (32 and 64-bits). io GNU/Linux is a Live DVD/USB based on Debian Sid and focused on multimedia. This new version includes an installer (without support for EFI/GPT based systems for now) Kernel 3.16.7-ck7, Jack2 as default sound server, e18 as desktop environment and a big collection of installed software... Full persistence for USB install (with encryption) and more cool stuff... For more infos: manual, packages list, screenshots, video etc... Check: -> http://io.gnu.linux.free.fr/ (work in progress) -> https://sourceforge.net/projects/io-gnu-linux/ Feedbacks welcome, enjoy :) MK

10 years, 3 months

Hydrogen and Round Robin

by Aurélien Leblond

I just bought the drumdrops mapex samples to create a kit in Hydrogen... They are gonna be great with the direct/overhead/room functionaly in Hydrogen. The set comes with Round Robin and with a bit of thinking I came up with 2 possible design to get this functionality in. COMPLEX: - Add a list of samples in the Layer object ; the sampler will chose randomly one sample of the list when the instrument layer is played - GUI wise, when a user click edit/delete layer, a form will popup asking the user which of the sample he wants to edit/delete The pros is that data structure wise it is really clean: Instrument->Components->Layers->RoundRobin->Samples The cons is that GUI wise it's not very clear for the user what's going on, and it asks for more development. SIMPLE - Increase the number of layer per instrumebr to 64 - A check box is added in the instrument to active round robin - If round robin is activated, layers that share the same velocity range will be played randomly. If round robin is not activated, the layers that share the same velocity range are player simultaneously The pros is that the changes are very minimum to Hydrogen can be implemented in a couple of hours. In addition it is simpler for the user to see what's going on (checkbox and the visual of layers). So what do you guys think? I wouldn't mind coding the simple options, cannot wait to put all the samples i just bought into this! Aurélien

10 years, 3 months

jack1 unsafe with accidentally (?) internal exported functions

by Tito Latini

Hi, some internal functions are globals and I think it is not what you want (jack2 seems ok). For example, a naive way to forbid the creation of other jack clients is: # tested with jack 0.124.1 gcc -ljack private_club_mode.c ./a.out # prints "JACK compiled with System V SHM support." echo $? # 0 jack_lsp # no more clients please, segfault (jack_client_open_aux) /* private_club_mode.c */ #include <jack/jack.h> int jack_register_server(const char *, int); int main() { return jack_register_server("umpa", 0xDADA); } Tito

10 years, 3 months

Fwd: AES69-2015 standard for file exchange - Spatial acoustic data file format

by Jörn Nettingsmeier

This was just announced on sursound. Might be worthwhile to adopt for anyone working with spatial audio datasets and files... -------- Forwarded Message -------- Subject: [Sursound] AES69-2015 standard for file exchange - Spatial acoustic data file format Date: Sun, 15 Mar 2015 16:13:47 +0100 From: Markus Noisternig <Markus.Noisternig(a)ircam.fr> Reply-To: Surround Sound discussion group <sursound(a)music.vt.edu> To: Surround Sound discussion group <sursound(a)music.vt.edu> Dear Sursounders, We are pleased to announce the recent publication of the AES69-2015 standard for file exchange - Spatial acoustic data file format. See also the AES press release at http://www.aes.org/press/?ID=293 <http://www.aes.org/press/?ID=293> The new AES69-2015 standard defines a file format to exchange space-related acoustic data in various forms. These include HRTF, as well as directional room impulse responses (DRIR). The format is designed to be scalable to match the available rendering process and to be sufficiently flexible to include source materials from different databases. This project was developed in AES Standards Working Group SC-02-08 and standardizes the Spatially-oriented format for acoustics (SOFA), which aims at storing and transmitting any transfer-function data measured with microphone arrays and loudspeaker arrays. See http://www.sofaconventions.org/ <http://www.sofaconventions.org/> for further information and ongoing format discussions. Open source application-programming interfaces (API) for Matlab, Octave, and C++ are available online at http://sourceforge.net/projects/sofacoustics/ <http://sourceforge.net/projects/sofacoustics/> All the best, Markus and Piotr -- Markus Noisternig Acoustics and Cognition Research Group IRCAM, CNRS, Sorbonne Universities, UPMC Paris, France Piotr Majdak Psychoacoustics and Experimental Audiology Acoustics Research Institute Austrian Academy of Sciences Vienna, Austria

10 years, 3 months

Re: [LAD] Fw: [alsa-devel] Using loopback card to Connect GSM two way call to the real sound card UDA1345TS

by Clemens Ladisch

Srinivasan S wrote: > $ aplay -f dat -D VOUTL new.wav > Playing WAVE 'new.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo > aplay: set_params:1087: Channels count non available You are trying to play a two-channel file on a single-channel device. Regards, Clemens

10 years, 3 months

[ANN] Vee One Suite 0.6.1 - A fourth beta release

by Rui Nuno Capela

Hi, The 'Vee One Suite' of this 'old-school' software instruments, also self-indicted as the gang of three usual suspects thou being: synthv1 [1], as one polyphonic synthesizer, samplv1 [2], a polyphonic sampler and drumkv1 [3], as one drum-kit sampler, now released into the world, yet still beta. Not much of any audible changes I must say for this so called fourth beta release though it goes as follows: - Added application description as freedesktop.org's AppData. - Introducing LV2 port-groups (as proposed by Amadeus Folego aka. badosu, thanks). - Improved envelope widget nodes click-and-drag precision. - Introducing a brand new user preference on eye-candy: cf. Help/Configure.../Options/Custom style theme (applies to the JACK stand-alone client only though). - Envelope and filter now rendered with anti-aliased lines. - Fixed a Qt5 FTBFS re. QHeaderView::set[Section]ResizeMode(). There's no surprise as it's all made available in dual form, as usual: - 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. The Vee One Suite are free and open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) [8] version 2 or later. Yet again, business as usual :/ **synthv1 - an old-school polyphonic synthesizer [1]** synthv1 0.6.1 (fourth official beta) has been 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.6.1.tar.gz - source package: http://download.sourceforge.net/synthv1/synthv1-0.6.1-20.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/synthv1/synthv1-0.6.1-20.rncbc.suse132.i586… http://download.sourceforge.net/synthv1/synthv1-0.6.1-20.rncbc.suse132.x86_… **samplv1 - an old-school polyphonic sampler [2]** samplv1 0.6.1 (fourth official beta) has been 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.6.1.tar.gz - source package: http://download.sourceforge.net/samplv1/samplv1-0.6.1-20.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/samplv1/samplv1-0.6.1-20.rncbc.suse132.i586… http://download.sourceforge.net/samplv1/samplv1-0.6.1-20.rncbc.suse132.x86_… **drumkv1 - an old-school drum-kit sampler [3]** drumkv1 0.6.1 (fourth official beta) has been 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.6.1.tar.gz - source package: http://download.sourceforge.net/drumkv1/drumkv1-0.6.1-16.rncbc.suse132.src.… - binary packages: http://download.sourceforge.net/drumkv1/drumkv1-0.6.1-16.rncbc.suse132.i586… http://download.sourceforge.net/drumkv1/drumkv1-0.6.1-16.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 See also: http://www.rncbc.org/drupal/node/874 Enjoy && keep the fun ;) -- rncbc aka. Rui Nuno Capela

10 years, 3 months

Re: [LAD] [alsa-devel] Using loopback card to Connect GSM two way call to the real sound card UDA1345TS

by Clemens Ladisch

Srinivasan S wrote: > Could you please provide any inputs w.r.t the loopback card using > snd-aloop & alsaloop, how this loopback card can be used to connect > the GSM two way call simultanoeusly to the UDA1345TS codec on MCASP0 > of the am335x (UDA1345TS ie., real sound card) snd-aloop creates a virtual sound card; it is not used with a real sound card. > The codec has two output channels VOUTL, VOUTR & two input channels VINL , VINR > > With this am able to achieve only one way call at a time by running > only one application at a time To allow a capture device to be shared, you need to use dsnoop. Your asound.conf already does this. To allow a playback device to be shared, you need to use dshare or dmix. (dshare allows to use _different_ channels; dmix allows mixing multiple sources into the same channels.) Your asound.conf does not do this; it uses "hw" instead. Regards, Clemens

10 years, 3 months

ALSA audio

by Will Godfrey

I've just been reading the ALSA Programming HOWTO by Matthias Nagorni and one detail caught my attention immediately. This is the idea of using plughw instead of directly addressing your soundcard. On the face of it this seems *much* easier, but there surely must be a catch. Can anyone explain what the downside of doing this might be? -- 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.

10 years, 4 months

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

10 years, 4 months

JACK Process Control library for Python

by Jonathan E. Brickman

Well, my need is clear, so the result has obtained. Nowhere near as pretty as I'd like, but it is working very well: http://lsn.ponderworthy.com/doku.php/concurrent_patch_management?&#jpctrlpy… Its purpose is to start processes and make sure they settle before starting more processes and/or wiring things up with JACK. Use is exemplified here: http://lsn.ponderworthy.com/doku.php/concurrent_patch_management?&#boot-gen… -- Jonathan E. Brickman | jeb(a)ponderworthy.com | (785)233-9977 Ponderworthy | http://ponderworthy.com Music of compassion; fire, and life!!!

10 years, 4 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