Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] XAP again - channels, etc.

by Tim Hockin

I fear we've all been very busy. I know I have. I have not had time to devote to XAP, though I have certainly not lost interest. So today I start looking at my evolving spec doc again. The biggest chunk of undecidedness lies in the area of Channels. We never really resolved the Bays/Channels etc debate. We just put it off. Here it is. I'd like to propose the following - it is simple and flexible. Not too confusing. Plugins define 'Modules'. Every plugin has a master Module, and 0-n extra Modules. The host can instantiate Modules as needed. A Module is analogous to a MIDI Channel in a synth (maybe Module is the wrong word). It is analogous to a slot in a mixer. struct XAP_descriptor { ... /* master module descriptor */ XAP_module master; /* other channel descriptors */ int n_modules; XAP_module *modules; /* * Instantiate a module, return a plugin-unique * id/index for it - it's 'Channel'. */ int (*add_module)(void *plugin, int module); /* * Remove a module. */ int (*del_module)(void *plugin, int index); }; struct XAP_module { char *label; char *name; uint32_t flags; /* how many instances of this module are allowed? */ int count_max; /* per-module controls and I/O */ int n_controls; XAP_control **controls; int n_ports; XAP_port **ports; };

22 years, 2 months

[linux-audio-dev] non-standard uses of MIDI reserved system opcodes

by John Lazzaro

Hi everyone, There are 2 MIDI System Common opcodes (0xF4 and 0xF5) and 2 MIDI System Realtime opcodes (0xF9 and 0xFD) that the official MIDI standard reserves for future use. I'm currently collecting examples of non-standard uses of these opcodes in hardware and software (on MIDI 1.0 DIN cables and in other hardware and software contexts). Examples I've collected so far are: -- 0xF9 as "MIDI Tick" -- 0xF5 for both "MIDI endpoint" and "virtual cable" selection I'm doing this as part of the process of finishing: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt It uses the semantics of the commands as part of its resiliency scheme, and so knowledge of non-standard uses of the reserved commands is needed to help craft resiliency logic for the opcodes. Probably best to send the info directly to lazzaro(a)cs.berkeley.edu, the topic is too mundane for the list ... thanks in advance! ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------

22 years, 2 months

[linux-audio-dev] [ANN] creox 0.2.0

by Jozef Kosoru

Hi all, I would like to announce creox 0.2.0 - the realtime sound processor for KDE http://www.uid0.sk/zyzstar/?creox As Creox is a JACK application, the output sound can be routed to the other JACK-aware applications, and the audio input can be taken as the output from the other JACK client. -- jozef kosoru

22 years, 2 months

[linux-audio-dev] mutex in process callback?

by Lukas Degener

Hi LADs, here is a problem that maybe very common with many rt audio apps, so hopefully there is a "standard" solution for it? assume jack process callback reads audio data from a buffer, while another thread might alter the contents of this buffer. In my particular scenario, i will actualy use doublebuffering. So the only operation that needs to be "mutexed" is the actual swapping of front and back buffers (well, pointers, of course, not the contents) Now my problem is: How can i make sure that swapping does not accure during process (playback) callback? I could use a mutex, but this might also block the playback thread. (if swapping is in process when the jack callback is invoked) On the other hand, swapping pointers shouldn't take that long, so maybe this would not be a problem? Or would it make sense to try and "foresee" such a situation and avoid it by delaying the swapping? Any clever suggestions on this? Regards, Lukas

22 years, 2 months

[linux-audio-dev] FFTW3 (beta)

by Steve Harris

http://www.fftw.org/ Just a headsup for all the people who link against it. Hopefully they've normailised the build system now... Looks pretty good, now includes SIMD optimisations. - Steve

22 years, 2 months

[linux-audio-dev] Alternitif Bitkisel kanser ilaci Carctol Alternative Cancer Healing

by carctol2034＠yahoo.com

Eger kemoterapi yada radyoterapinin yan etkileri ile bogusan bir yakininiz varsa, �z�lmeyin ancak bitkisel kanser ilaci Carctol'u yakindan tanimak i�in zaman ayirarak asagidaki link'e tiklayin. http://www.kanser-tedavisi.com Listeden adinizin silinmesini istiyorsaniz a_cengiz2002(a)yahoo.com a bos e posta yollayin. Tesekk�rler Hello, if you have got an acquaintance or a friend who is suffering from the side effects of chemotherapy, please visit the site below to see the truths about alternative herb cancer medicine Carctol. http://www.kanser-tedavisi.com/English_homepage.html If you wish to be removed from our list, please send us an email at this address bilgi(a)kanser-tedavisi.com so that we may remove your name. Thank you.

