Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

by Lars Luthman

Dino is a MIDI sequencer for GNU/Linux that uses JACK MIDI and JACK transport to send MIDI events to synths and synchronise with other sequencers or transport aware programs. It uses LASH to save and restore sessions. This is the first release. Get it at http://dinoseq.sf.net . Requirements: * libglademm >= 2.4.1 * libxml++ >= 2.6.1 * JACK >= 0.100 with the MIDI patch available here: http://www.custard.org/~deviant/jack-midi/ * LASH >= 0.5.0 -- Lars Luthman PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E

19 years, 4 months

[linux-audio-dev] Preliminary spec for OpenGraphics soundcard

by spikethehobbitmage＠excite.com

I have gained much valuable insight from reading the posts from last month on Linux Audio Dev and OpenGraphics. I have tried to incorporate what wisdom I could. Someone wiser than I could greatly improve on this, of course. Hence this document. Low to mid-range markets are saturated. Buildable, but not likely saleable. Top end market is pretty tight. R&D budget for that level of gear is probably more than the video card project. Semi-pro is more doable. Best bet is an aggressive design to sell on performance and features. Most advanced features can be implemented in software, so the hardware should be fairly straight-forward, but it still needs good throughput. Target market Semi-pro audio (high end of target) High end gamers (mid range of target) Home theater (low end of target) Hobbyist -Hobbyist add-ons could greatly increase saleability to other markets US$300? price range for baseline system - this needs to be priced out 19" rackmount boxes may cost more. Mainly due to the sheer volume of good stuff that can be packed into them. see below. Features 192kHz @ 24bit inputs and outputs (48 bit fixed point internal) on board resampling/mixing sample rate bit depth # channels channel swap on board realtime compression/decompression/transcoding all analog I/O is in (shielded) breakout boxes more than one kind of box supported (including custom boxes) more than one box at a time supported breakout boxes may be up to 100m from host system MIDI 5.1 optical ADAT sound samples/effects may be preloaded to card and played/mixed on demand full 3D audio processing custom codecs and effects generators may be loaded on demand on board speech synthesis - just another codec :) on board speech recognition - same :) IR remote control? watchdog timer? Several people have voiced desire for 192kHz capability and have indicated media at this quality is available from some sources. Native sample capabilities 192kHz at 24 bit max - more than this would be overkill, and would hurt other capabilities without benefit 96kHz, 48kHz, 44100Hz, 22050Hz, 11025Hz for good measure -there is no point resampling to a higher rate unless you are going to mix with a higher rate source. digital resampling does not increase sound quality. -resampling from 44100 (CD audio) and lower to 48k or higher creates artifacts (not an even multiple) -more processing power/bandwidth is available for effects/additional channels at lower sample speeds. halving the sample rate doubles the processing power available per sample. 48 bit fixed point internal DSP for best accuracy all samples converted to 48 bit fixed point for internal processing -there should be no data loss from this conversion -if the hardware is efficient: -there should be negligible performance penalty for conversion -there should be no performance penalty for using the higher bit depth -simplified design if all DSP functions and codecs use the same format -downsampling from 48 to 24 bit for output is trivial if implemented in hardware World clock world master capable may also use external world clock -card can repeat clock to host system and breakout boxes if no dedicated world clock wiring is desired or possible, soft world clock may be implemented -ie card and each peripheral generate their own clock and a periodic sync signal is provided over data channel. see below. -unit may not be able to run at full speed due to timing constraints/clock skew in this case. not acceptable for live work, but OK for lower markets. Virtual back plane for maximum flexibility (any input may be mapped to any output with any filtering/effects) external effects box can therefore be patched in at any location, if desired volume controls are 10-12 bit analog inputs sample at 20Hz? volume control sampling does not need to be synchronized to any world clock mutes are 1 bit input arrays. same sampling as above. I/O card is purely digital all analog and most digital I/O is in breakout boxes. see below. Analog inputs and outputs are discrete from each other (no dual I/O jacks to toast a mic with) powered outputs are discrete from line outputs 1/8", 1/4", RCA, balanced XLR as appropriate inputs digitally controlled analog gain or preamp for each channel analog prefilters to reduce digital aliasing digital post filter? (cropping excess digital bits is trivial) outputs digitally controlled output gain or postamp 5th or 7th order Bessel filters standard Digital optical S/PDIF in and out (5.1 audio) ADAT (lightpipe) in and out (8 channel, optical) does anybody have specs on this? how hard is it to get interface hardware? cost? licencing? (this is an open design, so this could be an issue) MIDI CD digital audio in/out (2 channel, 16 bit, 44100, twisted pair) this would be on-card, if provided could be used to link to other cards Breakout Boxes more than one type of box should be supportable 5 1/4" internal/external box? cheapest to build shielded for internal mounting line in/line out/mic/headphone/IR/MIDI 5.1 line out? volume control input may only need 100baseT if bandwidth isn't a problem 9" (approx) external box home theater/gamer 5.1 analog and optical in/out 5.1 analog speaker out (power amp) (5.1 analogs can be configured as 3 stereo pairs, or 6 mono) IR/MIDI/mic/headphone software controlled AM/FM radio tuner? LCD display? digital spectrum analyzer display? 19" rack mount (someone with experience could probably give better layout) I/O patch board 60-80 ports 1/4", balanced XLR (with switchable phantom power), headphone 1-2 volume controls per column ADAT in/out MIDI world clock in/out 1000baseT Control box 8-16 ports 1/4", XLR (with switchable phantom power), headphone ADAT in/out MIDI world clock in/out 32 volume control sliders with mutes (2 banks of 16) 4 master volume sliders with mutes (same as above, just labelled differently?) knob switches? (to select option or backplane presets, etc) 2 16 pos switches could be encoded in a byte or 4 4 pos switches, etc digital spectrum analyzer display? (also a programmable output) -this would suggest an equalizer somewhere would be in order too :) peak/RMS volume readouts? (which they are is a setting) 1000baseT more than one box at a time should be supported master can command boxes to forward streams to each other directly? multi master? ie more than one card connected to a group of breakout boxes and each other more complex design allows cards to talk to each other directly or share I/O resources 1000baseT connection NOT TCP/IP or IPv6 - should NOT be WAN routable don't need the extra overhead somebody is going to want to use the same switch their internet connection goes through.... all analog audio channels are 24 bit volume control channels are 10-12 bit mute controls are bit arrays requires in-box microcontroller as much work as possible should be done in hardware minimal processing requirements due to simple protocol ECC encode/decode/fixup is a large part of workload no DSP capability, other than perhaps hardware filters any digital filtering should be done by Master unit simple remote commands box detection broadcast (true PnP) per channel input signal forwarding (either to output on same box, output on other box, or to Master) world clock mode selection set gain controls box identification manufacturer model serial number(optional) I/O count/descriptions read current settings main load is data stream latch and marshal input signals for transmit (controlled by world clock) unmarshal packets to output signal latches 2 stage latch stepped by world clock lesser load is volume/mute update stream. same profile, just lower bandwidth I/O bandwidth 192kHz at 24bit is 576000 B/s 48kHz at 24bit is 144000 B/s max channels for 24 bit audio 192kHz 48kHz 10baseT 1 6 100baseT 17 69 Firewire 69 277 (400MHz) 1000baseT 173 694 100MHz could barely handle 17 channels @ 192kHz if you add ECC (usually a good idea) it would be even less Firewire can handle up to 69 channels (less for ECC), but protocols/drivers are a mess -how much does firewire hardware cost compared to 1000baseT? how to get? -Firewire2 at 800MHz might be a possibility, but again, cost/availability? Master Unit 1/2 height 1/2 length card PCI or PCIe form factor PCIe should be main focus offers higher bandwidth/lower latency than PCI common on newer machines by the time this gets to market, this will be the dominant standard x1 should be fast enough PCI provided for legacy support large current install base limited lifetime 1000baseT external connector 100 or 1000baseT internal connector (depending on cost and whether the 5 1/4" box needs 1000baseT) world clock in/out (to connect to another card in the same computer) ADAT I/O? 5.1 optical out? RAM 32-64 MB (128?) DDR dual channel? CPU 200MHz minimum can we do 300MHz, or even 400? overclockable with active cooling? 3rd party fan/water cooling mounts dual core? RISC like instruction set 48 bit fixed point DSP instructions or DSP farm 8-32 bit integer math (48 bit integer math?) bitwise functions should be efficient for compression/decompression using various codecs 32 bit address path so memory is upgradeable just by modifying the PCB I/O controls/registers should be separate bus, so memory map is linear minimal onboard boot loader, if required. all software is loaded from host system separate data and instruction L1 caches MMU so codecs run in own memory, don't direct have access to hardware necessary for buggy or untrusted codecs DMA to access host computer memory accelerated task switching multiple register files? OS embedded Linux to start with (at least until design is proofed) a true RTOS would be preferable multi-tasking SMP capable if CPU is dual core zero copy IO for performance will take a while to write :P maybe hack Linux? that is what it is for, after all on board watchdog timer? good if she locks up can be used as host computer watchdog timer as well hardware random # generator? can be used for white noise production 3 profiles of signal handling Live this is usually going from an analog input to an analog output highest priority in processing minimal buffering to reduce delay needs to be < 20ms, even if signal is passed through card more than once eg input -> card -> external effects box -> card -> output) this puts the highest load on the card critical for audiophiles may be important for gamers and hobbyists minimal importance for home theater Real-time this could be recording or playback precise timing is only necessary at source or output, respectively double buffering to improve efficiency is an asset even 500ms delay playing an MP3 doesn't matter. prebuffering several seconds wouldn't hurt anything either. video sync isn't affected if the timing signal back to the computer is generated AFTER the decompression codec output buffer double (or more) buffering during recording is critical to prevent data loss, especially if the audio is being compressed in real time Transcode lowest priority - this could be done entirely using time left over from the other operations buffering to improve efficiency is an must delay, clock skew, etc don't matter could be used with non-audio data with appropriate codecs (SETI at HOME, anyone?) If I have missed or messed up anything, that is just me being me. Please feel free to correct/mock/browbeat as appropriate. :) _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web!

19 years, 4 months

[linux-audio-dev] Preliminary spec for OpenGraphics soundcard

by spikethehobbitmage＠excite.com

Steve, > I think you mean Word Clock. you are probably right. > IIRC it's not an open design. It's owned by Alesis. That may or may not be a problem depending on their licencing requirments. Esben, No need to be sorry :) If 192kHz is to high we can always slow it down. 96 or 48 would allow more processing power to be used for other things. James, I want one too :) _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web!

