Hi. I need to know if there exists or if someone have coded a device driver
that may split one stereo source input (/dev/dsp0) to two pseudo devices
(something like /dev/dsp0L for left channel and /dev/dsp0R for right
channel).
I need this to split a 2 channel real time signal to two different
applications than only accept a /dev/dsp? for input.
I can do it if I install 2 soundcards on my machine and feed each separated
mono source to each card but I feel that I am waisting one card.
Any help pointing to a page with instructions in how to program a device
(/dev/?) may help.
Regards,
Fernando
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus
hi,
has anybody had any success using portaudio v19 to connect to jack
(0.80.0 or 0.90.1) ?
regards,
x
--
chris(a)lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
>That's right. But, Paul and I have been working closely with this and
>don't have much faith in the correctness of the 2.4 scheduler. Like
>all non-trivial software components it has bugs, and getting them
>fixed is difficult, if not impossible
I dont quite understand the 2.4 scheduler, but I'm, eh, guessing that
there is about 10% chance the following patch might fix the problem:
kjetism@notam02 ~/linux/linux-2.4.23-rc1/kernel $ diff -u sched.c
sched_g.c
--- sched.c 2003-11-16 14:18:08.000000000 +0100
+++ sched_g.c 2003-12-03 09:31:32.000000000 +0100
@@ -180,6 +180,7 @@
if (p->mm == this_mm || !p->mm)
weight += 1;
weight += 20 - p->nice;
+ if(weight>999) weight=999;
goto out;
}
If someone bothers, please explain why it wont, if it doesnt work, and
if anyone knows. This is quite interesting. :)
--
Please excuse cross postings, and freely forward this message to anyone
who might be interested. Thank you.
Best,
Tae Hong Park, ICMC 2004 Publicity Chair
----------------------------------------
Call for Works: ICMC 2004
The University of Miami is pleased to announce the general call for
submissions to ICMC 2004, to be held 1-6 November in Miami, Florida USA.
These documents, along with PDF submission forms and paper templates are
posted on the ICMC 2004 web site at www.icmc2004.org.
Best regards,
Colby Leider, Chair
> http://www.museresearch.com
>check the "technology->architecture" page (Flash). they are running
>linux. they also run VST plugins. how? what's going on ...
Just wondering if anyone asked them why they claim to be "license free"?
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Apparently upon the beginning of the barrage, the donkey broke
discipline and panicked, toppling the cart. At that point, the rockets
disconnected from the timer, leaving them strewn around the street.
Tethered to the now toppled cart, the donkey was unable to escape before
the arrival of U.S. troops.
United Press International
Rockets on donkeys hit major Baghdad sites
By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM
while we're discussing various kernel security patches to facilitate
easier access to SCHED_FIFO/mlockall, i have another idea for a patch
that some people *might* like.
a new system call. call it "switch_to()". takes a PID (actually, it
needs some kind of TID), and does something very similar to
sched_yield() except instead of giving up the processor to whatever
the scheduler thinks is right, it yields to the specific
process/thread.
security: the target thread has to be using the same RT scheduling
policy (FIFO or RR) as the initiating thread. this means that it can
only be used to cause denial-of-service attacks that were already
trivial (because SCHED_FIFO was already available to the initiating
thread).
this could be used to completely short-circuit the FIFO mechanism used
by JACK in favor of completely deterministic, FS-lock-free
system. when you add in stuff like this (from ingo, discussing NPTL):
our kernel thread context switch latency is below 1 usec on a
typical P4 box, so our NPT library should compare pretty favorably
even in such benchmarks. We get from the pthread_create() call to
the first user instruction of the specified thread-function code in
less than 2 usecs, and we get from pthread_exit() to the thread
that does the pthread_join() in less than 2 usecs as well - all of
these operations are done via a single system-call and a single
context switch.
you end up with a truly superb architecture for the kind of thing
we're doing with JACK already.
however, note this comment from ingo as well, which i consider
short-sighted, and is part of the reason for my thinking about
switch_to():
M:N's big mistake is that it concentrates on what matters the least:
useruser context switches. Nothing really wants to do that. And if
it does, it's contended on some userspace locking object, at which
point it doesnt really matter whether the cost of switching is 1
usec or 0.5 usecs, the main application cost is the lost paralellism
and increased cache trashing due to the serialization -
independently of what kind of threading abstraction is used.
any thoughts? adding a syscall is a pretty trivial patch to create.
--p
On Monday 01 December 2003 20.48, Paul Davis wrote:
> i'd appreciate test reports ASAP, so that out trusty release
> technician (the very wonderful taybin rutkin) can get a new release
> out in the near future.
>
alsa_driver.c
driver->period_usecs =
(jack_time_t) floor ((((float) driver->frames_per_cycle) /
driver->frame_rate) * 1000000.0f);
jackd/engine.c
poll_timeout = (engine->control->real_time == 0 ?
engine->client_timeout_msecs :
engine->driver->period_usecs/1000);
- - -
if (poll (pfd, 1, poll_timeout) < 0) {
Isn't this dangerous?
* What happens if period_usecs < 1000?
Well poll_timeout gets 0 since period_usecs is an uint64_t
A poll with time out of zero will return immediately.
OK?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
I am contemplating buying a laptop of some sort, to develop on.
I was wondering how many of you are using an x86 laptop and how
many are using a ppc laptop :)
It looks to me as if Apples laptops are rock solid and don't suffer
from buggy ACPI to start with. Or is this extra quality just a myth ?
I know some applications are not ported yet to ppc and suffer from
x86-isms, but that should be fixable I guess :)
anyway, thanks for your input,
v