Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7448 discussions

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

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

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

9 years, 7 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.

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

9 years, 7 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!!!

9 years, 7 months

aeolus: editing the synthesis parameters

by Paul

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

9 years, 7 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)

9 years, 7 months

Detecting 'ready' status of JACK-aware applications in Python

by Jonathan E. Brickman

What are good ways to pull a list of JACK ports in python and detect their readiness to accept connections? And/or, is there a better way to detect 'ready' status of JACK-aware applications? -- Jonathan E. Brickman | jeb(a)ponderworthy.com | (785)233-9977 Ponderworthy | http://ponderworthy.com Music of compassion; fire, and life!!!

9 years, 7 months

[maybe OT] question regarding the FIL equalizer

by Cedric Roux

Hi LAD, I have a technical question regarding the FIL equalizer (by Fons Adriaensen). The code uses Mitra-Regalia lattice filter (as described in [1]). After reordering things here and there I see it's indeed the case (surprise!). [1] might be hard to get, but there is [2] with a lot of details too, especially for bandwidth. The only remaining point that I don't get is the bandwidth manipulations. [1] uses for its parameter 'a' ('_s2' in FIL) the formula: a = (1 - tan(Omega/2)) / (1 + tan(Omega/2)) 'Omega' being I don't really know what (-3dB notch bandwidth for a gain of 0 maybe, if I read the paper correctly). FIL uses bandwith expressed in octave and does: _s2 = (1-b)/(1+b) with: b = bandwidth * 7 * (f0/fs) / sqrt(gain) ('f0' is the center frequency of the equalizer, 'fs' is the sampling rate) Reading [2] we see the factor 'sqrt(gain)' ('gain' is 'K') that we find in the FIL's formula (specifically the formula for k2 at page 13, after equation (17)). But the "bandwidth * 7 * (f0/fs)" remains a total mistery to me. It seems to be 'gamma' as found in [2], but 'gamma' is way more complicated than what we see in FIL's code. So the questions are: - can someone explain to me what this bandwidth computation means? - how it is derived starting from a bandwidth expressed in octave? - And if we use the notations of [1] and [2] how do we relate it to Omega or the various versions found in [2]? (which one is it by the way? I thought it was the "at the bandedge frequencies the gain is 'gain/2 dB'" one but it's not the case) (I wrote a little program to plot things and as far as my program is correct bandedge frequencies don't have a gain of 'gain/2 dB') Regards, Cédric. [1] P. A. Regalia and S. K. Mitra, “Tunable Digital Frequency Response Equalization Filters,” IEEE Trans. Acoust., Speech, Signal Process., vol. ASSP-35 (1987 Jan.). [2] http://www.musicdsp.org/files/EQ-Coefficients.pdf

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