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
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
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
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
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
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
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
> 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
>
> ..
>
>
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
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