19 years, 4 months

[linux-audio-dev] first ladspa2 example?

by Julien Claassen

Hi everyone! I think, I heard, that someone already did some preliminary example for ladspa2. Am I right there? If so, where can I find it? Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net - the Linux TextBased Studio guide

19 years, 4 months

[linux-audio-dev] LADSPA 2

by Steve Harris

Almost two years ago at the LA conference a bunch of us agreed that something need to be done to improve LADSPA, and on the approximate direction it should take. Anyway, I finally got round to making a sketch plugin and .h file: http://plugin.org.uk/ladspa2/ The .ladspa2 plugin is a "bundle", ie. a directory with all the data the plugin needs in it. This idea is nicked from OPENSTEP. I'm not 100% convinced it's a good idea, but I think it makes sense for plugins. The dsp core (amp.c) is just a LADSPA 1.1 plugin with all the fixed data fields taken out, and a URI field added, to allow for working identification. I also dropped the runAdding method, as I dont think it is used enough to justify the effort of supporting it. The plugin is untested, but it compiles and nm reports sane contents for it. The data is in the amp.ttl file (it's in Turtle http://www.dajobe.org/2004/01/turtle/ an easy to hand-write RDF syntax). We could mandate a particular syntax for the spec. There's a shell script (show-data.sh) which, if you have raptor and rasqal installed will do something similar to what analyseplugin does for LADSPA 1.x, but it's very crude. Overall I think this is a much better approach than LADSPA 1.x, it has usable identifiers, a clear route for extensions without compatibility problems and each plugin is quite a lot simpler. - Steve

