Linux-audio-dev January 2006

linux-audio-dev@lists.linuxaudio.org

83 participants
66 discussions

[linux-audio-dev] LAD site, linuxdj.com needs a new home

by Benno Senoner

Hi LADers, During the last months the LAD website ( http://www.linuxdj.com/audio/lad ) was hosted on the lionstracs.com server. Domenico from Lionstracs told me that he does not want do host the LAD site anymore since it consumes so much bandwidth, 200 GB in January, see here. http://www.linuxdj.com/webstat1/ its probably due to the audio/video material from the conferences (100MB a pop). Anyone willing to host the site ? As I did in the last years, I'll pay the for the linuxdj.com domain fees. cheers, Benno

18 years, 2 months

[linux-audio-dev] Launching DSSI GUIs via OSC?

by mlang

Hi. Is there anything planned for the DSSI standard which would allow DSSI hosts to launch GUIs just by sending a OSC message to some kind of GUI launcher? I am asking because I'd like to write a whysynth frontend in SuperCollider Language. That should be all doable, since the whole GUI->DSP->GUI process happens over OSC. Now there is only the session initiation left. I know its pretty trivial to write a wrapper WhySynth_osc which just sends off its argv to SCLang via OSC, but this feels kind of clumsy to me. In fact, for what I'd like to do, it would be quite pretty if jack-dssi-host just had an additional command-line argument which would tell its startGUI routine not to call exec, rather send the 4 strings to the specified osc url. $ jack-dssi-host -o osc.udp://localhost:57110/dssRequestedI/ whysynth.so How does this sound to you, worth a patch? Or should this really be done with wrappers, ugly as they may be? -- CYa, Mario

18 years, 2 months

[linux-audio-dev] Re:LAD site, linuxdj.com needs a new home

by Maluvia

On 1/30/06 Paul Davis wrote: >i have the space and capacity to host this at dreamhost under my >account. start the ball rolling. I think this would be the best solution - it will keep Paul with us for a long time to come. :) >btw, i happen to think that the current website is ugly and a mess. it >would nice if some people could spare several hours and clean it up to >make a really useful resource for people interested in linux audio >development. Agreed. -Maluvia

18 years, 2 months

[linux-audio-dev] open standards for file formats

by cdr

i know design by committee can be horrible but these situations usually utilize vastly similar yet incompatible formats, so its sort of biting off something small, i hope.. :) (1) Peak Files some of my favorite wav files have 10 metafiles each. peaks generated for peak, spark, wavelab, soundforge, cubase, ableton live, samplitude, rezound, sweep, ardour, plus a dir for "Apple Loops" data etc. it would be great if each time an audio file enters a new app, the user wasnt greeted with a 30 second burst of disk activity as peak files were generated yet again..what exactly is needed? here are some thoughts - average amplitude per time-slice to generate the waveform overview * what granularity is useful? peak files seem to run a few % of filesize.. - spectral centroid for comparisonics/freesound style colorization - annotations (OPML etc) - timing (tempo, cue points, beat markers) rather than invent some new arbitrary plaintext (or XML) format, i'm interested in using OSC (as described at http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec-examples.html ) to encapsulate this data, at which point this is simply an exercise in selecting a schema/namespace... beside faster load-times (eg one could pregenerate this data before a performance or composition session via a recursive shell command and 'sox'), a commonly understood format would enable easier sharing of CC-licensed material among a variety of users and apps without useful metadata being 'lost in translation'. additionally web and other interfaces could be developed using the metadata hints (see archive.org, NI's KORE) (2) Instruments compatibility and reuse of sample-based instruments between chionic, specimen, DSSI samplers, PD samplers, LinuxSampler, and seperation between editor and engine allowing more highly specialized apps - the 'nix way. - get rid of arbitrary region / bank / instrument boundaries which seem derived from MIDI (the amount of times you see 1-16 and 0-127 in modern software instruments is appalling) - sample regions pointing to audio files or groups - grouping (nesting / tags) - volume / filter / lfo stuff once again i am thinking OSC could be suited to this.. (3) 'project' components monolithic binary files still seem to remain the norm, eliminating all hope of reuse without tedious exporting of settings or components, things like: - pointers to regions (audio files, control streams, other projects) - note and controller-data streams - instrument / filter settings ive thought about this a bit and am leaning towards using a directory on disk, with a format for each of the above, which would enable revision tracking via SVN or darcs.. note/control data will likely be OSC (and MIDI encapsulated in OSC where necessary), instrument/filter settings would be closely aligned with what is fed to LADSPA/DSSI modules, and the pointer 'glue' file linking others and assigning filter and routing data to tracks, channels, regions..\\\

18 years, 2 months

[linux-audio-dev] dmix and jack

by voidcreature＠paradise.net.nz

