Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

[linux-audio-dev] Re: [ANN] Aqualung 0.9beta5 released

by Tom Szilagyi

On Fri, Jun 30, 2006 at 06:46:39AM -0700, Mark Knecht wrote: > > Tom, > Maybe you and Peter should post these on the Aqualung download > site? Maybe they are there already? The scripts were never intended to be used by a large audience (large by any standard), however, if there is popular demand for them, we might just post them to the website so everyone has easy access to it. We anticipate that this aspect of Aqualung (ie. mass import, mass tagging, etc) will improve greatly by the time we release our next beta. Tom

19 years

[linux-audio-dev] Re: [ANN] Aqualung 0.9beta5 released

by Tom Szilagyi

On Fri, Jun 30, 2006 at 01:34:31PM +0300, Sampo Savolainen wrote: > > Great news! Aqualung is starting to look like a very good option for a music > player. Thanks. We still see a number of areas where great improvement is needed, but we couldn't wait more before a real release (many people won't use our CVS tarballs ever, even though their contents are pretty much the same). > A few gripes though: > a) I would like to have a notification area icon to show/hide aqualung > b) There seems no easy way to import my existing collection of music. > I can select individual files from one directory, but whole > directories. My collection is divided into directories and > subdirectories. (artist/album/track.ogg) These are indeed noted, and planned for the next release. > Also, I found the metadata option a bit confusing: why doesn't aqualung use > metadata (id3's, etc.) provided by the audio files automatically? I had to > enable it explicitly. The defaults may be wrong, but once you enable autodetection, the program will remember your choice. (It is off by default so metadata won't accidentally override data from the Music Store -- this area may still need refinement.) Thanks for the feedback, Tom

19 years

[linux-audio-dev] Re: [linux-audio-user] [ANN] Aqualung 0.9beta5 released

by Sampo Savolainen

Quoting Tom Szilagyi <tomszilagyi(a)gmail.com>: > Aqualung: Music Player for GNU/Linux > > http://aqualung.sf.net > > Release 0.9beta5 > > > It is our greatest pleasure to announce the fifth official beta > release of Aqualung. Some features you'd rarely stumble upon in > other players (at least not too many of them at once): Great news! Aqualung is starting to look like a very good option for a music player. A few gripes though: a) I would like to have a notification area icon to show/hide aqualung b) There seems no easy way to import my existing collection of music. I can select individual files from one directory, but whole directories. My collection is divided into directories and subdirectories. (artist/album/track.ogg) Also, I found the metadata option a bit confusing: why doesn't aqualung use metadata (id3's, etc.) provided by the audio files automatically? I had to enable it explicitly. Just my 0.02 Sampo

19 years

[linux-audio-dev] [admin] linux-audio-* maintainer wanted...

by Joern Nettingsmeier

hi guys! due to post-academic stress syndrome (read: i'm getting a real job ;), i would like to resign from being maintainer of the linux-audio-* lists. lately i haven't been able to keep up with the lists as much as i would have liked to, and i feel it's time for new people to take over. if you'd like to volunteer, holler now :) i'm leaving on a four-week iceland trip in about a week, and if no-one has expressed their interest by then, i would be very glad if somebody could at least step forward to tend to the lists for a month or so... as an added bonus, there is also the job of cleaning up the old lad.linuxaudio.org page, throwing out all the obsolete stuff (i.e. everything except the subscription information and the contrib/ section) and maybe linking to all the excellent documentation efforts elsewhere :) i hope to stay in contact with the linux audio community in the future, and i will definitely do some volunteer work for next year's linux audio conference in berlin, but my life has moved away from studio work to live audio engineering, systems administration and (ugh) web content management... all the best, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D

19 years

[linux-audio-dev] fst, VST 2.0, kontakt

by Forest Bond

Hello everyone, I don't recall posting here in the past, although I have several hundred LAD mails in .Mail... Nice to meet you, anyway. I've been looking at fst, and was going to package it for Ubuntu. I had used dssi-vst in the past. My big problem is this: neither of the two save current settings for kontakt, my sampler of choice (there is no free equivalent, as far as I can tell, or I would use it). I've now decided that fst has better long-term potential to do what I need, mainly due to 1) lash support 2) not having to work through DSSI, which probably cripples its ability to be able to save ALL parameters. It would seem that fst doesn't have full VST 2.0 support, from looking at the source code. I've never written anything remotely VST-related, but would like to add such support to fst. I see Kjetil S. Matheussen's name in the source for vsti.c. I'm hoping he has some guidance for me. Kjetil, and LAD's in general, can you confirm my observations, and do you have an opinion on whether or not my goal is feasible? thanks, Forest

19 years

Re: [linux-audio-dev] ieee1394 deadlock on RT kernels

by Pieter Palmers

Ben Collins wrote: > On Mon, 2006-06-26 at 10:11 +0200, Pieter Palmers wrote: >> Lee Revell wrote: >> >>> On Mon, 2006-06-26 at 01:08 +0200, Pieter Palmers wrote: >>> >>> >>>> Hi, >>>> >>>> We are experiencing 'soft' deadlocks when running our code (Freebob, >>>> i.e. userspace lib for firewire audio) on RT kernels. After a few >>>> seconds, I get a kernel panic message that signals a soft lockup. >>>> >>>> >>> Can we see the kernel panic message? ;-) >>> >> no :p. I'm sorry for being a jerk, but I'm not going to type over that >> message just so that you can confirm that it indeed is a 'soft lockup' >> (or whatever it is called exactly) and that it occurs in the >> ohci1394_iso_unregister_tasklet. You'll have to take my word on it. If >> you need some specific part of the kernel message, you can get it. Tell >> me what you wqant and why, that way I can learn something from it. > > Take damn a digital photo. I'm sorry for being a jerk, but I'm not going > to debug an oops blind :P I'm sorry for my previous response... a monday-morning-bad-temper-leave-me-alone one that was very non-constructive. On top of that it is quite stupid to ask for help and at the same time claim "you'll have to take my word on it". Please accept my apologies. > > Seriously, if you are going to ask for help, be prepared to provide the > info requested, or plan on getting little to no help. > Of course. My monday-morning bad temper is over by now, and I hope I didn't transfer it to any of you. I'll provide the panic, one way or another. Again, I apologize, Pieter