19 years, 4 months

[linux-audio-dev] NAB trade show

by Ben Loftis

I am going to be at the NAB show in Las Vegas this week. Any other LAD's planning to be there? -Ben Loftis

19 years, 4 months

[linux-audio-dev] LADSPA Repository

by Patrick Shirkey

Hi, It is widely felt that the LADSPA plugins are becoming difficult for average users to manage due to the number of available plugins and the many different packages available. There is also a problem that developers face when managing different plugins as UniqueIds are not assigned by a central authority so it is possible that there can be double ups. I am volunteering my time to code a new web portal with the express purpose of providing a single place to get all known LADSPA plugins and packages. It will be hosted at ladspa.linuxaudio.org. it will also serve as a central automated authority for assigning UniqueIds. I would like to use this thread to discuss the finer details of the functionality of the site and how to make a package of all Plugins which will also be hosted on the site. The site will be run with a MYSQL DB. I intend to code it in AJAX style with a PHP+MYSQL backend. It will be a fully automated web portal and administrative interface. Here are the features: --------------- - Add new plugin/s via batch or manual upload/insert - Automated assigning of UniqueIds - Create complete package tarball automatically - Administrative interface for managing plugins and developer profiles etc... - User friendly frontend with accessibility: css, java, php, html, xml ---------------- I will appreciate your indepth analysis of the best methods to allow the above features for the portal. At this stage the most important points to discuss are how to manage the plugins efficiently and with minimal overhead and assigning UniqueIds automatically. Cheers. -- Patrick Shirkey - Boost Hardware Ltd. Http://www.boosthardware.com Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide ======================================== "Anything your mind can see you can manifest physically, then it will become reality" - Macka B

19 years, 4 months