Has anyone managed to successfully get jackd talking to dmix? My dmix setup works fix (i run VoIP stuff, artsd, and other assorted junk through it daily). jackd works great when connect to hw:0,0 or to plughw:0,0 (with the warning), but if I point it at my dmix'd "default" it sits there with 100% CPU usage, and doesn't otherwise operate. Does anyone have this combination of jack and dmix working? (i'm running alsa 1.0.11rc3 on 2.6.15.1, i've tried alsa 1.0.10 and jack 0.100.0 too) >jackd -v -d alsa -d default -r 48000 -S -n 8 -p 1024 -P jackd 0.100.7 Copyright 2001-2005 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK compiled with System V SHM support. server `default' registered loading driver .. registered builtin port type 32 bit float mono audio new client: alsa_pcm, id = 1 type 1 @ 0x8056a48 fd = -1 apparent rate = 48000 creating alsa driver ... default|-|1024|8|48000|0|0|nomon|swmeter|-|16bit configuring for 48000Hz, period = 1024 frames, buffer = 8 periods You appear to be using the ALSA software "plug" layer, probably a result of using the "default" ALSA device. This is less efficient than it could be. Consider using a hardware device instead rather than using the plug layer. Usually the name of the hardware device that corresponds to the first soun nperiods = 8 for playback new buffer size 1024 registered port alsa_pcm:playback_1, offset = 0 registered port alsa_pcm:playback_2, offset = 0 ++ jack_rechain_graph(): client alsa_pcm: internal client, execution_order=0. -- jack_rechain_graph() 7129 waiting for signals load = 1.1672 max usecs: 498.000, spare = 20835.000 load = 1.3102 max usecs: 310.000, spare = 21023.000 load = 1.3793 max usecs: 309.000, spare = 21024.000 load = 1.4162 max usecs: 310.000, spare = 21023.000 .... etc ....

18 years, 2 months

[linux-audio-dev] RME DIGI9652 with AEB8-I and AEB8-O

by Guillaume Pellerin

Hi all ! I have installed a RME DIGI9652 on a Debian Sarge and it seems to work great with Ardour ! However my two expansion boards AEB8-I [1] and AEB8-O [2] plugged respectively on the "CD IN" input and "ADAT 1" output of the main board - as it is mentionned in the documentation - don't get any signal, even when I change existing interrupts in kmix, gamix, etc.. I would then ask to anybody who knows the chipset/driver if there are special routing interrupts to be switched with alsactl or something... Thanks a lot for your help and useful work ! p--g ` Parisson, Paris (sorry for the wrong 1st Re: mail)

18 years, 2 months

[linux-audio-dev] LADSPA AC3 encoder?

by Lee Revell

Question for the DSP gurus: How hard would it be to implement an AC3 encoder as a LADSPA plugin that could be used in an ALSA config to encode stereo and 5.1 sources on the fly? Many Windows drivers seem to contain one, and it would be a nice response to the naysayers on LKML who doubt the power of ALSA. It appears that a simple AC3 encoder is ~1500 lines of code: http://www.koders.com/c/fid04210C5E2BC83FC0BA5E0A2A1C37D52503E31EFD.aspx http://www.telos.de/Surround_Sound_Formats.360.0.html#1051 FWIW, when emu10k1/2 based cards first came out Creative claimed the DSP was powerful enough to do AC3 encoding on the fly, but, they never shipped an implementation - their drivers did it in software. One of their engineers said the DSP wasn't suited for the frequency domain processing required to encode AC3. Lee

18 years, 2 months

[linux-audio-dev] C++ Keyboard Event Handling

by Carlo Capocasa

Hi, new to this list and knowing absolutely nothing about C++ audio programming I would like to ask for a little bit of help. I want to create a console keyboard to MIDI application and for this I would like to read the physical status of keyboard keys. Thank you. Carlo Capocasa

18 years, 2 months

[linux-audio-dev] Ladspa GUIs (Was Re: [linux-audio-user] Acid type program

by Kjetil S. Matheussen

Reuben Martin: >> (Why hasn't anyone made a ladspa plugin with a GUI by the way? Its >> really simple just spawning of a gui process program.) >> > >Because you have no way of knowing if the platform you are running it > No no, you misunderstand. I said "spawning of a gui process" (I should rather have said "spawning off a gui process", but I didn't. :-) ). Well, I guess the question was more retorical. I personally think reason is that linux programmers aren't that much into bells and whistles as windows programmers. >on will have support for the toolkit needed by the GUI. It would be >nice to append the LADSPA spec to allow for a simple markup language >to describe the GUI, and then depend on the host to render that markup >language into a GUI. It would make it toolkit independent. No, that would not be nice at all. Far too complicated for the hosts, and guis would be different from host to host, and limited by the markup language What would be nice was if we used a common gui-designer like qdesigner or glade, so that someone could make an automatic gui-spawner library that used the xml-files from qdesigner or glade to make guis. That way, anyone could make/edit gui's quite easely. The idea was proposed some years ago, but no one has picked it up. Its not much work to do, but I guess no one has got the time. It must be a community project as well, because it would be useless if no one bothered to make guis for the various plug-ins or the hosts didn't support it. (well, the host-problem could be fixed automatically by making a wrapper ladspa plugin, but its not the ideal solution)

18 years, 2 months

Re: [linux-audio-dev] xt2 coming to linux

by Chris Cannam

Lee Revell: > > Won't help if the code is to be part of a GPL'd > > application. > > The Linux kernel is a GPL'ed application yet Nvidia > gets away with linking into it. Quite different. Anyone can distribute the kernel without caring about the existence of the nVidia drivers. But if an application includes the VSTSDK, it presumably isn't complete without it. Chris

18 years, 2 months

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 January 2006