Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7513 discussions

[linux-audio-dev] Fakiir 0.4 - an RPC code generator

by jaromil

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 re all, i'm writing a software that can read a C++ header and generate code to expose the public functions in classes found: the generated code can be compiled together in the original app, which should also link to a library, then with 4 new lines OSC and XMLRPC servers will be active accepting remote calls to the functions. in fakiir, i make use of liblo-0.18 also published on this list. the software it's in a early phase of development, but since today is able to accept concurrent OSC and XMLRPC calls in the testclass.cpp application that is bundled with the source. http://fakiir.dyne.org i'm happy to hear comments, suggestions or any criticism that comes ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Cryptographically signed mail, see http://gnupg.org iD8DBQFCQvU3WLCC1ltubZcRAsP3AJwKkEKeXc4GrWoyTXOqkPUuStKLHwCfReBE NN7TpeyfrNxTIC7dNNN4BPE= =uqyK -----END PGP SIGNATURE-----

20 years, 5 months

[linux-audio-dev] Jack and sample rate conversion : realtime or not ?

by Olivier Guilyardi

Hi, If playing a sound file that has a different framerate from Jack, using libsamplerate, should I : - convert in real time, in the process callback ? - convert the whole file into memory when loading it ? Actually, I've already coded the second option, but just discovered the jack_set_samplerate_callback() method, which seems to require the first option... Is it important to support framerate changes while rolling ? -- og

20 years, 5 months

[linux-audio-dev] Re: jack-udp

by Jordan

Thanks for the replies everyone! :) I was afraid that the computers would not be able to handle more than 8 channels of recording which is why I was limiting them that way. How many channels can one computer handle? What kind of specs (ie: processor/RAM) would that computer need? What interfaces can handle more than 8 analog mics? I would need to record about 32 mic inputs. Also, the OpenMosix would be disabled while recording, and would only be active when in a non-recording mode. Also, this network would be an island. The gigabit ethernet switch would be dedicated to just the audio stuff. -jordan

20 years, 5 months

[linux-audio-dev] Jack-udp

by Jordan

Hello all. I don't really have any business asking, but I am more and more interested in digital HD recording, and I have spent many hours recently studying hardware, software, techniques, et cetera. I don't really have the funds to create such a system, but it is fun to plan it out, in case my church or someone else would be interested in such a system in the future. The recent discussion of jack over networks has gotten me wondering a few things. Here is my current fantasy rack setup: 1U: UPS 1U: KVM 2U: RAID 2U: Master/DAW 1U: Slave Recorder/Node 1U: Slave Recorder/Node 1U: Slave Recorder/Node 1U: Slave Recorder/Node 1U: Gigabit ethernet switch (all computers connected through it) Basically, all slaves would boot off of the RAID server (for easier maintenance) into a cut-down Linux kernel, and will boot into text-only mode, starting only the programs absolutely required to run Ecasound. The slave node would begin recording when the master tells it to, and all audio data would be sent to the RAID server. I am thinking that each slave would be able to handle 8 channels of mono input. All nodes would be equipped with the OpenMosix software, so that they can assist the Master when they are not busy. The master would boot into GUI mode, so that the operator wouldn't be intimidated by learning Linux command line. The master would be able to see the status of all slaves, and what each channel is doing. The master would able to assign friendly names to each of the input channels (ie: vocal 1, vocal 2, drums 1, bass, etc.). When the operator checks a box at each channel, to indicate whether it should record or not (no point in recording if nothing is plugged into it). The operator can also enter a friendly name for the project. When the operator issues forth the "BEGIN RECORDING!!!!" command, a directory is created on the server, and all nodes begin recording. The all data is sent directly to the server, then opened on the DAW from there. The DAW operator would be able to record a live mix into a JACK-capable recorder, such a ReZound, then burn it to CD. The operator would also be able to back-up the project (ie: all of the raw audio) to a data DVD. So, I guess the question is, would this work? -jordan

20 years, 5 months

[linux-audio-dev] jack.udp issues

by Antonio "Willy" Malara