19 years

[linux-audio-dev] LADSPA Extension for Extra GUI Data

by jez＠technetium.net.au

Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a "describe_value" function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return "SAW", "SIN", "SQR" etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return "-4 semitones" also wanting to add a mechanism to group ports into logical sections. without changing the underlying APIs, only by adding more layers on top this way preserving backwards compatibility, the host simply dlsyms for "ladgui_descriptor" and if it's there it makes use of the extra data, otherwise it falls back to how it previously did things once the API is done i plan to make a reference gui the idea behind this is that plugins will not need any of their own gui code as a useful gui can be constructed on the fly as a part of the host or a separate process that will work for any plugin so plugin developers never need worry about constructing a gui and can instead just make nice useable algorithms and test them quickly and easily. nicknamed LADGUI for now. API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ it seems like a good one to me, but when i joined here to post this i noticed lots of talk about LADSPA2, i've tried to read up on it but i can't seem to find much information about it, and it doesn't seem to be backwards compatible and doesn't seem to add anything to help create guis in the host? is there a page somewhere which explains it all? i'm sure there's lots of useful stuff that i'm missing, what other things would be useful in such an extension? thanks Jez Kabanov

19 years

Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data

by Jeff McClintock

> it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace In my mind every plugin parameter should be automatable, therefore every parameter update should be visible to the host ...therefore every plugin GUI should connect to the host (not directly to the plugin)...therefore to support such GUIs every host *SHOULD* provide some kind of query-of-plugin-namespace. Jeff > Message: 3 > Date: Mon, 26 Jun 2006 18:05:37 +0000 > From: carmen <_(a)whats-your.name> > Subject: Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data > To: linux-audio-dev(a)music.columbia.edu > Message-ID: <20060626180537.GS2312(a)replic.net> > Content-Type: text/plain; charset=us-ascii > > >>>>To ensure consistency the GUI should get its plugin descriptions from >>>>the host anyway. This works even with POL (Plain Old Ladspa). > > >>rather a more general format that it could use to describe its >>internal modules or other plugin formats as well. The GUI doesn't > > > in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. > > it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace > > .. > >

