Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

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, 4 months

[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, 4 months

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, 4 months

[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, 4 months

[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, 4 months

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

by Pieter Palmers

Stefan Richter wrote: > Pieter Palmers wrote: >> The problem summary is that running ieee1394 ISO traffic can cause >> scheduling latency spikes up to 1ms, even for RT threads with higher >> priority. > > Do your patches to lower CPU utilization show any influence? Not tested yet. I have a hunch that the removal of the dummy read might improve the situation. But I haven't investigated this yet. > > Do you get 1394 bus resets while ieee1394stress is running? (You could > e.g. print raw1394_get_generation(handle) when it starts and when it exits.) As far as I can tell there are no bus resets, but I'll check. Pieter

19 years, 4 months

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

by Pieter Palmers

Hi all, 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. The problem summary is that running ieee1394 ISO traffic can cause scheduling latency spikes up to 1ms, even for RT threads with higher priority. I've written a simple test suite that can be used to reproduce this behavior. The only thing needed is a firewire host controller (no firewire devices). I'd appreciate it if some people would try the test so that I can have an overview of the problem. Of course, this applies mostly to people running an -RT patched kernel. You can find the test suite here: http://freebob.sourceforge.net/old/ieee1394-latencytest.tar.gz see the README for details. Please report the maximum latency you get and the kernel/hardware you're running. Many thanks, Pieter Palmers FreeBoB developer

19 years, 4 months

[linux-audio-dev] [ANN] jack_capture V0.2.4

by Kjetil S. Matheussen

jack_capture is a small program to capture whatever sound is going out to your speakers into a file without every having to patch jack connections, fiddle around with fileformats, or set options on the argument line. This is the program I always wanted to have for jack, but no one made. So here it is. http://ccrma.stanford.edu/~kjetil/src/ Changes 0.2.3 -> 0.2.4: *Give message to stderr during recording (not only after) if any overruns occur. *Do not delete file after recording if any overruns have occured. (stupid jackreq code #$!@$) *Increased default buffer size from 0.5M to 2M.

19 years, 4 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 33, Issue 11

by Ben Loftis

Hi Alex. What you're trying to implement is called an automixer. "Winner Takes All" is probably not going to work as well as your original expander. It will have problems when somebody coughs, drops their books, bumps the mic, tries to interject, etc, because it will duck the current speaker. Here are some of the subtleties that you might want to consider: A "filibuster" function which guarantees that once a mic is gated on, it stays on until the speaker has gone silent for a second or three, and it can't be silenced by some other mic gating on. An "AGC" (automatic gain control) algorithm on each mic that guarantees quiet speakers and loud speakers have the same perceived volume in the recording. Duck the unused mics a few dB instead of a fully gating them, or always leave one mic open. The room ambience is important and it (kinda) proves the recording hasn't been doctored. I picked up an IED 8000-series automixer which does all these things on eBay for $20.00. Dan Dugan also makes some nice ones. So if this is a one-shot deal for a serious project, you may want to consider finding something similar that is proven to work rather than rolling your own. Just my $0.02 -Ben Loftis > > My first project will be a winner-takes-it-all-gain filter that takes > n number of inputs and lowers the gain on all but the loudest signal. > I want to use this on recordings of conversations where each speaker > has a separate microphone. First I tried sidechain ducking which > didn't really work for me. Then I tried expanding each channel, so as > to mute it when it fell under the threshold. That works pretty well > but it's not perfect. This winner-takes-it-all thingy should be dead > simple to implement and I expect it work pretty well. > > alex

19 years, 4 months

[linux-audio-dev] LV2 update

by Steve Harris

There's been little news on the LV2 front here recently, all the disucssion seems to have taken place on IRC, so a quick update: Theres now a website: http://lv2plug.in/ as of a couple od days ago, thanks to Thorsten Wilms which has links to drafts of the C header file and RDF/Turtle schema. Please read the formal specs and comment. Following discussion on the l-a-u list and hard work by a lot of people there's a logo. Please don't discuss the logo except to praise it ;) choosing one was quite involved. Various generic forms (black on white etc.) will be availble on the website in due course. TODO list: * Finalise the technical aspect of the spec, get interested parties to confirm that it meets thier needs (or at least doesn't prevent them). * Write human language specification to go with .h and .ttl explaining how to use the spec, conventions etc. * Make sure there's a reasonable set of reference implementations and examples. * Test the extension mechanisms. * Publish final spec, have tea and cakes etc. - Steve

19 years, 4 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