jack.udp for me means many underrun in this configuration: x86 pc jackd -d alsa -d hw:0 jack.udp recv ^ | (FastEthernet network (100mbps)) | | powerpc pc jackd -d dummy jack.udp -r IP send the first thing that came in my mind was some network troubles like mtu.. further investigation (like involving two x86 hosts, or working directly without the switch, working with 802.11b networks...) made me think that jack.udp uses the audiocard driver for some kind of timing. now, i've some troubles running an audiocard with jack in the powerpc (my main computer) there is a way to make this system usable with dummy driver? i've noticed that this dummy driver has a "delay in microsecs" parameter, now i think if i can calculate the right number the problem will fade away, but i dont know how to do the math :( some one has an idea on this? or has solved a similar trouble? another question out of this trouble: someone knows how to raise the IRQ priority of the USB controller to an usable value? possibly not involving the use of the realtime patch, inusable on ppc-powermac, thanks for attention and eventual replies, and keep the good work on this audio software :) willy

20 years, 6 months

[linux-audio-dev] jack.udp issues

by Ben Loftis

On Monday 21 March 2005 12:06 pm, linux-audio-dev-request(a)music.columbia.edu wrote: > jack.udp for me means many underrun in this configuration: > > x86 pc > jackd -d alsa -d hw:0 > jack.udp recv > ^ > | (FastEthernet network (100mbps)) > | > | > powerpc pc > jackd -d dummy > jack.udp -r IP send In order for this to work, the sending side needs to know "how many" samples it needs to send. In other words, if the x86 side needs exactly 44,100 samples per second, there is no way in your existing setup to make sure that the powerpc doesn't send 44,101 or 44,099 samples per second. You'll need to run an actual alsa client on the sending side, and use wordclock or some other mechanism to keep the two soundcards in sync. You might be able to hack something into the receiving side which tells the sender each time it consumes a buffer, but that's probably not going to get you where you want to be. -Ben Loftis

20 years, 6 months

[linux-audio-dev] OSC-Question

by Arnold Krille

Hi all, after some of the latest discussions about audio-apps without gui, my head is filled with giving JackMix[1] OSC-Support and perhaps splitting it into a text-based / osc-based server doing the mixing and a gui... So my question arises: Which OSC-implementation to use? I had a look into Steve Harris' liblo and libOSC++. The later seems more appealing to me since I am a C++-Guy. What do you folks think? What do you propose? What are you using? Arnold [1] http://roederberg.dyndns.org/~arnold/jackmix/ -- There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. -- Douglas Adams, The Restaurant at the End of the Universe

20 years, 6 months

Re: [linux-audio-dev] jack transport

by Luis Garrido

> Syncing video playback to Ardour would be a great example of the > usefullness of jack-transport. Unfortunately, i guess the fact > is that the design of mplayer means it can never be a real jack > client. Perhaps a jack client could control mplayer via its slave > mode, for use with non-keyframe based video formats, but thats a > bit of a hack. I needed a jack driven video player to allow me to compose the soundtrack for a videoclip in MusE. Since there was none available, I made my own one. I think it is a not so great but adequate example of the usefullness of jack-transport ;-D One of the solutions I thought of was that suggested by you: mplayer slave mode. I don't remember well why I dropped it. Finally I ended up glueing some libraries to make a very quick hack that did the job. Don't expect good video performance, nor support of keyframed video formats, I only spent a couple of days and got what I needed. I use it successfully with MusE and ardour. You can check the project page and a screenshot: http://sourceforge.net/projects/xjadeo/ http://sourceforge.net/project/screenshots.php?group_id=131926 Regards, Luis

20 years, 6 months

[linux-audio-dev] appropriate LADSPA plugin for rejection?

by Andrew Gaydenko

Hi! The aim is to investigate some signal which consists of main harmonic and others with rather low level. I'd like to reject main harmonic _and_do_not_affect_ to other harmonics. What LADSPA plugin is the most sutable for such work? Thanks! Andrew

20 years, 6 months

[linux-audio-dev] Quick question regarding raw midi access via alsa sequencer

by Ivica Ico Bukvic

Hi all, I did a bit of hacking on my app trying to make it alsa sequencer compatible but did not want to do too much changing in terms of how it deals with raw MIDI data. From looking at the API reference it seems that I have 2 choices: 1) Use raw midi option and specify "virtual" name which makes my app's MIDI I/O appear in the alsa sequencer, *but* does not give me an option of changing the node names which obviously is very important when it comes to working with a lot of apps concurrently. So therefore here's my first question: Is there a way to specify a "virtual" port so that I can receive raw MIDI data, have ports show in the alsa sequencer and on top of that be able to *rename* the port as necessary? 2) The other option is obviously to use alsa-sequencer API but in that case is there a way to simply convert the stream of received MIDI data into raw midi format so that I can use my built-in raw MIDI parsing engine for parsing the messages? Any help is greatly appreciated! Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico/ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005

20 years, 6 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