19 years

[linux-audio-dev] ieee1394 deadlock on RT kernels

by Pieter Palmers

Hi, We are experiencing 'soft' deadlocks when running our code (Freebob, i.e. userspace lib for firewire audio) on RT kernels. After a few seconds, I get a kernel panic message that signals a soft lockup. The problems occur when an ISO stream (receive and/or transmit) is shut down in a SCHED_FIFO thread. More precisely when running the freebob jackd backend in real-time mode. And even more precise: they only seem to occur when jackd is shut down. There are no problems when jackd is run without RT scheduling. I havent been able to reproduce this with other test programs that are shutting down streams in a SCHED_FIFO thread. printk() debugging point to the tasklet_kill() call in ohci1349_unregister_iso_tasklet (drivers/ieee1394/ohci1394.c), that doesn't seem to return. For experiment, i've put a tasklet_disable before the tasklet_kill, and that causes the soft lockup to be due to the tasklet_disable. I would like to ask if anyone has a clue why this is happening. The only thing I can come up with is that jackd is stopped by a CTRL-C, and that the stream shutdown happens in signal handler context, which somehow interacts with the tasklet_kill. But I don't have the time now to dig into this, so for a change I ask for advice early instead of first banging my head against the wall for some days :). Thx, Pieter Palmers

19 years

[linux-audio-dev] Re: [Freebob-devel] [REQUEST] test the influence of linux1394 kernel drivers on scheduling latency

by Jonathan Woithe

Pieter Palmers wrote: > This weekend I've discovered a (serious) kernel scheduling latency issue > with the current ieee1394 kernel drivers. Before I submit something > about this to lkml, I'd like some more tests. I've been able to > reproduce this on two different machines, so I suspect that this is a > more general problem. I ran the tests quickly on my firewire development machine overnight. First I started the latency monitor and left it run for about 10 minutes while I did other things, including accessing a USB stick. I then started the ieee1394 stress tester; almost immediately the monitor noted maximum latencies of the order of 1 ms (compared to tens of microseconds when the stress tester wasn't running). The output is blow. > ./latency_histogram -p 80 -n 128 -t 1 -s 1 Histogram size: 128 bins, bin size: 1us, last bin: 128us aquiring RT scheduling with priority 80 ... getting cpu speed... 67547857.763 Hz (67.548 MHz) Sleeping for 1us between timer reads... Running, press CTRL-C to stop... (+) New maximum: 62 cycles, 0.917868 (-) New minimum: 62 cycles, 0.917868 (-) New minimum: 58 cycles, 0.858650 (+) New maximum: 298 cycles, 4.411687 (+) New maximum: 43475 cycles, 643.617747 (+) New maximum: 48239 cycles, 714.145520 (+) New maximum: 52924 cycles, 783.503752 (+) New maximum: 131949 cycles, 1953.415021 (+) New maximum: 170136 cycles, 2518.747532 # of iterations: 243335 max. difference: 170136 cycles, 2518.747532us min. difference: 58 cycles, 0.858650us avg. difference: 66 cycles, 0.989601us Histogram --------- =< 1us: 33 1us : 243285 2us : 9 3us : 1 4us : 3 5us : 2 6us : 1 7us : 1 ... >= 128us: 33 The "New maximum: 298 cycles" appeared very soon after the stress tester was started, with the ones below it following soon after. Despite what the log says, this was running a 2.0 GHz "Dothan" Centrino CPU. Kernel was 2.6.16-rt25, distro was Slackware 10.2. Both the stress tester and the monitor were run with RT privilege access. The firewire interface used has a TI OHCI chipset. I apologise that the run was particularly short and that therefore the statistics aren't particularly good, but it does seem to confirm the observations you made on your machine. The large latencies only occur when the stress tester is running. Regards jonathan

19 years

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