Linux-audio-dev January 2006

linux-audio-dev@lists.linuxaudio.org

83 participants
66 discussions

[linux-audio-dev] Alsa device to Jack ports?

by Melanie

Hi, I am using an application which enumerates the ALSA supported hardware devices and offers them as input / output devices. Now, I would much rather have that app output to Jack. The app does support OSS, but only native OSS, it does not offer OSS support when ALSA is available, else I could have used oss2jack. Now I wonder, is there something like alsa2jack? Something that appears as a physical soundcard in ALSA, yet feeds into Jack? Melanie

18 years, 3 months

[linux-audio-dev] Problem compiling with liblo: error: 'lo_address' does not name a type

by Frank Barknecht

Hallo, while trying to build Dave Griffith's fluxus, which uses liblo, on Debian, I've hit a very strange error. It boils down to g++ not finding the symbols exported in lo/lo.h. I stripped down the code, where it fails to this supershort C++-file: // -------------- // OSCServer.cpp // #include <lo/lo.h> lo_address m_Destination; // ---------- end Trying to compile this with $ g++ -c OSCServer.cpp will give these errors: $ g++-3.2 -c OSCServer.cpp OSCServer.cpp:2: 'lo_address' is used as a type, but is not defined as a type. $ g++-3.3 -c OSCServer.cpp OSCServer.cpp:2: error: 'lo_address' is used as a type, but is not defined as a type. $ g++-4.0 -c OSCServer.cpp OSCServer.cpp:2: error: 'lo_address' does not name a type liblo is installed from the Debian package: ii liblo0-dev 0.22-1 Lightweight OSC library --development files I think, g++ finds <lo/lo.h>, otherwise it should complain about a missing header, but then it doesn't want to use it. Does anyone have an idea, what is going wrong here? Ciao -- Frank Barknecht _ ______footils.org_ __goto10.org__

18 years, 3 months

[linux-audio-dev] things to port to the gp2x ..

by Jay Vaughan

hi all, well i've recently waded into the GP2X territory, fairly deeply, and i'm enjoying it immensely: http://gbax.com/ its a dual-processor (ARM) portable games machine, battery powered, US$180, and .. it runs linux, has a very interesting EXT connector which supports USB and MIDI, video and audio, and extremely active games coding is going on, with well over 10,000 games currently runnable on it (emulation, baby): http://wiki.gp2x.org/wiki/EXT it can support usb-gadget audio (already has usb-gadget serial) so it wouldn't be terribly hard to 'integrate' it, either, with USB-based audio outputs .. and there is SDL onboard too, for graphics, with cairo/libsvg of course .. so its not such a stretch to consider this to be -the- synthesis platform of choice for linux audio hacking, and so i was wondering .. what linux-based softsynths do you think would be worthy to port to such a beast? i've already got sampling, a sequencer (thanks to MidiShare), and some basic audio idea's down, but what do you guys think about having a bit of a port-fest and turning the GP2X into a veritable treasure trove of a softsynth platform? -- ; Jay Vaughan

18 years, 3 months

[linux-audio-dev] ANNOUNCE: set_rlimits 1.2.0

by Jonathan Woithe

Hi everyone This is a short note to point out that I have released set_rlimits 1.2.0. It can be found at http://www.physics.adelaide.edu.au/~jwoithe/set_rlimits-1.2.0.tgz This is the software formerly known as set_rtlimits. I've changed the name to reflect the fact that any rlimit can be controlled by this program if the need arises. Changes/additions in this version: * improved configuration file syntax (with support for the old syntax if it is found) * ability to set the memlock resource limit * easier command line use (an absolute path is no longer required for example - it is taken from the configuration file) As always, bug reports, suggestions and patches are welcome. Regards jonathan

18 years, 3 months

Re: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address'does not name a type

by Chris Cannam

Frank Barknecht: > OSCServer.cpp:2: 'lo_address' is used as a type, > but is not defined as a type. Wasn't lo_address called something else in very old versions of liblo? Maybe you have spare headers lying around. Or maybe I'm inventing things. Chris

18 years, 3 months

[linux-audio-dev] Splitting audio files?

by Dan Stromberg

