I am wondering what the status of the mLAN or something similar is in
linux? I have been able to find some mention of talking with Yamaha
about it, but past that I cant seem to find anything on it. I am
looking for a solution to allow me to connect and stream audio in
realtime over firewire to a Mac Mini to run some VSTs on until VST
support in Linux is worked out completly. Thanks.
Seablade
Thanks for the tip on "diversity reception". Yes, I got the
idea from astronomer's systems. I use the term "invented" the same
way as patenteers: due lack of extensive literary search, I know
at most that the thing is new to me.
Though, I have never seen such a system used in consumer radios.
I'm not sure if it have been used in DX'ing radios either.
My test plan was to record the same music station at two cities
(apart 200km). Then timescale and align the digitized (1 or 2 hours)
recordings manually. And then do the thing.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Hi,
here
http://affenbande.org/~tapas/rt_watchdog.tgz
you find a small program which acts as a watchdog daemon that kills
runaway SCHED_FIFO tasks. It does so by setting up two threads:
- one high priority (99) consumer that runs every 3 seconds
- one low priority (1) producer that runs every second
the producer fills a ringbuffer and the consumer drains it. When the
ringbuffer runs empty a shell script will be run (via the system()
function) that tries to change the scheduling policy of all threads in
the system from SCHED_FIFO to SCHED_OTHER. the offending task may
naturally not run at prio 99, otherwise the watchdog would never get to
run.
Here's a potential problem: The shell script potentially changes its own
scheduling policy to SCHED_OTHER prior to chnaging the offending runaway
task. Ugh! Any hint?
Also all IRQ handler threads also have their policy changed. Dunno
whether that's good or not.
For reference i pasted the script and the c file here:
unfifo_stuff.sh (the two arguments are the two thread id's of the
rt_watchdog threads, as these are not supposed to have their policy
changed).
There's also a small test program in the tarball (compiles to test_rt)
that wastes cycles SCHED_FIFO (locking the system) but exits eventually,
so it's quite safe to test the watchdog with it.
Maybe someone else find's it useful. Recommendations, tips, critique are
all welcome..
unfifo_stuff.sh
#!/bin/bash
for i in $( ps -eL -o pid ); do
if [ "$i" != "$1" -a "$i" != "$2" ]
then
chrt -o -p 0 $i
fi
done
rt_watchdog.c:
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <syslog.h>
#include <signal.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <linux/unistd.h>
#include <errno.h>
_syscall0(pid_t,gettid)
#include "ringbuffer.h"
/* how long to sleep between checks in the high prio thread */
#define SLEEPSECS 3
/* how long to sleep between writing "alive" messages to the ringbuffer
from the low prio thread */
#define LP_SLEEPSECS 1
/* the priority of the high prio thread */
#define PRIO 99
/* the priority of the low prio thread */
#define LP_PRIO 1
/* the ringbuffer used to transfer "alive" messages from low prio producer
to high prio consumer */
jack_ringbuffer_t *rb;
pthread_t low_prio_thread;
/* the thread id's for the low prio and high prio threads.
these get passed to the unfifo_stuff.sh script to make sure
the watchdog doesn't repolicy itself to SCHED_OTHER */
pid_t lp_tid;
pid_t hp_tid;
void signalled(int signal)
{
}
volatile int thread_finish;
/* this is the low prio thread. it simply writes to
the ringbuffer to signal that it got to run, meaning it is still
alive */
void *lp_thread_func(void *arg) {
char data;
struct timespec tv;
lp_tid = gettid();
/* syslog(LOG_INFO, "lp tid: %i", gettid()); */
data = 0 ;
while(!thread_finish) {
/* we simply write stuff to the ringbuffer and go back to sleeping
we can ignore the return value, cause, when it's full, it's ok
the data doesn;t have any meaning. it just needs to be there
running full shouldn't happen anyways */
jack_ringbuffer_write(rb, &data, sizeof(data));
/* then sleep a bit. but less than the watchdog high prio thread */
tv.tv_sec = LP_SLEEPSECS;
tv.tv_nsec = 0;
// sleep(LP_SLEEPSECS);
nanosleep(&tv, NULL);
}
return 0;
}
int main()
{
pid_t pid, sid;
int done;
struct sched_param params;
char data;
int err;
int consumed;
int count;
struct timespec tv;
char unfifo_cmd[1000];
/* Fork off the parent process */
pid = fork();
if (pid < 0) {
exit(EXIT_FAILURE);
}
/* If we got a good PID, then
we can exit the parent process. */
if (pid > 0) {
exit(EXIT_SUCCESS);
}
/* Change the file mode mask */
umask(0);
/* Open any logs here */
openlog("rt_watchdog", 0, LOG_DAEMON);
syslog(LOG_INFO, "started");
/* Create a new SID for the child process */
sid = setsid();
if (sid < 0) {
/* Log any failure here */
syslog(LOG_INFO, "setsid failed. exiting");
exit(EXIT_FAILURE);
}
/* Change the current working directory */
if ((chdir("/")) < 0) {
/* Log any failure here */
syslog(LOG_INFO, "chdir failed. exiting");
exit(EXIT_FAILURE);
}
/* Close out the standard file descriptors */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);
// syslog(LOG_INFO, "closed fd's");
/* syslog(LOG_INFO, "hp tid: %i", gettid()); */
hp_tid = gettid();
/* not really nessecary, but wtf */
mlockall(MCL_FUTURE);
thread_finish = 0;
done = 0;
/* get ourself SCHED_FIFO with prio PRIO */
params.sched_priority = PRIO;
if (pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶ms)) {
syslog(LOG_INFO, "couldn't set realtime prio for main thread.. exiting..");
exit(EXIT_FAILURE);
}
// syslog(LOG_INFO, "prio set");
/* create a ringbuffer for the low prio thread to signal it's alive */
rb = jack_ringbuffer_create(1024);
// syslog(LOG_INFO, "ringbuffer created");
/* create low prio thread */
err = pthread_create(&low_prio_thread, 0, lp_thread_func, 0);
if(err) {
syslog(LOG_INFO, "couldn't create low prio thread, exiting..");
exit(EXIT_FAILURE);
}
/* dirty. we really need to wait for the lp thread
to have written the lp_tid. (condition variable?) */
sleep(1);
// syslog(LOG_INFO, "created low prio thread");
/* make the low prio thread sched_fifo */
params.sched_priority = LP_PRIO;
if (pthread_setschedparam(low_prio_thread, SCHED_FIFO, ¶ms)) {
syslog(LOG_INFO, "couldn't set realtime prio for lower prio thread.. exiting..");
thread_finish = 1;
pthread_join(low_prio_thread, NULL);
exit(EXIT_FAILURE);
}
/* this is the main loop. we somply check whether the low prio thread
got to run at all by looking into the ringbuffer. If it's empty,
the low prio thread is kinda dead */
count = 0;
while(!done) {
tv.tv_sec = SLEEPSECS;
tv.tv_nsec = 0;
nanosleep(&tv, NULL);
/* sleep(SLEEPSECS); */
count++;
/* syslog(LOG_INFO, "count %i", count); */
/* see if our little brother got to run */
if (jack_ringbuffer_read_space(rb) == 0) {
/* oh oh, it didn't */
syslog(LOG_INFO, "low prio thread seems to be starved, taking measures...");
/* we pass our own TID's to the script, so we are excluded from the
scheduling policy change */
sprintf(unfifo_cmd, "unfifo_stuff.sh %i %i", lp_tid, hp_tid);
syslog(LOG_INFO, "unfifo command:");
syslog(LOG_INFO, unfifo_cmd);
if (system(unfifo_cmd) == -1) {
syslog(LOG_INFO, "unfifo command failed");
}
} else {
/* consume stuff from ringbuffer */
consumed = 0;
while (jack_ringbuffer_read_space(rb)) {
consumed++;
jack_ringbuffer_read(rb, &data, 1);
}
/* syslog(LOG_INFO, "lp alive: %i", consumed); */
}
}
thread_finish = 1;
pthread_join(low_prio_thread, NULL);
syslog(LOG_INFO, "exiting");
exit(EXIT_SUCCESS);
}
test.c:
#include <pthread.h>
#include <stdlib.h>
#include <sys/time.h>
#include <time.h>
int main() {
struct sched_param params;
int done = 0;
struct timeval tv;
time_t startsec;
unsigned long int loops;
int outer_loops;
params.sched_priority = 80;
pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶ms);
gettimeofday(&tv,0);
startsec = tv.tv_sec;
#if 0
while(!done) {
gettimeofday(&tv, 0);
if(tv.tv_sec - startsec > 10)
done = 1;
}
#endif
for (outer_loops = 0; outer_loops < 4; ++outer_loops) {
for (loops = 0; loops < 1000000000; loops++) {done += 1;}
}
exit (EXIT_SUCCESS);
}
--
Palimm Palimm!
http://tapas.affenbande.org
Hello Everybody,
DRC 2.6.1 is available at:
http://sourceforge.net/project/showfiles.php?group_id=136217
and soon it will be announced at the usual:
http://freshmeat.net/projects/drc/
Changes:
Minor corrections and improvements have been applied to the documentation
and to the pre-echo truncation inversion procedure. A new target transfer
function definition procedure based on Uniform B Splines has been
introduced. The development environment has been moved to Code::Blocks and
GCC/MinGW.
Best of listening,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
Denemo is a GTK+ front end for GNU Lilypond Music Typesetter.
http://denemo.sourceforge.net
After a long period of time denemo 0.7.4 has been released.
New features include :
Help Documentation
Support for exporting to Lilypond 2.6
All ornaments/articulations added
Replace Mode
Basic Redo/Undo Functionality for individual objects
More Templates available
Export to PDF (via lilypond processing) Courtesy of Jens Askengren
Also, this mail serves as a call for additional contributors to the
project as Lilypond is fast moving
rapid development is required to keep up. A plug-in API is being
developed to enable export to other file formats
or automated composition tools.
Any contribution will be greatly received.
Adam
I'm trying to get a digigram mixart8 aes/ebu working in a dual xeon box.
A RME digi96 card works fine in the same box and the digigram works fine
in a different uni-processor box. I don't know if it's smp related or
just the box or what. booting with nosmp does not help.
The symptom is that aplay fails with EINVAL when trying to open
/dev/snd/pcmC0D0p (or any other device on the card). jackd fails
similarly when trying to open the corresponding capture device.
Elrond:~# aplay /var/snd/999999_000.wav
aplay: main:533: audio open error: Invalid argument
The firmware is loaded. aplay works on the same box with the RME card.
This is debian sarge with 2.6.13 (also tried 2.6.14) and alsa 1.0.9.
Anyone have any thoughts?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
Hello Lists,
I don't know, where ich can fix my little problem. Maybe i 've missed some
explanations and/or haven't read my mails good enough. anyway, i try to
install a linuxbox for audio on slackware
i have installed slackware and patching the kernel 2.6.14 vanilla with
patch-2.6.14-rt2. Then i installed the set_rtlimits1.1.0 software, because
Slackware has no PAM.
First. this must be all for audio in realtime , is this right??
then i have to set the setuid. aus root i have done
bash-3.00$ su
Password:
bash-3.00# chmod ugo+s /usr/local/bin/jackd
bash-3.00# exit
bash-3.00$ ls -la /usr/local/bin/jackd
-rwsr-sr-x 1 root root 206476 2005-11-01 15:23 /usr/local/bin/jackd
bash-3.00$ whoami
soundroom
bash-3.00$ jackd -dalsa&
[1] 3202
bash-3.00$ jackd 0.100.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
bash-3.00$ ps -aux
[..]
root 3202 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa
root 3203 0.0 0.4 10472 2380 pts/1 R 12:03 0:00 jackd -dalsa
root 3204 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa
root 3205 0.0 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa
root 3206 0.2 0.4 10472 2380 pts/1 S 12:03 0:00 jackd -dalsa
[..]
bash-3.00$ jack_lsp
JACK server not running
why i can't use jack an normal user? what have i missed? why there are 5
processes of jack? is this a secure way? do i need every application as suid?
How about a software which can combine the outputs coming from
two receivers tuned to the same station?
Typically with short-wave receivers (tuned to distant radio station)
there are problems. With two or more receivers (perhaps located at
different cities and connected via Internet!) the problems can be
reduced and the station signal restored. This kind of signal
restoration must be known already in other contexts.
Strange, I recently read a recent (2000+) paper. They praised
(like having a patent on them) two innovations: (1) an audio editor
could handle non-audio signals, e.g., RF signal, ultrasound, etc.,
and (2) the above kind of receiver combination. The innovation (1)
was discussed at 1997/98 here or elsewhere, and I invented the
innovation (2) at 1993.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Dear all,
this should have come one month earlier, but such is life..anyway:
This mail is to announce the calls for papers/music/etc for the 4th
International Linux Audio Conference (LAC2006).
See http://lac.zkm.de/2006 for more information.
LAC2006 will take place 27-30 April 2006, again at the ZKM | Institute for
Music and Acoustics in Karlsruhe, Germany.
We have tried to simplify things a little bit since LAC2005. There are
calls for papers, demos, workshops, and music. The former category BOFS
has been merged with the workshops. There is no call for project notes
anymore; instead we have the call for demos now. The call for posters
has been discarded.
We hope everybody agrees that this is an improvement and we are looking
forward to many interesting submissions for LAC2006!
Please feel free to forward this email to anybody who is interested.
Thank you for reading!
Frank Neumann and Goetz Dipper
***********************************************************************
Call for Papers
We invite submissions of papers addressing all areas of audio
processing based on Linux and open source software. Papers can focus
on technical, artistic or scientific issues and can target developers
or users. This includes (but is not limited to) the following
categories:
* Computer Music
* Music Production
* Instruments
* Drivers and Sound Architecture
* Audio Distributions
* Generic (Usage, Documentation etc.)
The conference is held in english, so all papers and presentations
will have to be done in english, too.
Length of a paper is 4-8 pages. Papers have to include an abstract
(50-100 words). The abstract will be published separately on the
conference website once the paper has been accepted. Also, papers
should include up to 5 keywords.
In general talks should take 20-30 minutes followed by 5 minutes
discussion.
Please notify us if you need a special technical setup. The technical
standard setup will be:
* microphone (head set)
* projector with XVGA input (resolution 1024x768)
* stereo speaker setup with mini jack input
If you are not able to bring your laptop along with you, please notify
us in advance.
How to submit
* File format is PDF, formatted for A4 paper. Make use of the
templates for paper formatting available at:
http://lac.zkm.de/2006/downloads.shtml
* See our check list to ensure that you do not forget to enclose
all necessary information:
http://lac.zkm.de/2006/submission_instructions.shtml
* Send your paper and all necessary information by 8 Jan 2006
via email to this address: lac2006 at zkm dot de
* You will be notified by 19 Feb 2006 whether your paper has been
accepted. The reviewers may ask you to modify your paper in
order to be accepted. The deadline for the final version is
March 12, 2006.
Important Dates
08 Jan 2006: Paper submission deadline
19 Feb 2006: Notification of acceptance
12 Mar 2006: Final version deadline
27 - 30 Apr 2006: Conference
***********************************************************************
Call for Demos
This is the only new category of LAC2006. You do not need to write a
whole paper, but rather a short abstract only (50-100 words). This
category is mainly thought for software demos. Be aware though that in
case of too many submissions papers take priority over demos.
See section "Call for Papers" for info on the duration of talks and
the technical setup.
How to submit
* See our check list to ensure that you do not forget to enclose
all necessary information:
http://lac.zkm.de/2006/submission_instructions.shtml
* Send your abstract and all necessary information by 8 Jan
2006 via email to this address: lac2006 at zkm dot de
* You will be notified by 19 Feb 2006 whether your submission has
been accepted.
Deadline for submissions is 08 Jan 2006.
***********************************************************************
Call for Workshops
With respect to their content workshops do not differ from talks:
Workshops can have technical focus as well as artistic or scientific
focus. Workshops can be targeted to developers as well as users. See
section "Call for Papers" for more info on this.
The shape of the workshop is completely up to you. E.g. it can be
tutorial-like ("how to write an ALSA driver/ a jack application/ a
LADSPA plugin/ etc.") or it can be BOFS-like (e.g. a meeting of
like-minded users and/or developers to exchange experience and
knowledge about a specific topic), or it can be anything in between.
Workshops can take place in seminar rooms or in a public space like
the ZKM cafe. Depending on the location, attendance might be limited
to ca 10 people.
There is no deadline for submitting workshops. However, we strongly
encourage you to submit early. It will be more likely to get a free
slot and it will be easier for attendants to know about the workshop
if it is published on the conference website. If you expect the
attendants to prepare their laptops for your workshop (e.g. by
installing some software) or if there are other requirements, please
note so in your abstract.
How to submit
* See our check list to ensure that you do not forget to enclose
all necessary information.
http://lac.zkm.de/2006/submission_instructions.shtml
* Send an abstract (ca. 50-100 words) and all necessary
information via email to this address: lac2006 at zkm dot de
* The abstract will be published on the conference website once
the workshop has been accepted (not before 27 Feb 2006 though).
***********************************************************************
Call for Music
There will be some concerts during the conference. We are looking for
music that has been produced completely or mostly under Linux and/or
with open source software:
* "Serious" compositions, to be played in a concert-like context
* Electronica, Chill-Out, Ambient etc., to be played in a less
formal, "party-like" context.
Additionally you are welcome to give a talk about your piece. We
encourage you especially to show how you made the piece using open
source software. Please send a short abstract (ca. 50-100 words) if
you want to give a talk.
If you want to participate, send your composition(s) to this address:
LAC2006 - Call for Music
ZKM | Institut fuer Musik und Akustik
Lorenzstr. 19
D-76135 Karlsruhe
Germany
Make use of one of the following media formats:
* Media: Audio-CD, DVD or CD-ROM
* File formats: aiff or wav
* Channels: mono, stereo or multi-channel
* Samplerate: 44.1, 48, or 96 kHz
* Resolution: 16 or 24 bit
Include the following items with your submission (in English):
* Requirements (speaker setup, instruments etc.)
* A filled-out and signed printout of the form available here:
http://lac.zkm.de/2006/downloads.shtml
For the printed programme and to be published online and on the
conference CD, in continuous text (no table or list please):
* A short commentary on the composition(s) (each ca. 150 words)
* A short Curriculum Vitae (ca. 100 words)
Deadline for submissions is 08 Jan 2006.
A jury will select the compositions that will be
performed/played. Furthermore, the jury will give out three prices to
participants to contribute to their travel expenses.
Besides artistic criteria and technical reasons, these criteria apply
for the selection:
* Tape pieces or pieces which are performed by the composer
herself will generally have more chances to get included.
* If we get more pieces than we can include in the programme,
composers who are attending the conference are preferred.
Terms and conditions for participation can be found in the form
mentioned above. This form includes among other things:
* I will receive no fees whether my composition is played or not.
* GEMA fees (in case of performance) will be paid by ZKM.
* The material I send to ZKM will not be returned.
Additionally to this Call for Music, there will be an open stage
called
"Plug & Chill - The Linux Jam Night"
at Saturday night (29 Apr 2006), where attendents of the conference
are invited to perform their pieces in a less "official"
context. There is no deadline for this, so people can decide during
the conference if they want to participate.
However if you already know that you want to participate do not
hesitate to inform us. Send us an email to lac2006 at zkm dot de and
include a description of your equipment and a short characterisation
of your music (keywords only).
During the conference it is possible to register at the info
desk. Note that there is a time limit for "Plug & Chill". If we have
received too many registrations already you might not get a slot.
Contributions to "Plug & Chill" should not exceed 10 min.
There will be a room at ZKM where people can meet during the
conference and rehearse for "Plug & Chill".
***********************************************************************
hello,
i would like to mix several (up to six) s/pdif sources in the digital
domain. the problem is, that every source has its own clock and possibly
different sample rate. is there any software that can open several
non-synchronized sound cards at the same time? iirc there was a patch
for jackd for drift compensation, but i cannot find it in anymore and
i'm also not sure if that would help.
Minidisc 44100.17 ==S/PDIF==> Sound Card 1 ==> Audio App \
\
Laptop 48000.23 ==S/PDIF==> Sound Card 2 ==> Audio App --> D/A (96khz)
/
DAT 48000.09 ==S/PDIF==> Sound Card 3 ==> Audio App /
