Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Sampo Savolainen

Quoting Esben Stien <b0ef(a)esben-stien.name>: > Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes: > > > LV2 > > What happened to the funny recursive acronyms?;). That they don't show > up in a google search don't hold water; f.ex a search for JACK get > you.. our beloved, sacred one. > > How about a girlie name to accompany JACK, then?;) How about both recursive and a girlie name? BELLA = BELLA Effects Layer for Linux Audio (B could also be Bitchin') Sampo

19 years, 7 months

[linux-audio-dev] "LADSPA2" naming redux

by Steve Harris

Richard's preferred name of "PEA" (AKA anything that's not LADSPA2) got me to thinking. What about abstracting it up one level and calling the directory + .so files + manifest thing a POD (Plugin Object and Description). Theres nothing particularly audio specific about the high level construct, its "just" that we don't have a concrete ABI for dealing with sills, video etc. This means that what we think of as a "LADSPA2" plugin would be a "LADSPA POD". The directory would have a .pod extension. POD seems like a nice word to me, plenty of scope for puns, short and "pod plugin" on google doesn't come up with anything much. The only audio related things for "pod" I could see are: a guitar effects processor called a PODxt (there was a POD historically), an audio I/O device called a Firepod, and the documentation for the LADSPA Perl module. Perl docs are the only non-coincidental hits for "LADSPA POD". I could juggle the description stuff around the seperate pod-ness from ladspa-ness, it's not hard, but also not neccesary. There is a small name clash with Perl, which uses .pod for it's documentation format, but I dont think that's really an issue, our .pods will be found in POD_PATH (eg. /usr/lib/pod/, ~/.pod/) and be will be directories. Thoughts? - Steve

19 years, 7 months

[linux-audio-dev] Re: NAB trade show

by Juhana Sadeharju

Anyone took photos at the show? Dieter Meier of Yello was in Avid's booth if I understood correctly. Dieter Meier is a member of board at Euphonix and perhaps now has business with Avid too. http://www.euphonix.com/news/news2002/021202_dieter_interview.htm A few guys at the Yello list visited the show but they had no camera with them. :-( Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

19 years, 7 months

[linux-audio-dev] Re: NAB trade show

by Ben Loftis

> > So what did you see? > Not much honestly. Digi was demo'ing the new version of PT but they are just playing catchup with the innovative companies at this point. The coolest thing at the show was definitely Ardour, which we were using as a playback and recording machine for our mixing consoles. > One this I've been wondering is how do the 5.1 upmix boxes work? The > ones that take in stereo and convert it to surround sound. The sales There are infinite ways to do this and none of them make the music sound better than stereo. OK I guess "better" is subjective but there's certainly no "correct" way to do it. You can easily derive a center/sub channel but most systems do something hideous when it comes to the rear channels. -Ben Loftis www.harrisonconsoles.com

19 years, 7 months

[linux-audio-dev] CLAM Music Annotator 0.3.1 released

by Pau Arumi

May 8th 2006, CLAM Music Annotator 0.3.1 released What is the CLAM Music Annotator? --------------------------------- Is an application of the CLAM framework [1] that can be used to visualise, check and modify music information extracted from audio: low level features, note segmentation, chords, structure... The tool is intended to be useful for (though not limited to) the music information retrieval research whenever you need to: - Supervise and correct the results of automated audio feature extraction algorithms - Generate manually edited annotations of audio as training examples or ground truth for those algorithms. You can learn more about Music Annotator in its wiki page, which includes screenshots and videos galleries: http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator The application comes with two example extractors. One that computes low level descriptors and another that performs chord detection. It also features useful views such as the "tonnetz" and "key space" to visualise the tonal features (chords, notes...) CLAM Music Annotator is GPL. What's new from last (0.2) version ? ------------------------------------ This is a major release which have at least duplicated the number of important features. - Ported to Qt4 - New chord extractor - Colourful animated visualisations - Improved application work-flow (project building, etc.) - It also works as a collaborative annotation tool (BOCA client) See the changelog [2] for a complete list of changes. or the wiki [3] for general information. How to install it? ------------------ In Windows we provide a binary installer which includes all the needed libraries (including Qt4) and ready-to-use sample data. For Linux and Mac OSX we don't provide binaries at this moment (though we plan to do in short). Source tarballs can be downloaded from the web and complete build instructions can be found in the INSTALL file. http://clam.iua.upf.edu/download.html Acknowledgements ----------------- This project is partially founded by SIMAC European Project, IST-507142 and Catalunya's Government, exp 200/05 ST The chord extractor extracts segments labeled with chords. It uses Christopher Harte algorithm with some minor variations. It has been developed as a collaboration between the Queen Mary University of London and the Universitat Pompeu Fabra (UPF) of Barcelona. The "keyspace" view is a great contribution of Jordi Bonada and Emilia Gomez, at UPF. The CLAM team Music Tecnology Group Universitat Pompeu Fabra (Barcelona) References: 1. http://clam.iua.upf.edu 2. http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator_Changelog 3. http://iua-share.upf.es/wikis/clam/index.php/Music_Annotator

19 years, 7 months

[linux-audio-dev] n00b friendly latency tester

by Lee Revell

After some discussions at LAC I think a user friendly latency tester is needed so users have an easy way to test a setup, something better than than just installing apps and being mystified when they get tons of xruns. The backend is trivial (there are a bunch of similar little tools out there), but I'm not a GUI person. Would anyone like to help design and implement this? Since time is money ;-) a simple Gnome and/or KDE front end would be the easiest way to start, and of course there should be a separation between the GUI and the back end so anyone can implement a leaner version if they want to. Anyone want to help with the GUI side? Lee

19 years, 7 months

[linux-audio-dev] LAC2006 Photos

by Christoph Eckert

Hi all, I just uploaded some Photos taken during LAC 2006. It one huge tgz archive, no web gallery available. It will be up in 15 minutes: http://christeck.de/stuff/LAC2006.tar.gz To save bandwidth, I scaled them down a bit. If anyone is interested in a particular high resolution image, don't hesitate to send me an e-mail. Any further resources? Best regards ce

19 years, 7 months

[linux-audio-dev] [ANN] Dino 0.2

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