22 years, 2 months

[linux-audio-dev] [ANN] Hydrogen 0.7.6

by Comix

Hi all, the 0.7.6 version of Hydrogen Gnu/Linux drum machine is available at http://hydrogen.sf.net Features: * Graphical user interface based on QT 3, * Sample based audio engine, * Oss Audio driver, * Jack Audio driver, * Export to disk audio driver, * Alsa Midi input, * Ability to import/export xml-based song file, * 64 ticks per pattern, * 16 voices with volume, mute, solo, pan capabilities, * Import of samples in wave, au, aiff format. * Humanize and swing functions Changes: * Bug fix in note velocity editor * Improved pattern editor * Humanize function * Swing function * New child frame interface * Stereo peak visualization in mixer * New song editor Happy drumming! ;) -- Alessandro <Comix> Cominu http://hydrogen.sf.net e-mail: comix(a)despammed.com Icq: 116354077 Linux User # 203765 [...Codito Ergo Sum...]

22 years, 2 months

[linux-audio-dev] Update -- 24-bit/192 KHz Portable DAT Replacement

by moskowit＠panix.com

We've posted an update about PDAudio (our new 24/192 portable digital audio recorder): http://www.core-sound.com/HighResRecorderNews.html Thanks to all for the high level of interest! -- Len Moskowitz PDAudio, Binaural Mics, Cables, DPA, M-Audio Core Sound http://www.stealthmicrophones.com Teaneck, New Jersey USA http://www.core-sound.com moskowit(a)core-sound.com Tel: 201-801-0812, FAX: 201-801-0912

22 years, 2 months

Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux

by Ranjit Singh

>> We're effectively talking about a driver for the Motorola DSP >> onboard (I can't remember what the no is.) >No, that stuff is "secret". The microcode is available only as raw >binaries, and the driver's job is to talk to the microcode; not the >hardware directly. So, we're talking about Linux kernel space only; >no DSP code. When you say "available as binaries" I take it that it's still running on board the card's ROM? (ie microcode implemented within the card, not the host.)

22 years, 2 months

[linux-audio-dev] Re: [jmax] Running a patch as a LADSPA plugin

by Steve Harris

[This is a conversation Francois and I have been having this morning. There is a general problem with LADSPA wrapper plugins that create plugins from other sources. Its not possible for them to pick unique IDs as they dont know what has been assigned and what hasn't] On Tue, Mar 18, 2003 at 10:14:44AM +0100, Francois Dechelle wrote: > > That reminds me, there was another issue that Thomas raised, theres > > currently no way to create a one-time unique LADSPA id, which I guess you > > would need for this to work reliably. > > Yes, it is something that I need. The problem is that the jmaxladspa > plugin is not a unique plugin: the number of plugins it defines is > variable (it is the number of .jmax files that are in LADSPA_PATH > directories). > > A temporary solution would be to allocate to the jMax plugin a range of > unique IDs and that no more than this range patches can be loaded. What > do you think about it? Thats OK as a quick fix, but it doesn't solve the broader problem, if you save state from a host using jMax LADSPA plugins then it wont necceserily be the same set when you reload. I think LADSPA needs self assigned ID's, if the UID space were bigger we could just reseve the top bit for self assigned stuff and hash unique strings to fill it, but as its only 32bits thats not enough space. > Apart from this solution, I don't see how to do it. Agreed, without a change to LADSPA I dont think its possible. One solution could be to use a reserved ID range to flag that the ID isn't globally unique, but the label string (not name) is, so hosts should save state aginst the label not the ID. It has very dodgy semantics though. A better solution would be to expand the ID space to 64bits, and reserve the top bit's worth, which is plenty, but will break binary compatibility of course. > Another question: is there a plan to get plugin port values that are not > floats? More precisely, I am thinking of transforming a patch that does > granular synthesis into a plugin. But this patch needs a sound file > name. How can I pass it to the LADSPA plugin? You can't. I think this is thought to be outside the remit of LADSPA. > BTW, do you think we should discuss this on jMax mailing list or on > linux-audio-dev? Yes, both probably, but I've forgotten what email address I subscribed to the jMax list with. I guess I should resubscribe. I'l CC this to l-a-d in the meantime. - Steve

22 years, 2 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