Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

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

aeolus: editing the synthesis parameters

by Paul

How do I start the synthesis parameter editor in Aeolus 0.9.0? -- P.

10 years, 10 months

Fw: Re: [maybe OT] question regarding the FIL equalizer

by Fons Adriaensen

Date: Thu, 26 Feb 2015 22:04:39 +0000 From: Fons Adriaensen <fons(a)linuxaudio.org> To: Cedric Roux <sed(a)free.fr> On Wed, Feb 25, 2015 at 11:46:37PM +0100, Cedric Roux wrote: > can someone explain to me what this bandwidth computation means? There is nothing magical about it, it's just a pragmatic approximation that results in the 3dB BW (for high + or - gain) being expressed in octaves. Expressing the BW in a logarithmic unit (such as octaves) make sense because the magnitude response of a second order parametric is symmetric on a log(f) scale but not on a linear one. An absolute value in Hz or even a relative one (the same divided by center frequency) is informative only for small BW, where the linear distance to the -3dB points left and right would be more or less equal. For large BW values (as often used in sound engineering) this is no longer true. For example for a center frequency of 1 kHz and two octaves BW the -3dB points are at 500 Hz and 2 kHz. For four octaves that would be 250 Hz and 4 kHz, giving a -3dB BW in Hz that is larger than twice the center frequency, which is somewhat counter-intuitive. The 'mathematical' way to define the BW of an second order allpass would be at the +/- 90 degree phase points. This also corresponds to the -3 dB points for an infinite notch, as used by M & R. But keeping this value fixed in a parametric results in curves that are not even symmetric for + and - gains. The 'bumps' would be much wider than the 'notches'. The sqrt (gain) factor restores this symmetry. But using this means that there is no longer any simple relation to what looks like bandwidth on a frequency response plot and the actual 'mathematical' value. 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)

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