Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Pedro Lopez-Cabanillas

Drumstick is a C++ wrapper around the ALSA library sequencer interface using Qt4 objects, idioms and style. ALSA sequencer provides software support for MIDI technology on Linux. Complementary classes for SMF, WRK and OVE file processing are also included. This library is used in KMetronome, KMidimon and KMid2, and was formerly known as "aseqmm". Changes: * OVE file format support, contributed by Rui Fan * Optional RealtimeKit support for MIDI input thread * guiplayer simplified and optimized, with OVE format playback * Build system fixes: using visibility=hidden if it is available, exceptions, static build. Copyright (C) 2009-2010, Pedro Lopez-Cabanillas License: GPL v2 or later Project web site http://sourceforge.net/projects/drumstick Online documentation http://drumstick.sourceforge.net/docs/ Downloads http://sourceforge.net/projects/drumstick/files/

15 years, 3 months

interrupt-drive ALSA returning buffers too small

by Gabriel M. Beddingfield

I was going through Paul Davis's excellent tutorial on the ALSA API: http://www.equalarea.com/paul/alsa-audio.html#interruptex I've set alsa to wake me up every N frames. However, when I awake, I find that I often have fewer than N frames available: int err; uint32_t N = 2048, frames_to_deliver; assert( 0 == ((N-1)&N) ); /* power of 2 */ /*...*/ snd_pcm_sw_params_set_avail_min (playback_handle, sw_params, N) /* ... */ while(1) { err = snd_pcm_wait(playback_handle, 1000); assert(err >= 0); /* OK */ frames_to_deliver = snd_pcm_avail_update(playback_handle); assert(frames_to_deliver >= 0); /* OK */ /* this fails about every other cycle: */ assert(frames_to_deliver >= N); } E.g. with N = 2048, I'll typically get a stream that looks like 1996, 2048, 2048, 1990, 2048, 1999, 2048... Any ideas? -gabriel

15 years, 3 months

Re: [LAD] Mouse/knob interaction

by Arnold Krille

On Thursday 09 September 2010 00:32:18 Olivier Guilyardi wrote: > On 09/08/2010 11:37 PM, Arnold Krille wrote: > > http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-won > > ton.png > > http://positron.physik.uni-halle.de/~arnold/fadercolors-system_colors-ob > > sidian.png > > Sorry but wouldn't it be clearer with tiny level bars, instead of colors? > > http://testing.samalyse.com/lad/widgets/numbers.png > http://testing.samalyse.com/lad/widgets/numbers.svg Hm. No. The left-to-right level-bars imply a left-to-right movement to change the values. And one of the reasons to do the color-thing is space. If I hide the text and only show it when the mouse hovers, I can fit a lot of mixing-nodes on screen. A horizontal (or vertical) bars needs more space to have a comparable resolution. I like the idea of hiding the mouse during value-changing moves. I already have these "sliders" react to the mouse-movement logarithmic. That also helps a lot when both coarse and fine changes should be possible with similar mouse- movement. And somehow I dream of a toolkit where you select a knob/slider/fader and it then reacts to the turn-knob you have on your desk. But given the variety in toolkits, I think this is a dream of the distant future unless that big knob sends out mouse-movement signals... Have fun, Arnold

15 years, 3 months

Fwd: Mouse/knob interaction

by alex stone

So far, nobody's mentioned how to get to the aforesaid knob in the first place, or alternatives to manipulating it. Navigating with the mouse is a poor second to precise locating, and using qwerty actions to set values, be it a knob or slider, is more accurate. So, tab, or an associated action to get to the knob in the first place, and something like ALT+ up/down arrows (as an example) to change the knob value. Then it's irrelevant whether the knob responds to mouse up/down/left/right, or mouse wheel, for users who find those options second best, when a more efficient and precise option already exists. For graduated speed in the case of a spin knob (starting slow and getting faster), the user only needs to keep the actions pressed. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

15 years, 3 months

EMutrix v0.1 released

by Camilo Polymeris

Hello EMutrix is a simple, easy-to-use graphical mixer application for EMU 1010 based cards like the E-MU 1212m, E-Mu 1616m and E-MU 1820 models. I am releasing the first source package of EMutrix, version 0.1 at http://emutrix.googlecode.com It is mostly functional, allowing arbitrary routing between the card's multiple inputs, outputs and ALSA, setting clock rate and pads. More features to come in future versions. Try it out if you have an E-Mu card! Any comments welcome. Greetings, Camilo

15 years, 3 months

jMax Phoenix beta 0.6 is out

by Maurizio De Cecco

After many month of development, we are proud to announce the version 0.6 beta of jMax Phoenix. The major highlights for this version are: - A first version of the puredata source compatibility kit, including the build system and a full example of recompiled object library. - A large set of usability bug fixed; all the bugs preventing a smooth work flow have been fixed. - Error handling improvements: most of the bugs and configuration errors now results in error messages, and not unexplained freezes. - A set of examples and tutorials has been recovered from old ISPW archives; they are not updated to include all the major jMax functionalities, but it is better than nothing. Full release notes are available in the release notes section of the projet site. This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian 5, Fedora 13 and Mandriva Spring 2010; check the installation instruction on the projet site for specific caveats for Debian and Fedora. The Puredata compatibility sub-project has been *very* time consuming; in order to better manage my scarce time resources, we need some user feedback (and possibly help) to be able to evaluate the actual interest of pursuing this development direction. For more information and download and installation instructions go to http://www.jmax-phoenix.org/. For contacting the project team: contact(a)jmax-phoenix.org The jMax Phoenix team

