hello * !
frank neumann has sent me some photos he took during the lad meeting at
the zkm in march. they have been uploaded to the lad page and can be
viewed at
http://www.linuxdj.com/audio/lad/contrib/zkm_meeting_2003/photos/frank_n_ph…
have fun.
--
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
-- Charter of the United Nations, Article 2.4
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
(Sorry for reposting to LAD, I've already sent this to alsa-user but I'm
unsure which list is more appropriate so I'm trying both)
Hello,
I have a machine with two DELTA 1010LT cards and they work very well
with ALSA (using ALSA binaries from Planet CCRMA).
I would like to write a single threaded application
that is able to write on all out channels (analog outs 1-8 of card 1 and 2 =
16 channels) simultaneously.
The card's manual says that in order to synchronize two cards one should
select the first card as master and set the internal clock generation
(I do this via envy24control) and then connecting the SPDIF-OUT of card 1
to the SPDIF-IN of card 2 and set the card 2's clock source to SPDIF-IN.
So far so good (from the hardware point of view)
I managed to write ALSA code that writes to a single card:
it opens the PCM hw:0 device selects 10 channel interleaved S32_LE mode
and then writes out some data. This works perfectly for a single card.
Now my question:
I would like to extend this app so that it writes to both cards simultaneously
without going out of sync.
I assume that the SPDIF writing and clocksouce selection provides this
from a hardware point of view, but I am unsure how to proceed from with
the application code since the ALSA docs do not mention such a scenario.
currently for a single card setup,
I do the usual card setup and then sit in a while loop that does
while(1) {
snd_pcm_writei(pcm_handle, audiobuf, MY_PERIOD_FRAMES);
}
Is the following way to extend the app to two cards correct ?
call the functions to setup card 1 (hw:0)
call the functions to setup card 2 (hw:1)
while(1) {
snd_pcm_writei(pcm_handle1, audiobuf1, MY_PERIOD_FRAMES);
snd_pcm_writei(pcm_handle2, audiobuf2, MY_PERIOD_FRAMES);
}
(where audiobuf1 is the buffer sent to card 1 while audiobuf2 is
the buffer sent to card 2)
Or is some special "sync start" procedure needed ?
I remember ALSA had/has provides some functionality in this regard
but I was unable to find documentation about it.
Thanks in advance for your help.
PS: does the DELTA cards only support the interleaved mode ?
The model seems a bit inefficient since in most apps the data
sources are non interleaved audio streams.
(eg a HDR app that outputs each audio track to a different audio channel)
cheers,
Benno
http://linuxsampler.sourceforge.net
-------------------------------------------------
This mail sent through http://www.gardena.net
Just a quick notification to you all that pawfal (the webste for arty
free software types) has been reborn as a wiki, and is open for all to
use and abuse. Feel free to add information of your own - we're
especially interested in people using linux and/or free software for
artistic purposes to put links to their work there, you can create your
own wiki page etc etc.
http://www.pawfal.org
For more information, if you are new to wiki's:
http://www.pawfal.org/index.php/PawfalFaq
cheers,
dave
Hi all, I know this is off-topic, but at this point I could use any help
I could get since I am just about ready to do a clean reinstall
(Something that I do really not feel like doing right now).
I had Mdk 9.0 and upgraded it to 9.1. Since, when I have dynamically
linked apps to the /usr/lib/libc.so.6 (or /usr/lib/libc.so) I always get
the same error:
Error while loading shared libraries: /usr/lib/libc.so.6: invalid ELF
header
I tried reinstalling 9.1 glibc and glibc-devel and that did not fix it.
I also tried installing libelf rpm for mandrake and that did not do a
thing. Finally I even installed the newest cooker version of these two
files and I still come up with the same error. This brings me to a
conclusion that the problem lies somewhere else, but where?
Rebuilding of glibc from srpm eventually fails with some weird error
(can't remember it any more), so that option is out of question.
Furthermore, what is really odd, is that the clean install on another
machine of the same distro does not have this problem, yet the files in
question libc.so (and other related ones) are IDENTICAL to the ones I
have on this machine (at least they were before I installed the latest
glibc from the cooker).
I also checked binutils package and it is the same on both machines.
So what gives?
Does anyone have any suggestions as to how could I go about resolving
this issue?
Any help at this point is greatly appreciated! Sincerely,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico
HI!
I'm trying to write very simple software synthesizer under Linux just for my
own educational purpose.
but one problem i came over is the following:
I made the audio thread shced_fifo with max priority. My GUI thread is
sched_other. To allow the GUI to rerspond, I thought i could just put the
audio thread to sleep for the playing length of the buffer (7ms). But the
minimum tick interval of the linux scheduler is 10ms and its not even sure
that the thread will sleep for exact 20ms. So how can I avoid underruns if
the timing is so unreliable?
Thanks in advance
Alex
Hi,
jack_input is an AlsaPlayer input plugin. Connect any JACK output port
to the alsaplayer input ports.
Pros:
* Volume / pan control through alsaplayer
* Visualize your JACK streams with alsaplayer scopes
* Feed live input to alsaplayer (line-in, mic, etc)
* Export jack streams to other audio subsystems supported by alsaplayer
(not recommended, unless output is through the same input hw)
* ???
Cons:
* alsaplayer's internal format is still 16-bit
* possible distortion if machine is heavily loaded (input overruns)
* high latency caused by aggressive internal buffering
* not configurable enough
Usage:
$ alsaplayer -ojack jack_input:
This will load the jack input plugin and create 2 new input ports:
alsaplayer_in:in_1
alsaplayer_in:in_2
Connect your output to these ports. Warning: loops are possible :-)
Download:
http://alsaplayer.org/jack_input-0.1.tar.bz2
Enjoy!
Andy @ alsaplayer.org