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
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
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.
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
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
I thought it might be of interest to other plugin developers to learn what
my experiences were of porting my LADSPA plugins to the LV2 draft.
As some of you may know the primary source for my plugins is a wierd XML
format, so porting that was fiddly, but didn't involve much manual effort,
"just" coding a handful of XSLT sheets.
However I ported a couple by hand to get a feel for it, and basically it
comes down to deleting the constants and runAdding method from the ladspa
.c file, sedding some struct names and replacing occurances of LADSPA_Data
with float (except the last argument to connectPort, which is a void *).
It may be possible to do it automatically with a cpp/m4 hack, or a perl
script or something, but I doubt its worth the effort.
Writing the turtle is a little more involved, but I'm sure some
enterprising person can write a program to generate .ttl from existing
LADSPA .so's, then it will be a case of adding any additional data you
want to express by hand.
Writing the Makefile was pretty tricky, as the plugin data and code all
ends up in a plugin directory, but it wasn't too bad once I figured out
how best to layout the source. I decided not to use automake/autoonf/
ibtool as I felt it caused more probems than it solved with LADSPA. The
Makefile would have been less critical if I didn't have quite so many
plugins; I didn't want to recurse into every plugin directory, which is
the obvious thing to do.
- Steve
On Monday, 19 June 2006, Stephen Cameron wrote:
> > http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
>
> Thanks, I'd found that already... it's slightly better than no
> documentation. :-) Â But I'll take what I can get. Â It's a little
> rough going at first when it kind of assumes you're aware of a big
> picture that, in my case, I was almost totally unaware of. Â As you
> slowly figure it out, and the bigger picture of how all the pieces
> fit together -- sequencer ports, clients, channels, and how they're
> named and accessed and what's what, the docs become a little clearer.
>
> Helps to understand it before you read it, heh.
This document is the original proposal, by the ALSA sequencer author:
http://www.alsa-project.org/~frank/alsa-sequencer/index.html
A bit outdated, but a very intersting reading, if you want to get the big
picture.
Regards,
Pedro
Hi,
I'm trying to figure out how to use the ALSA sequencer
with my app. (to date, I've been just using raw midi).
What I'm supposed to use for the "name" parameter for snd_seq_open
is not exactly clear. I've been using "hw:0,0" and it returns zero,
but I'm not sure it's right (see aconnect -lio output below.); That's
my soundcard, however, I'm really trying to send to a softsynth.
[scameron@zuul ~]$ amidi -l
Device Name
hw:0,0 Audigy MPU-401 (UART)
hw:0,1 Audigy MPU-401 #2
hw:0,2 Emu10k1 Synth MIDI (16 subdevices)
hw:0,3 Emu10k1 Synth MIDI (16 subdevices)
[scameron@zuul ~]$
I have code to open and set up an alsa client port that looks
like this:
struct midi_handle *midi_open_alsa(unsigned char *name)
{
int rc;
struct midi_handle_alsa *mh;
unsigned char clientname[255], portname[255];
sprintf(clientname, "Gneutronica (%d)", getpid());
mh = (struct midi_handle_alsa *) malloc(sizeof(*mh));
if (mh == NULL)
return NULL;
rc = snd_seq_open(&mh->seqp, name, SND_SEQ_OPEN_OUTPUT, 0);
if (rc < 0) {
printf("snd_seq_open returns %d\n", rc);
free(mh);
return NULL;
}
rc = snd_seq_set_client_name(mh->seqp, clientname);
if (rc < 0)
printf("snd_seq_set_client_name failed \n");
sprintf(portname, "Gneutronica output (%d:%d)", getpid(), 0);
mh->outputport = snd_seq_create_simple_port(mh->seqp, portname,
SND_SEQ_PORT_CAP_READ|SND_SEQ_PORT_CAP_SUBS_READ,
SND_SEQ_PORT_TYPE_MIDI_GENERIC);
if (mh->outputport < 0)
printf("snd_seq_create_simple_port failed\n");
return (struct midi_handle *) mh;
}
struct midi_handle_alsa is just this:
struct midi_handle_alsa {
snd_seq_t *seqp; /* alsa sequencer port */
int outputport;
};
This *appears* to work... When I run my app, I can see this:
[root@zuul ~]# aconnect -loi
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
Connecting To: 15:0
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 16: 'Audigy MPU-401 #2' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
client 17: 'Emu10k1 WaveTable' [type=kernel]
0 'Emu10k1 Port 0 '
1 'Emu10k1 Port 1 '
2 'Emu10k1 Port 2 '
3 'Emu10k1 Port 3 '
client 128: 'FLUID Synth (6096)' [type=user]
0 'Synth input port (6096:0)'
client 129: 'Gneutronica (14693)' [type=user]
0 'Gneutronica output (14693:0)'
There's my app, client 129, and I can do this:
[root@zuul ~]# aconnect 129:0 128:0
[root@zuul ~]# aconnect -loi
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
Connecting To: 15:0
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 16: 'Audigy MPU-401 #2' [type=kernel]
0 'Audigy MPU-401 (UART)'
32 'Audigy MPU-401 #2'
client 17: 'Emu10k1 WaveTable' [type=kernel]
0 'Emu10k1 Port 0 '
1 'Emu10k1 Port 1 '
2 'Emu10k1 Port 2 '
3 'Emu10k1 Port 3 '
client 128: 'FLUID Synth (6096)' [type=user]
0 'Synth input port (6096:0)'
Connected From: 129:0
client 129: 'Gneutronica (14693)' [type=user]
0 'Gneutronica output (14693:0)'
Connecting To: 128:0
[root@zuul ~]#
Which, I think looks correct... the aconnect makes
client 128:0 subscribe to 129:0, right?
But, when I try to send events from my app, they don't
seem to go through.
Here's the event sending code:
void midi_noteon_alsa(struct midi_handle *mh,
unsigned char channel,
unsigned char value,
unsigned char volume)
{
struct midi_handle_alsa *mha = (struct midi_handle_alsa *) mh;
snd_seq_event_t ev;
snd_seq_ev_clear(&ev);
snd_seq_ev_set_source(&ev, mha->outputport);
snd_seq_ev_set_subs(&ev);
snd_seq_ev_set_direct(&ev);
ev.type = SND_SEQ_EVENT_NOTEON;
ev.data.note.channel = channel;
ev.data.note.note = value;
ev.data.note.velocity = volume;
ev.data.note.off_velocity = 0;
ev.data.note.duration = 100; /* it's drums... there is no note off. */
printf("Sending event to port %d, note=%d, vel=%d, pid=%d\n",
mha->outputport, ev.data.note.note, ev.data.note.velocity, getpid());
snd_seq_event_output(mha->seqp, &ev);
return;
}
I get output from my app that looks like:
Bass Drum
Sending event to port 0, note=35, vel=100, pid=14693
Bass Drum
Sending event to port 0, note=36, vel=100, pid=14693
Rim Stick
Sending event to port 0, note=37, vel=100, pid=14693
Tom Hi
Sending event to port 0, note=38, vel=100, pid=14693
Hand Clap
Sending event to port 0, note=39, vel=100, pid=14693
(The channel is zero.)
If I use raw midi (write to a file descriptor hooked to /dev/snd/midiC2D0
and use snd-virmidi acconnected to Fluidsynth... it works.
I'm obviously missing something, but it's not obvious to me
what it is...
Any ideas?
Thanks,
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi Nishanth,
Hope you are doing well.
We have an issue with the Linux kernel 2.6 for OMAP 2430
which is available on TI site for download. The Stereo effect
does not work. Would you advise us some thing, why it does
work? We are planning to test our surround and other effect modules
on this target but due to stereo does not work, we can't test our midi
engine with effect module.
Please advise us if any to come out of this problem.
Best Regards
chandrashekhar
----- Original Message -----
From: "Menon, Nishanth" <x0nishan(a)ti.com>
To: "chandrashekhar singh" <cp_singh(a)faith.co.jp>
Sent: Wednesday, June 07, 2006 11:01 PM
Subject: RE: Linux Audio driver problem on TI OMAP 2430
Chandrashekar,
If ur using MV kernel, then there are some interesting things u can play
with :).. u can now choose to switch b/w the onboard speakers and the
headset speakers using IOCTLs (don't remember offhand what it was).
There is one interesting factor I had reported to the SDP team,
recording can be done from headset mic (the 2.5 mm) only if I plug in a
headset into the 3.5mm jack.. just thought I'd warn u on this.. minor
irritant, but better know than being surprised..
Regards,
Nishanth Menon
> -----Original Message-----
> From: chandrashekhar singh [mailto:cp_singh@faith.co.jp]
> Sent: Tuesday, June 06, 2006 10:18 PM
> To: Menon, Nishanth
> Cc: Khasim, Syed
> Subject: Re: Linux Audio driver problem on TI OMAP 2430
>
> Hi Nishanth,
>
> Thanks for your prompt response which saved our alot of time
> now we have tested our application on revised version of Board
> component and it seems working perfectly.
>
> Thanking you all.
> ========================
> \ chandrashekhar singh
> \ cp_singh(a)faith.co.jp
> / Faith Inc. Tokyo
> / www.faith.co.jp
> ========================
> ----- Original Message -----
> From: "Menon, Nishanth" <x0nishan(a)ti.com>
> To: "Khasim, Syed" <x0khasim(a)ti.com>; "chandrashekhar singh"
> <cp_singh(a)faith.co.jp>
> Sent: Wednesday, May 31, 2006 9:52 PM
> Subject: RE: Linux Audio driver problem on TI OMAP 2430
>
>
> Hi Chandrashekar,
> Please look for modification to the following board revision numbers:
> * T2 Companion Board, Revision 750-2012-001 (E).
> * Connectivity Board, Revision 750-2003-002 (D).
> * Enhanced LCD/Audio Board, Revision 750-2038-001 (C).
> Regards,
> Nishanth Menon
> > -----Original Message-----
> > From: linux-omap-open-source-bounces(a)linux.omap.com
> [mailto:linux-omap-
> > open-source-bounces(a)linux.omap.com] On Behalf Of Khasim, Syed
> > Sent: Wednesday, May 31, 2006 7:29 AM
> > To: chandrashekhar singh; linux-omap-open-source(a)linux.omap.com
> > Subject: RE: Linux Audio driver problem on TI OMAP 2430
> >
> > Hi Chandra shekhar,
> >
> > Which version of 2430 SDP is this and are you working with TWL4030
> (T2)
> > audio codec?
> >
> > There was a noise issue with T2 audio codec and got resolved later.
> This
> > needs some hardware modifications. You might have to upgrade your
> board.
> > Please contact your vendor.
> >
> > Regards,
> > Khasim
> >
> > -----Original Message-----
> > From: linux-omap-open-source-bounces+x0khasim=ti.com(a)linux.omap.com
> >
[mailto:linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com]
> > On Behalf Of chandrashekhar singh
> > Sent: Wednesday, May 31, 2006 6:07 AM
> > To: linux-omap-open-source(a)linux.omap.com
> > Subject: Linux Audio driver problem on TI OMAP 2430
> >
> > Dear All,
> > We are working on a porting on porting of a audio application on
> > TI OMAP 2430.
> >
> > We have got running Monta-vista linux kernel 2.4 on this target
board
> > and ported our application, while playing we noticed that there is
> > some noise generated by audio driver in back ground.
> >
> > For testing purpose we have downloaded Genaral Linux kernel 2.6 for
> > OMAP 2430 from TI site and tested our appliction on this.
> >
> > The problem remain same on both linux.
> >
> > If any body had experience this problem and have got some solution
> > please help me out.
> >
> >
> > Thanks in advance.
> > chandrashekhar
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source(a)linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source(a)linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source