15 years, 3 months

Re: [LAD] Best way to insert DSP module in audio chain in Linux

by Kim Therkelsen

Thank you very much for your advice everyone. As mentioned I have already made the LADSPA plugin and tested it with PulseAudio, so I will take a look at the PulseAudio LADSPA plugin module loader and see if I can add the functionality I need (multichannel audio and detection of when headphones are plugged in). Then I will see how it goes from there. /Kim

15 years, 3 months

Best way to insert DSP module in audio chain in Linux

by Kim Therkelsen

Hi, I want to make is a DSP module that improves the sound quality of the sound coming from the laptop builtin speakers by applying DSP (FIR/IIR filters). I want to route all audio played back (from for instance an offline WAV or MP3 file, from a movie, or streamed from the internet) to pass through the DSP plugin whenever headphones are NOT connected. When headphones are connected no processing should be applied. I want to place the DSP module as close to the hardware as possible to make sure all audio is really routed through the DSP plugin so I always can enjoy the DSP improvements made to the sound. Where should I place this module/DSP code? - As a plugin to PulseAudio? - As a plugin to ALSA? - As its own virtual sound card? - In the audio driver for my built-in sound card? - As a kernel module? I have tried loading the LADSPA-module using the module-ladspa-sink in PulseAudio but I am not sure this is the best solution. I need to remove some limitations in module-ladspa-sink to get it working properly ( multichannel audio, only DSP processing for internal speakers). My requirements: 1) Must be able to detect if headphones are connected 2) Must be able to process stereo and multichannel (5.1/7.1) formats. I need the multichannel formats to perform binaural downmixing to stereo. So it is important that I can receive multichannel audio and mix it down to stereo and output it to a stereo soundcard. /Kim

15 years, 3 months

Re: [LAD] mixer

by fons＠kokkinizita.net

Alex, I hope you don't mind quoting part of your message on the list, as the subject is of general interest. Alex stone wrote offlist: > Fons, i've read in the mailing list in the thread concerning mixers, > that you have something you're working on. > ... > More than any other facet of working in software for audio/midi/vid, > i've been frustrated and tired out by poor navigation options, and i > don't think i'm on my own. > The mouse is insufficent for ease, speed, and pain free day in day out > use, and i ask you to at least consider (or not, as you decide) > alternatives such as the one above, to make a difference in the way > users commonly interact with this type of software. I more than agree with this. Defining the way a user interacts with a large software mixer is 90% of the work of writing one. Common GUI methods just don't work for this sort of thing. The thing that is slowly taking some form here will observe some GUI guidelines quite strictly, in particular there will be *NO* repeat *NO* resizing, scrolling or moving of windows, menus will be used sparingly and be small, and popup dialogs will be used only for operations that can be assumed to be infrequent (mainly setting up things, selecting and connecting plugins, etc.). When setting up a new session, you define the resources: - number of channel strips - number of real groups - number of control groups - number of visible sections - number of strips per section - number of jack/alsa inputs - number of jack/alsa outputs These are more or less fixed afterwards, in the sense that you can't remove any, but probably I can allow to increase these numbers (the point here is that all snapshots taken for such a configuration must remain valid without requiring changes to the resources). Anyway there is no penalty (apart from a small amount of memory used) for providing more than you need. A _section_ is a group of strips, typically 8, 10 or 12. Normally you should select the section size so you can have two of them side by side, as this facilitates many operations. For each visible section there is a control strip, which contains e.g. buttons to select which strips are shown. You will have default sections, e.g. inputs 1-8, 9-16, 17-24, etc, same for real groups and control groups. There are also user-defined sections: these can contain copies of any strip you want in any order you want. For example you could group all inputs used for drums in a secion, or have a 'master' section that contains mainly groups and maybe some solo mics. There is some 'intelligence' in the section selection buttons, for example, if you select to see inputs 17-24 in the right section, you click that button (or use a kb shortcut), then clicking again restores the previous view. Or selecting a section that is already visible will swap the two, etc.etc. Each visible section is vertically divided in two, the bottom half showing the faders, channel ID, mute, solo etc. most of the time, while the top half can show parts of the strips, e.g. EQ, sends or dynamics. Again this layout is configurable to some extent, you can e.g. select to have some aux sends visible all the time. The top part of each visible section can also be used for plugins, metering, 'visual' panning, or whatever extra functions that would need to be displayed. All Jack/Alsa ports are generic, each of them can be assigned to any function inside the mixer. That means e.g. that Jack connections can remain fixed no matter how you 'rewire' the mixer, and this in turn means that nothing is lost if you connect directly to a multichannel Alsa device, e.g. a MADI card. The mixer will have its own plugin interface, and it will not accept any of the existing standards. If someone wants to use a LADSPA or LV2 I will consider porting it. Condition for this will be the *quality* of the plugin, and nothing else. Ciao from very hot Crete (I'll be cooling down 20m below the water surface in a short time). -- FA There are three of them, and Alleline.

15 years, 3 months

Fwd: Claim: Microsoft Pressured Digidesign to Deny Support of GNU/Linux

by Niels Mayer

Comments anybody :-) http://techrights.org/2010/08/27/throwing-a-wrench-at-protools/ ........................... I have heard from a reliable source, inside Digidesign, that they actually have Protools running on Linux, and that the port from OSX isn’t that hard, but are under contract obligation to Microsoft to not release a Linux port. Otherwise Microsoft can revoke their access to the Windows SDK. .......................... Niels http://nielsmayer.com

15 years, 3 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