Hi all!
I know it's completely OT, but I think there maybe people here, who could
help me.
Problem is: I'm still on my libcui (character user interface) project and I
wonder:
I push a button, slide a slider... How does the UI notify the program of
this change? How do Engine and UI communicate?
Please anyone: HELP ME!
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide
Hi,
Are there any linux tools out there that will sample the line in, and
display a detailed spectrum scope of the detected sound?
E.g.
http://www.pcavtech.com/soundcards/ct462048/SNR_LB_FS.gif
Eventually I wish to send a test signal from one sound card to another
and compare the frequency response/noise etc. of the line input of the card.
James
The wiki that was at http://fugal.net:2500 is no longer there. It now
has its own subdomain: http://lawiki.fugal.net
I would be perfectly happy to entertain a more dedicated domain name, or
more appropriate subdomain of an existing domain, if someone wants to
foot the bill.
If I can figure out how in a short amount of time, I'll put up a
redirect at the old address.
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
netjack-0.11rc5
Some pieces of Code which can deliver you the full jackd experience with
multiple Computers.
Links JackPorts via generic IP networks.
The alsa_in and alsa_out client can connect jackd to an unrelated
alsa Soundcard. And their algorithm has been improved.
Also downsampling and bitrate reduction is included now, to make it work
on low bitrate links. Tested over the Internet some times now, with
moderate success.
Also compiles on OSX... with-alsa=0
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
The following post came across the the Open graphics list from one of
the founders of the project looking for other things to do with the
technology they have developed.
I thought I'd post it here. Anyone interested should contact Tim.
For anyone who dosen't know what OGD1 is see: http://kerneltrap.org/node/6262
I would think that with a little guidence from this list and tight
integration with ardour and jack that a _really_ kicking pro audio
setup could be produced.
=============
From: Timothy Miller <theosib(a)gmail.com>
To: ogml <open-graphics(a)duskglow.com>
Since we're having a bit of a lull in the discussions on OGML, I
thought I might start off a discussion about some ideas I've had that
would benefit the Linux community as well as give OGP and Traversal a
boost financially.
The Open Graphics Project has gotten everyone involved a lot of
attention. While it's still possible to get graphics cards supported
by open source drivers, that supply is dwinding. At the rate things
are going, we'll soon have no choices left. Politically and socially,
the OGP is a great idea. Economically, however, it's entirely a
different story. Because of the development and costs involved,
low-end graphics is actually not such a great place to start. The
attention we get because we want to do graphics is a major driving
force, but there are much better ways to get our stream of funds
started.
One such idea that's been brought up before is ultra high end audio.
The low-end is solved; it's called AC97 and is found in every PC
chipset you can buy today. But imagine taking what would normally
cost tens to hundreds of thousands of dollars in audio recording and
production equipment and applying the open source model to it.
Designing and producing a low-end commodity product is hard. But
designing a niche audio product that sold competitively for thousands
of dollars is relatively easy to pull off. To begin with, we now
become much less cost-sensitive for parts, so the end product can be
FPGA-based. That makes OGD1 an ideal development platform for a new
audio device; in fact, it's major overkill. Once the new design is
finished, we'd mass-produce a new board using a smaller FPGA and
include all of the audio I/O hardware directly on-board.
I know basically nothing about audio technology. But given what
little I do know, here are some things that I think would be
relatively easy to do with OGD1 and, what shall we call it, OAC1:
- 60+ audio channels (pick your combination of in and out)
- (A specialized card could handle lots more channels)
- 24-bit precision per channel
- Sample rates in the hundreds of kilohertz
- Thousands of audio samples and MIDI instruments
- Sample-based and algorithmically-generated sound-effects
- Fourier analysis, band filters, mixing, and other sorts of math
stuff that if I could name it, you'd be impressed
- Noise-free signals (because we have experience with graphics)
- Accelerated "3D sound"
- Accelerated compression/decompression
- Lots of other things
Given hardware acceleration for most parts of audio processing, plus
some excellent piece of open source sound studio software, I don't see
why we couldn't produce a combination that is as good as or better
than what you find in music recording studios, television stations,
and every other place where you might find a need for this. Imagine
how much money this could save musicians. The only thing we can't
provide is the recording room with the proper accoustics.
If a reduced version of the card sold for $1000, we'd have more than a
few gamers and multimedia enthusiasts buying it for their 50-speaker
surround-sound reality-immersion systems.
Were such a project started, I would have to carefully tune my
involvement. Since Howard, Andy, and I do not have a background in
audio technology, it would probably be best for someone with
appropriate experience to lead. But if the community can spec this
product and help us design it (we can put into hardware any algorithm
you specify), Traversal can produce it. The whole project, from start
to finish, would be developed under GPL. This would be quite a major
effort, due to the requirement for more than just drivers. Unlike the
OGP, which started out of a corporation and has retained some of that
flavor, the OAP would have to organize itself and push itself along.
In my mind, the first major problem is getting the right people in the
community together to develop the specs.
So, what do you all think of this idea? Comments? Suggestions?
Discussion! :)
==================
--
Richard A. Smith
Hi all,
I'm trying to restart a liblo thread with the same port, but something
seems to being kept hold of, as it fails (this may be intentional though).
I have a test case here - am I being daft, or should this work:
---8<---
#include <stdio.h>
#include <lo/lo.h>
void handler(int num, const char *msg, const char *path)
{
printf("liblo server error %d\n",num);
}
int main()
{
printf("once\n");
lo_server_thread thr = lo_server_thread_new("4444",handler);
lo_server_thread_start(thr);
lo_server_thread_stop(thr);
lo_server_thread_free(thr);
printf("twice\n");
thr = lo_server_thread_new("4444",handler);
}
--->8---
I get the output:
once
twice
liblo server error 9904
cheers,
dave
On 4/6/06, James Courtier-Dutton <James(a)superbug.co.uk> wrote:
> Creative have actually donated an X-Fi and an EMU1212M to me.
> No datasheets, but at least having the hardware is a start. (Creative
> pass me some datasheets for other cards though)
> I have currently got as far as horrible noises coming from the EMU1212M.
So, does it mean that soon we'll have linux drivers for Emu 1212, 1616 and 1818?
Regards,
Dmitry.
Hello List,
I'm trying to find a library or code-snippet in order to do audio
resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to
resample the data in realtime - resampling a buffer of data, not a
soundfile. The quality doesn't need to be good so I guess the best
solution might be linear audio resampling. The device to do the
resampling on is an ARM CM-X255 running at 400MHz.
I tried out libsamplerate so far but when I tested it with the
soundfile conversion test program it needed 3,5 secs to sample from
8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me.
Is there something faster that can do the job?
Any suggestions are highly welcome
Greetings,
Tobias
Quoting Dave Robillard <drobilla(a)connect.carleton.ca>:
> On Tue, 2006-04-04 at 13:22 +1000, Loki Davison wrote:
> * At least 1 ADAT Lightpipe in/out
I'd vote for at least 4 ADAT inputs so you could connect two 8 channel
preamps using 88.2k or 96k to the device. ;)
Sampo
Greetings:
First, thank you to everyone who responded to my original query. I now
have a much better idea how I want to do this project.
I definitely want to involve members of this group. Some of you have
offered to take on particular chapters, and that seems to me the best
approach. I believe we can complete the work in record time by spreading
the work around. I'll speak with my publisher about this plan. If he
approves this approach we'll start work immediately.
Some respondents wrote to me off-list and have offered to assist. I'll
be in touch with you all after talking with Bill Pollock. If Bill gives
us a green light I'll start organizing the distribution of work
immediately. I'll communicate directly with you regarding style
preferences, format requirements, deadlines, etc. I must emphasize that
this project is commercial work, i.e., we'll have editors at the
publishing house and there will be demands that certain dates be met.
Please, only take on the work if you're sure you can work under those
conditions.
If the community approach is accepted I'll post a list of topics and
areas that need attention. I have a large amount of unedited/incomplete
material that I'm willing to offer as starting points.
I've been thinking about the royalties issue. I'm far from a final plan,
but I think it might be possible to route some (all?) of the royalties
to the Linux Audio Consortium. The community can then decide how to use
it. I can't leave this issue vague, my publisher will need to know who
is in charge of accounts receivable, and I can't simply accept
contributions from the community and not reimburse those contributors.
How that reimbursement takes place can be left to the individual
contributors, or we may decide to simply throw everything in one
direction (e.g. linuxaudio.org).
Btw, I especially appreciate the community's response re: the 2.4 kernel
series. It is laid to rest, there will be coverage only from kernel 2.6
upwards. Thank goodness.
No Starch has already accepted my outline for the project. At some point
I'll post that outline on the Web for the community to consider.
However, please bear in mind that there will be limitations of space and
scope. I'm unlikely to be able to cover games, consumer devices, or
telephony. Alas, material for a programmer's guide will probably not be
accepted. IMO that really requires a separate book now. A developer's
guide to ALSA and JACK is certainly timely and needed, but I'm not the
one to write that book.
Again, if you're interested in writing for this project please contact
me off-list. Specify your area of interest and we'll go from there.
Best regards,
dp