Linux-audio-dev February 2005

linux-audio-dev@lists.linuxaudio.org

78 participants
65 discussions

Re: [linux-audio-dev] 3D fft analysis program

by Downer

> I'm hoping that you're thinking of a realtime display, in which the > peaks roll off to create a true waterfall effect. Baudline (http://www.baudline.com) is a fantastic viewer that does fft cascade. I've used it for a couple of years, and it is great for figuring out how different sounds "work", and it has an oscilloscope-type display as well. Cheers, Jason Downer

17 years, 6 months

[linux-audio-dev] Drum synth

by Dmitry Baikov

Hello. I finally started making my pet music project and realized I need a drum synth to make some cool sounds. psindustrializer is good but also need some tr-909-style sounds. I remeber from my old windoze days I used a nice piece of software called Stomper. Does anybody know any software for linux with comparable capabilities? Or we need to write one? Stomper does not work under wine :( Thanks.

17 years, 6 months

[linux-audio-dev] Re: Drum synth

by Juhana Sadeharju

Hello. I had a couple of articles on drum synths. Check ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/ I built the circuit in a00*.jpg at the time when this article was fresh. The article b00*jpg mentions an earlier article. I will check that out at library. Hmm.. I coded a drum synth for Commodore VIC-20 at the time. VIC provided an audio chip with three oscillators, noise, and a common volume if I remember correctly. What I did was to modulate osc pitch and volume parameters with a fast and accurate (compared to Basic) assembly code. The drum sounds were assigned to the keys. This was about 1984, inspired by Yamaha's digital RX drum synths, not by analog drums. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

17 years, 6 months

[linux-audio-dev] Re: lad design patterns

by Juhana Sadeharju

>From: "Levi D. Burton" <ldb(a)puresimplicity.net> > >does the idea of documenting various lad design patterns make >sense to anyone? Such "LAD Gems" doc would be much needed here too. (For audio dsp gems, take a look at "musicdsp.org".) I would appreciate if somebody would take a look at Ardour and document best gems found there. E.g., the GUI and audio thread separation and start up sequences. Likewise for Linuxsampler and one of its GUI frontends. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

17 years, 9 months

Re: [linux-audio-dev] impulse convolution LADSPA plugin

by Stefan Turner

Hi Steve, thanks for the reply. I will definitely look into using DSSI, looks like it could be good once as supported as LADSPA is (I'd never even heard of it before your post, although that's probably just me). Is it intended as an eventual LADSPA replacement? I never really saw the need to divide plugins into 'instruments' and 'effects', and it seems like DSSI can do both. Stefan Turner > It would be more practical to do it as a DSSI plugin, LADSPA has no way > to > indicate that you want to load files during runtime, and no UI. > > In DSSI you can load the impulse in the "UI" process, perform the FFT > on > it and send it ot hte DSP code with configure(). Once there the DSP > code > can the overlap-add/save on it. > > - Steve ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com

18 years, 6 months

[linux-audio-dev] RME HDSP MADI drivers?

by Marije Baalman

Hi, this question is mostly for Thomas Charbonnel, I suppose, as he was working on this a while ago... Is the Alsa driver for the RME HDSP MADI already up and running? sincerely, Marije

18 years, 8 months

[linux-audio-dev] Any interest in DVD-Audio?

by Dave Chapman

Hi, Hopefully this is within the scope of this list but following a lot of recent googling, there doesn't appear to be any interest in "open-sourcing" anything related to DVD-Audio. As you may know, commercially authored DVD-Audio disks have three very unfriendly features - encryption, watermarking and Meridian Lossless Packing (MLP). I am assuming that these are some of the reasons developers have not become interested in DVD-Audio. However, none of those features are compulsory, and if you remove those obstacles (which I am not interested in overcoming - simply avoiding), you are left with a standard which allows 18 combinations of samplerate and sample wordsize for 2-channel stereo audio (including 16-bit/44.1KHz RedBook, and going all the way up to 24-bit/192KHz), plus a range of 6-channel uncompressed surround sound formats. My aim is to produce a set of GPL'd tools to both author, "un-author", and play such unencrypted, uncompressed disks, and am curious to know if any other developers have an interest in this area or not. To this end, I've started the "dvd-audio" project at sourceforge - http://sourceforge.net/projects/dvd-audio/ I have not yet populated the site with HTML content or any of the software I'm in the process of developing, but there is a "dvd-audio-devel" mailing list which anyone is welcome to subscribe to. I should reiterate that I'm not interested in investigating features such as encryption or MLP - I simply wish to be able to author my own unencrypted and uncompressed DVD-Audio disks using my own music, which I can then play back either on my hardware DVD-Audio player or on my PC, all using free software Regards, Dave.

18 years, 9 months

[linux-audio-dev] OSC, mDNS and LASH: a good combo?

by Martin Habets

My impression is that more and more applications are moving to OSC for inter-process communication. Question 1: Are most audio/midi applications converging on OSC? Are there any moving away from it? Or are there other strong contenters in this area? AFAIK all linux audio/midi applications use an arbitrary UDP port number, and rely on manual configuration of this for the server and all clients. With OSC popularity increasing this will pose a growing problem for end users who have to configure the ports, and for developers of client programs that want to interact with multiple servers. The answer to this issue is service discovery, which was recently discussed on the OSC_dev list [1]. That thread leads to a product called howl [2], which is an open implementation of mDNS/redezvous/ zeroconf (take your pick). It provides 3 daemons (of which 2 should be run) and some libraries. Using this implementation all applications would (ideally) register or discover services using the howl libraries. Apart from this, the programs would communicate via OSC. To me this seems like a lot of overhead for a relatively small gain. OTOH it seems like a very flexible and future-proof solution. An alternate way I've been considering is an OSC-based service discovery daemon. It would accept OSC messages to register and discover services. The advantage of this is that it only uses 1 small daemon, but more importantly that applications do not need to use any additional libraries besides the OSC one (<insert liblo plug here> :). So far I can see 6 input messages for such a daemon, with 4 response messages. The disadvantage is that the daemon would still need an arbitrary port number, and all applications would need to know it (at least for a while). For intra-host discover the daemon could still interact with howl or something like it if that is needed. But if this approach is successfull we could request one dedicated port from IANA. Question 2: Are there other better alternatives? Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon) The only thing I haven't mentioned yet is LASH. Well, in my opinion it is the prime example of an application that needs to interact with all other linux audio/midi appications. As such, I think it could gain most from a service discovery scheme. And there has been talk about using OSC for it [3]. Comments/suggestions/questions? Blast away! Phasers on stun please! And Steve: appologies for stepping on your turf. Best regards, -- Martin [1] http://www.create.ucsb.edu/pipermail/osc_dev/2004-December/000841.html [2] http://www.porchdogsoft.com/products/howl/ [3] http://music.columbia.edu/pipermail/linux-audio-dev/2004-August/009288.html [4] http://www.cnmat.berkeley.edu/OpenSoundControl/ --------------------------------------------------------------------------- 30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is today. - Martin Habets ---------------------------------------------------------------------------

18 years, 9 months

[linux-audio-dev] Re: [linux-audio-user] hydrogen crashes / extract waves from .mid-files of ddrum

by Lee Revell

On Mon, 2005-02-21 at 15:42 +0100, CC-Band wrote: > hi, > > i tried out the agnula demudi project. > > jack & hydrogen works fine but sometimes hydrogen crashes immediately. > what can i do to get information, why? I am having the exact same problem with Hydrogen. Most of the time it crashes immediately. If I start it repeatedly it will eventually succeed. I have found it's a lot more likely to segfault immediately on startup if JACK is run in verbose mode, and the crashes are more likely with lower latencies. 32 frames almost always crashes. 128 almost always succeeds. 64 is hit or miss. Lower latencies are less likely to crash on a faster machine. I have reproduced this across several versions of JACK and Hydrogen on multiple machines. I got a backtrace from gdb and this is where it crashes (from src/lib/Hydrogen.cpp): inline void audioEngine_process_clearAudioBuffers(uint32_t nFrames) { *---> memset( m_pMainBuffer_L, 0, nFrames * sizeof( float ) ); // clear main out Left memset( m_pMainBuffer_R, 0, nFrames * sizeof( float ) ); // clear main out Right As soon as it goes to clear the audio buffers, boom. As the problem is timing sensitive it's certainly a race condition. I cannot determine whether the bug is in JACK or hydrogen though. I have reported the problem on hydrogen-devel and got no response whatsoever. It's getting to be frustrating as the bug is 100% reproducible, but I can't even get the Hydrogen developers to ACK my bug report. Here is the backtrace. Lee (gdb) bt full #0 0xb759949b in memset (dstpp=0x0, c=0, len=512) at ../sysdeps/i386/memset.c:65 d0 = 128 dstp = 0 x = 0 #1 0x0807da0f in audioEngine_process_clearAudioBuffers (nFrames=128) at src/lib/Hydrogen.cpp:702 No locals. #2 0x08074381 in audioEngine_process (nframes=128, arg=0x0) at src/lib/Hydrogen.cpp:746 res = 0 startTimeval = {tv_sec = 1107297223, tv_usec = 403047} sendPatternChange = 183 res2 = -1218109252 renderTime_start = {tv_sec = -1217118338, tv_usec = -1208618368} i = 3086349340 pNote = (class Note *) 0x1 renderTime_end = {tv_sec = 91845001, tv_usec = -1084229004} ladspaTime_start = {tv_sec = 52302212, tv_usec = 0} ladspaTime_end = {tv_sec = -1208836712, tv_usec = 0} val_L = -0.87490797 val_R = 1.40129846e-45 fRenderTime = 0 fLadspaTime = 1.821688e-44 finishTimeval = {tv_sec = -1208834440, tv_usec = -1084229128} sampleRate = 1.17287768e-35 #3 0xb7f2e9f9 in jack_client_thread (arg=0x82f59d0) at client.c:1264 control = (volatile struct {...} *) 0xb73a3000 event = {type = GraphReordered, x = {n = 0, port_id = 0, self_id = 0}, y = {n = 1, ptid = 1, other_id = 1}} status = 0 '\0' c = 0 '\0' err = 0 #4 0xb773fe51 in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:309 default_params = {__sched_priority = 0} request = {req_thread = 0x0, req_kind = REQ_CREATE, req_args = {create = {attr = 0x0, fn = 0, arg = 0x0, mask = {__val = { 0 <repeats 32 times>}}}, free = {thread_id = 0}, exit = {code = 0}, post = 0x0, for_each = {fn = 0, arg = 0x0}}} outcome = (void *) 0x0 #5 0xb75f96ea in clone () from /usr/lib/debug/libc.so.6 fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}} __elf_set___libc_subfreeres_element_fstab_free__ = (const void *) 0xb762dce0

18 years, 9 months

[linux-audio-dev] addy change

by Dave Phillips

Greetings: My ancient bright.net address is finally closed, as of now. I'll receive no more email at that address (current addy is in this mail's header). If you've sent any mail to me over the past two days it's probably been lost: I inadvertently cleared my Inbox for the older account, so please resend if you've sent anything directly to me recently. All my bright.net pages will be revived at another location, I'll send a note to this list at that time to say where & when. Best, dp

18 years, 9 months

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 February 2005