What are people's favorite applications for splitting up large sound files? I have a bunch a bunch of IMA ADPCM .wav's that I want to burn to CD, but often they're too large for a single CD. BTW, I've been converting the files to .cdr on a linux system, and then transferring that result to a windows machine for burning via a windows version of cdrecord. I'm interested in both CLI and GUI ways of doing this. Thanks!

18 years, 3 months

[linux-audio-dev] Interaction bug between zynaddsubfx and muse.

by Bill Allen

Hi. I'm writing to the list as opposed to the individual app owners since I can't really tell where the bug is. I have a sequence in which I want to use zynaddsubfx as the bass and another instance of zynaddsubfx for synth strings. The problem that I see is when I add the base instance to the bass track, muse then gray's out both instances (which have the same name, so I assume that muse is going through the list graying out any instance with the given name). I do notice in qjackctl's connection screen that the two instances of zynaddsubfx midi out have the same name although obviously they are on different ports. The zynaddsubfx audio instances have different names. This could be a bug - I'm not familiar enough with the jack naming conventions to definitively state this though. However, when I do the same in rosegarden4, it works fine. Rosegarden4 seems to key its list of softsynths with the name and port number. Thus, in conclusion it seems that zynaddsubfx might be at fault in that multiple instances advertise themselves with the same midi out name. I tested several other softsynths. It seems that ams, spiral modular synth and hydrogen also share this characteristic. AmSynth appends a "serial number" to new instances in the midi client list and I tested that muse does indeed work fine with muliple instances of AmSynth. Muse might be at fault because it uses only the midi out name instead of looking also at the port number. Given the number of softsynths that follow the convention of identifying themselves by non-unique names, I think muse should probably add the port number to the identifier to tell instances of the same softsynth apart.

18 years, 3 months

[linux-audio-dev] top 10

by Lee Revell

The Independent picked their top 10 free software projects: http://news.independent.co.uk/media/article337369.ece and dyne:bolic made the list. I think all Linux audio developers deserve some credit for this. Lee

18 years, 3 months

[linux-audio-dev] VST compiled for linux / gui message loop

by jorgen

Hi, Im coding a VST host for windows and linux. The linux version will support VSTs compiled on linux and not using wine or aything. Of course, there is not alot of native linux VST plugins around but that will change (I already made one :P ) There is one challange though, event dispatching in X11. Unlike windows, X11 windows doesnt have an assotiated window proc for dispatching events. I can overcome this in my own gui toolkit by passing a Display* pointer to the plugin etc, but it wouldnt work with other gui toolkits. So how do I make a soution that work with any toolkits on linux? 1) the plugin calls its own event loop in effEditIdle 2) make a new atom "wndproc" for storing wndproc function per window, the host will send XEvents to the wndproc if found. I prefer 1) but I dont know if toolkits supports manually calling the event loop? cheers jorgen

18 years, 3 months

[linux-audio-dev] RTP MIDI I-Ds now in IETF Last Call ...

by lazzaro

Hi everyone, The Internet-Drafts for the RTP MIDI protocols for sending MIDI over IP are now in "IETF Last Call" -- this is a process where the Internet Engineering Steering Group (IESG) solicits comments from the community at large, before making a decision on whether the protocol should be blessed with standards-track RFC status. See below for information on how to send comments to the IESG (don't send them to me directly -- I can't pass them on). Thanks! ----- From: The IESG <iesg-secretary(a)ietf.org> Date: January 6, 2006 8:46:17 AM PST To: IETF-Announce <ietf-announce(a)ietf.org> Cc: avt(a)ietf.org Subject: Last Call: 'RTP Payload Format for MIDI' to Proposed Standard Reply-To: iesg(a)ietf.org The IESG has received a request from the Audio/Video Transport WG to consider the following documents: - 'RTP Payload Format for MIDI ' <draft-ietf-avt-rtp-midi-format-14.txt> as a Proposed Standard - 'An Implementation Guide for RTP MIDI ' <draft-ietf-avt-rtp-midi-guidelines-14.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg(a)ietf.org mailing lists by 2006-01-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi- format-14.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi- guidelines-14.txt --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

18 years, 3 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