Linux-audio-dev November 2007

linux-audio-dev@lists.linuxaudio.org

41 participants
27 discussions

Re: [LAD] "enhanced event port" LV2 extension proposal

by Krzysztof Foltman

Dave Robillard wrote: > Why not make it satisfy most everyone by being extensible? It *is* extensible. Note that commands 0x00-0x6F and 0x73-0x7F are unused, so further extensions are free to define them (perhaps we need a scheme for binding extension URIs to command numbers, to make it more LV2-ey). And 0x72 command can be used for pretty much any data larger than 8+2 octets. While it's "efficient first" and not "generic first", so to speak, it should be fine for the intended uses. > The idea of a generic event port is not a bad one, I think it's not just "not a bad one". The other possibility (multiple event ports) is less efficient, and speed is crucial here. It's also more complex, looking from plugin author's perspective. So I had little choice. > idea at all (no matter what, someone is going to want to put something > in there you didn't think of. Please don't jump to conclusions, and take more time to read and analyse the proposal. Of course, it is possible to add new event types with arbitrary length data, and the limitation of 8 octets per extended block is not that bad, because you can always fit an interface pointer (32-bit or 64-bit) there. Just look how binary data extension is implemented. Notice that I just took the approach of optimizing for most common case (MIDI events), and tried to maximize functionality while keeping block size small and constant (to avoid pointer arithmetic that was complicating Lars' proposal a bit). > Trying to pre-define things from the top down like this is un-lv2-ey). Well, sometimes you need to find the right tradeoff between being efficient (memory- and speed-wise) and generic. I think I've found an acceptable tradeoff (definitely favouring speed, but not losing generality and not very memory-hungry). However, I had to make some assumptions about how it will be used (mostly implemented by inexperienced people, mostly used for MIDI and float parameters, seldom used for advanced stuff). Oh well, I'm repeating myself here :) I think those are correct assumptions, but you seem to have a different angle for looking at those things. Well, it took me years (and failed/inadequate designs) to grow out of the "everything should be as generic as possible" approach, so I understand why you're doing that, but I still prefer the priority-based optimization approach that I've used. I still think my proposal could be improved, and I don't like some decisions that I made (basically, I made them because the alternatives looked even more nasty), but stripping off optimizations is not the way to go, IMO. > Something more appropriate (IMO) might be like: > struct LV2_EVENT > { > ev_stamp_t time; ///< (ignoring the timestamp type issue) > ev_type_t type; ///< (again ignoring type issue) > size_t buf_size; ///< size of buf in bytes > char* buf; ///< raw event data > } You're suggesting a "classic" textbook chunked data approach, which works, no doubt. However, it has some problems with it, which might not be considered very major, but seem to make my approach slightly more favourable: - too much data to be accessed in the most common use case (in 32-bit environment, 16 bytes of header plus event data possibly in distant memory); we don't need to save every byte of RAM, but when you need to read and write twice as much RAM as you could, then maybe it's worth rethinking it - separation of event header and event data in the most common case; it would be better not to cause cache thrashing too much - it encourages memory fragmentation (experienced people will allocate event data for all events in the same buffer, wonder about inexperienced ones, one malloc per event data? :) ) - it doesn't deal with large data properly (because the plugin cannot start "owning" the raw event data instead of copying it from the buffer provided); imagine copying a video buffer in the process() function of a plugin! I'm not saying that approach is Really Bad - just that it's kind of a pre-optimization version of my proposal (I made MIDI data very efficient, float parameter data slightly less efficient, float parameter data with deltas even less efficient, and binary data are pretty inefficient :) ). The fact that event has to be handled is annoying enough on its own :) - I have to end the inner loop, store state information somewhere etc. - I don't want some additional, unnecessary memory accesses which may throw sample data and buffers out of the cache. > (Obviously just a quick generic knock-off to get the idea across). In > networkey terms, this is separating transport from contents, which is > pretty firmly established as a Good Idea. In network context, yes. However, _optimizing_ for uncommon case is not a preferable approach to me. The arbitrary binary data command (0x72) mentioned in my proposal can give you practically everything you need, and can be used in a network-transparent way, as long as data in the "binary data" chunks are self-contained (don't refer to other buffers). However, my proposal lacks any mechanism to be used for serializing arguments of future commands defined by extensions. Still, that problem was solved many times in history, by deriving extra interfaces for the new commands from an interface that provides reference counting and marshalling. IPersistStream type stuff, for the victims of Microsoft APIs. It is a bit complex (or at least not as trivial as plain MIDI), but it would be only used in hosts and complex plugins that use extension events, so I guess it'd be fine. > I very strongly feel that if 'more than MIDI' events are going to be > mixed with MIDI events in the same port (s/MIDI/whatever), then the > event transport mechanism needs to be 100% event type agnostic. On the other hand, "100% generic" means "almost 100% unoptimized". By throwing away extra information, you often throw away the chances for optimization, so to speak. Instead of thinking in terms of MIDI vs non-MIDI, try thinking of "my" event types as "short" (8 octets), "medium" (16 octets) and "large" (arbitrary-sized blobs). The fact that all short events are MIDI events is, I think, less important. It's also not set in stone. > It's the same approach LV2 takes with ports, and it works beautifully there. On the other hand, it deals with a trivial problem, and solves it in a complex way. That's not an engineer's dream :) Regards, Krzysztof

17 years, 1 month

Re: [LAD] "enhanced event port" LV2 extension proposal

by Jeff McClintock

> However, it (MIDI) also has its own age. And limitations. In particular, the > amount of per-note control is pitiful. > .... In the meantime, maybe the MIDI guys will decide for us :D They did, "Key Based Instrument Controllers" provide for per-note controllers. Granted MIDI remains stupid. MIDI is 15 different ways of saying "set this control". All of MIDI can be reduced to two messages: set-control (addressed by Channel, Voice and Controller ID) .. and SYSEX - for data-dumps. Jeff McClintock Message: 13 Date: Fri, 30 Nov 2007 00:30:58 +0000 From: Krzysztof Foltman <wdev(a)foltman.com> Subject: Re: [LAD] "enhanced event port" LV2 extension proposal To: Dave Robillard <drobilla(a)connect.carleton.ca>, LAD <linux-audio-dev(a)lists.linuxaudio.org> Message-ID: <474F59C2.1050805(a)foltman.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Dave Robillard wrote: > I /really/ don't like screwing around with MIDI. Just make the events > pure, raw MIDI. Jack MIDI events are 'just n bytes of MIDI', Alsa has > functions to get at 'just n bytes of MIDI', and... well, it's just MIDI. > However, it also has its own age. And limitations. In particular, the amount of per-note control is pitiful. I can always use hacks to get around the limitations, or introduce a per-note control via separate "set note parameter" event type. But hacks are ... hacky, and the extended extension of extension for every single feature is a bit inelegant too. Anyway - so far, I have no code that would make use of this, so we might keep it as plain MIDI. And then we have next 5 years to decide the details of the feature. In the meantime, maybe the MIDI guys will decide for us :D Krzysztof

17 years, 1 month

Ladspa plugin invisible

by Rémi Thébault

Hi I'm trying to make a guitar tuner ladspa plugin. I already wrote a first draft, but listplugins can't find my plugin in the library : $ listplugins ... /usr/lib/ladspa/TunerUnit.so: <--- /usr/lib/ladspa/tap_doubler.so: ... it could be because I've chosen a uniqueID already in use. is there a list or way to register a uniqueID ? here is a part of my _init() function: g_psTUDescriptor->UniqueID = 4053; g_psTUDescriptor->Label = strdup("tner"); g_psTUDescriptor->Properties = LADSPA_PROPERTY_HARD_RT_CAPABLE; g_psTUDescriptor->Name = strdup("Universal Digital Tuner Unit"); g_psTUDescriptor->Maker = strdup("Rémi Thébault"); g_psTUDescriptor->Copyright = strdup("None"); By the way, for the moment I use FFTW for the frequency identification. Is there a way to identify a frequency with quite high precision without computing a big spectrum analysis ? For a 0.7 Hz precision with fft, I need 65536 samples, what will take a lot CPU load every 1.5 sec. It is obvious that so much CPU Load is no acceptable for a small plugin in a realtime application. Rémi

17 years, 1 month

Re: [LAD] "enhanced event port" LV2 extension proposal

by David Olofson

On Friday 30 November 2007, Dave Robillard wrote: > > That's why I'm using a Port as the smallest "connection unit", > > much like LADSPA ports, so there is no need for an event type > > field of any kind at all, let alone a URI. > > Ports /are/ the smallest "connection unit". But ports can /contain/ > events, and if we want multiple kinds of events in a single port, > then the events themselves need a type field. Sounds like there's a fundamental difference there, then. I'm using a model where a port is nothing more than something that deals with a value of some sort. There are no channels, voices, different events or anything "inside" a port - just a value. An output port can "operate" that value of a compatible input port. Of course, that "value" could be anything, but I'm not explicitly supporting that on the API level. If plugins want to use MIDI messages, they're on their own when it comes to mapping of channels, CCs etc. That stuff is really beyond the scope of my project, as one wouldn't be able to configure and control such things normally. > > The data in the events *could* be MIDI or whatever (the host > > doesn't even have to understand any of it), but normally, in the > > case of Audiality 2, it'll be modular synth style ramped control > > events. That is, one port controls exactly one value - just like > > in LADSPA, only using timestamped events with ramping info instead > > of one value per buffer. > > The host might not have to (though in practise it usually does), but > other plugins certainly do. You can't process events if you don't > even know what they are. Yes, obviously. I don't quite see what you think I'm trying to say here. :-) > > Extensibility is a non-issue on this level. > > OK, the event extension doesn't define your ramped control events, > so you're not allowed to use them, ever, period. > > ... looks like extensibility is an issue at this level, eh? ;) Right, but that's mostly about Audiality 2 anyway. There, if I for some reason started with control events without ramping, I'd add another "control events v2" port type. If that type happens to be a superset of the first one doesn't really matter, as they're still not compatible. Where it makes sense, one can provide converters to/from other types, but to the host (the low level machinery directly dealing with plugin graphs, that is), those are just ordinary plugins with only one input port and one output port. > > What you do if you want > > more stuff is just grab another URI for a new event based > > protocol, and you get to start over with a fresh event struct to > > use in whatever way you like. (In fact, as it is, the host doesn't > > even have to know you'll be using events. It just provides a LIFO > > pool of events for any plugins that might need it.) > > Sounds like you're thinking too hard. Nah. I'm just in the middle of another project, and the Audiality 2 code isn't in a state where I could post that without just adding to the confusion. And, I think we might have a terminology impedance mismatch. :-) > "Events" here are just a bunch of bytes in a flat buffer. Mine are implemented as linked lists of small memory blocks, for various reasons. (I've had a working implementation for years, so I'll stick with that for now. Not saying it's the best or most efficient way of doing it, but I have yet to figure out how to bend flat buffers around my event routing model - or the other way around.) I did "hardwire" fixed point timestamps as those are closely related to the whole deal with sample frames, buffers etc - but the data area is indeed just a bunch of raw bytes. > There is definitely no protocol here. Please, please don't > say "protocol". That way lies painful digressed conversations, > trust me. I'm open to alternative terminology. :-) What I'm talking about is just the name of "whatever goes on between connected ports." I don't want the term to be too specific, as it also covers LADSPA style audio buffers, shared buffers (which can contain function pointers) and whatever else plugins might use to communicate. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

17 years, 1 month

[ANN] FreeBoB: libfreebob-1.0.7 released

by Pieter Palmers

Hi, A fresh new release from the FreeBoB project is available. It is only a maintenance release. It fixes a few bugs which were reported. If you don't have problems with the your current version of libfreebob, there is no reason to update to this one. Available through the SourceForge release system at: http://sourceforge.net/project/showfiles.php?group_id=117802 Have fun recording! The FreeBoB Team PS: Expect FFADO soon...

17 years, 1 month

[ANN] FreeBoB: libfreebob-1.0.7 released

by Pieter Palmers

17 years, 1 month

portmidi and alsa

by James Stone

Hi there, This may be a very simple question, I am not sure. I am hacking on a buzz-like tracker, aldrin. It is written in Python, but the heavy lifting is done by libzzub, which uses portmidi for midi implementation. At the moment, midi in devices can be selected, midi out are a bit buggy, but I think that should not be too difficult to sort out. The main problem which I would like help with, is that the midi inputs and outputs from aldrin do not show up in with aconnect -lo or -li at all.. Is it possible to get portmidi to work with alsa correctly in this way, or are midi connections always handled within the program, connecting to alsa devices, but invisible to aconnect? The source for both projects is at: http://trac.zeitherrschaft.org/aldrin/browser http://trac.zeitherrschaft.org/zzub/browser All the best, James

17 years, 1 month

ethernet audio device driver developer wanted

by Paul Davis

I am looking for someone with device driver experience to implement an audio-over-ethernet protocol on Linux. This is a short-term paid position; the license and basic architecture of the driver is not yet decided. If you're interested, get in touch with me. thanks, --p

17 years, 1 month

"enhanced event port" LV2 extension proposal

by Krzysztof Foltman

Hello all, A few weeks ago there was a discussion about proposed enhancements to Lars Luthman's LV2 MIDI port extension (lv2-midiport.h). I've read the suggestions that you gave, and tried to hack together a new version, that would enhance the initial standard that Lars designed, by: - addressing alignment-related issues - using fixed-point integers for time values - adding optional sub-channel addressing (for per-note control changes and similar features) - optionally allowing sending floating point automation events in the same stream as MIDI events (because mixing several event streams at the same time is inefficient) - optionally allowing sending arbitrary data (similar to SysEx, but fully binary safe and without having to pay to register at MMA :) ) - trying to keep it simple, efficient and easy to implement Finding the right compromise is often an impossible task, so it won't probably satisfy everyone. However, I think its advantages outweight those of its drawbacks and limitations that I can currently see. The basic MIDI-type events can be passed with minimal effort, however, the more advanced features require more effort if you want to make use of them (though they may be safely ignored). Here we go - treat it as pseudocode sketch meant to get more feedback from you, not as the compilable C code (that's why there is no license or copyrights attached, in case anybody's wondering). In fact, there's no actual *code* (as in: anything that translates into CPU instructions) here, just data structures and declarations. Also, because it is not meant to be actually used at this stage, I'm not assigning it any URI. // data structures for proposed "enhanced event port" extension of LV2 audio plugin standard // loosely based on Lars Luthman's lv2-midiport.h; most ideas come from people on // linux-audio-developers mailing list (David Olofson, Lars Luthman, Stefan Westerfeld, // Nedko Arnaudov and others) // base event structure // size: 8 octets // if command < 0x80, one more 8-octet structure follows; the type of that // structure is dependent on value of command // the plugin that does not understand the given command can safely skip the next 8 bytes struct LV2_EVENT_HEADER { uint32_t timestamp; ///< fixed-point timestamp with 16 integer and 16 fractional bits; use of fractional part is optional uint8_t command; ///< command byte - >= 0x80 for MIDI commands, <0x80 for 16-octet extended commands uint8_t arg1; ///< for MIDI commands that need it; should be 0 otherwise uint8_t arg2; ///< for MIDI commands that need it; should be 0 otherwise uint8_t subchannel; ///< optional, allows for control changes for specific notes; writer must set to 0 if not used }; // buffer of events, analogous to LV2_MIDI structure in Lars Luthman's extension struct LV2_EVENT_BUFFER { LV2_EVENT_HEADER *first; ///< pointer to the first event, the next ones (if any) follow it directly uint32_t event_count; ///< number of events in the buffer uint32_t block_count; ///< buffer size (current or max, depending on if it's input or output buffer) in 8-octet blocks }; // the features below are optional and may be ignored by skipping the 8-octet extension block // optional command 0x70: set parameter struct LV2_EVENT_EXT_FLOAT { uint32_t lv2_ctl_port; float new_value; }; // feel _encouraged_ to ignore everything below this line ;) // advanced optional command 0x71: set parameter delta // specifies that until the next event the parameter // is supposed to increase linearly by new_value_delta each sample // this is for super-precise envelopes and other insane paranoid stuff :) struct LV2_EVENT_EXT_FLOAT_DELTA { uint32_t lv2_ctl_port; float new_value_delta; }; struct LV2_BINARY_BUFFER; struct LV2_BINARY_BUFFER_FUNCTIONS { // increase reference count and return data pointer const char *(*ref_inc)(struct LV2_BINARY_BUFFER *self); // decrease reference count void (*ref_dec)(struct LV2_BINARY_BUFFER *self); // get event type URI or MIME type const char *(*get_type)(struct LV2_BINARY_BUFFER *self); // get string encoding (if applicable) const char *(*get_encoding)(struct LV2_BINARY_BUFFER *self); }; struct LV2_BINARY_BUFFER { // pointer analogous to virtual method table pointer LV2_BINARY_BUFFER_FUNCS *funcs; // length of data in octets uint32_t length; }; // advanced optional command 0x72: data block // in order to get to the data, ref_inc must be used before // process function ends (and then use ref_dec to free the data) // otherwise host will free or reuse it to avoid leaks struct LV2_EVENT_EXT_BINARY { union { uint64_t pad; // padding so that the structure is 64 bits long LV2_BINARY_BUFFER *bb; }; }; --- Have fun :) Krzysztof

17 years, 1 month

..._1913.xml: No such file or...

by james jwm-art net

Hello again, I've coded a module to use the fast_lookahead_limiter plugin. Upon using the LADSPA plugin's run function, it segfaults. gdb reveals: (gdb) step runFastLookaheadLimiter (instance=0x80de1d8, sample_count=1) at fast_lookahead_limiter_1913.xml:79 79 fast_lookahead_limiter_1913.xml: No such file or directory. in fast_lookahead_limiter_1913.xml Current language: auto; currently c --- I can't find any information about this. I don't understand or know why it needs to access the xml file. I don't what I am meant to do to make sure it finds it, or even where it's meant to be. There was no such problem implementing GLAME Butterworth filters. How I'm meant to tell? Cheers, James.

17 years, 1 month

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 November 2007