[linux-audio-dev] Re: "LADSPA 2" name

by Kjetil S. Matheussen

Steve Harris: > > Several people have suggested that LADSPA is not a great name for what we > are calling LADSPA 2. Reasons for this include: > > The L, it's not really linux specific, and though /we/ know that its the L > of LAD, its not obvious to people outside. > > The S, it ain't really going to be simple. For someone like me, who is > neck deep in triples on a daily basis, 2.0 seems like the paragon of > simplicity, but I can imagine 2.9 being quite a beast. > > LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy. > > 2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary > incompatible. I'm not sure everyone thinks in major and minor revisions. > > So, with some trepidation I suggest that we think about naming, with the > proviso that if we haven't reached consensus by May 10th we default to > LADSPA 2.0, and live with the pain. > I don't agree about taking away the "L". Ladspa is not linux-specific, but it has certainly originated from linux, and has the best support in linux software. If linux dissapears before the ladspa format, we can at least still remember linux through the name of ladspa... Regarding your argumentation about the prononounciation, I think its a bit anglocentric language-vice. In most other countries (scandinavian, german, spanish, belgian, dutch, slavic (I might be wrong about some of these though)), where the "a" is actually pronounced like the round "ah" (and very short in this case), and you don't have to move the mouth that much as in english (and especially in american english), "ladspa" sounds really cool and is not very difficult to say. A good solution to this problem would be if the english speakers started to allways say the more common rounder "ah" instead of "a", not only for ladspa, but for all acronyms. I think the argument about S is valid enough though, but not a good enough argument to change a name we all have learned and love(?). As an alternative, we can change the meaning of s into something else, like Super, Second, Sophisticated, System, Steve, Sourcecode, Syntax, Structure, Success, Superb, Superior. To name a few, well, I'm sure there are better alternatives. > ---- > > My suggestion is that we ressurect the XAP name > (http://www.google.com/search?q=lad+xap) > It stood for Xap Audio Plugin IIRC. > > Pros: it's short*, relatively unused** and pronouncable*** > > Cons: xap.{com,org,net} will have gone long ago (too short), theres a > small ammount of baggage. > I think its too short. Its not cool, and its hard to remember from the pronounciation.

19 years, 4 months

[linux-audio-dev] [ANN] libgig 3.0.0

by Christian Schoenebeck

Hi! Usually I don't announce new versions of libgig here anymore, but this release might be of interest for some: Beside a bunch of bug fixes it now also allows to modify existing and create new Gigasampler files. If anybody's interested in writing a .gig editor, have a look at the "gigwritedemo.cpp" example application: http://stud.hs-heilbronn.de/~cschoene/projects/libgig/#examples libgig is released under (pure) GPL and as always available on its original site: http://stud.hs-heilbronn.de/~cschoene/projects/libgig/ as well as on the LS server: http://www.linuxsampler.org/downloads.html http://download.linuxsampler.org/packages/ CU Christian P.S. I just restored the old libgig source packages on the LS server, all other packages will be restored after LAC (that is next week) - I know the downloads section on LS.org was dead for too long now, sorry!

19 years, 4 months

[linux-audio-dev] LADSPA2 name early consensus

by Steve Harris

OK, it seems like the consensus is clear to me. So far, most people want to use/keep LADSPA2. I ran it through a condorcet program, just to make sure, but it't not in doubt. FWIW, by my count the pure "acceptable" numbers came out as: 17 ladspa2 7 xap 6 peep 5 apa 4 sax 4 plux 3 rap 2 peeper 2 eep 1 wasap 1 sap 1 pea 1 openplux 1 lapa 1 fap 1 clap 1 chap And the condorcet pattern was: 9 ladspa2 1 ladspa2>apa>sax 1 ladspa2>plux 1 ladspa2>sap>xap>peep>peeper>sax>fap>eep>clap>chap>apa>rap>pea>wasap>rap 1 ladspa2>lapa>plux>xap 1 openplux>plux>ladspa2 1 peep 1 peeper>peep>apa 1 plux>apa>ladspa2 1 sax>eep>xap 1 xap>apa>ladspa2 1 xap>peep 1 xap>rap>peep 1 xap>sax>peep>ladspa2 Only 23% of those voters would find LADSPA2 unacceptable, next best is XAP which 68% would find unacceptable. I wasn't especially rigourous, so I may have missed, or misinterpreted someones vote. Someone could poll the LAU list if they felt inclined. I think that we should give the people who's names appear on the original .h file a veto, as were doing some radical changes to the design - though hopefully still in the spirit of the original. It doesn't look like we'd ever reach consensus on any other name though. *sigh* I guess I should invest in an anti-RSI keyboard. - Steve

19 years, 4 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