On Friday 06 January 2012, you wrote:
> btw: is there a way to list available clients/ports from the api.
> I know that aconnect -i / -o does this, but is there a c/c++ function?
>
> Dave
The functions are: snd_seq_query_next_client() and snd_seq_query_next_port();
you need to loop calling these functions while they return a correct answer.
For instance, this is the relevant code in "aconnect.c" :
static void do_search_port(snd_seq_t *seq, int perm, action_func_t do_action)
{
snd_seq_client_info_t *cinfo;
snd_seq_port_info_t *pinfo;
int count;
snd_seq_client_info_alloca(&cinfo);
snd_seq_port_info_alloca(&pinfo);
snd_seq_client_info_set_client(cinfo, -1);
while (snd_seq_query_next_client(seq, cinfo) >= 0) {
/* reset query info */
snd_seq_port_info_set_client(pinfo,
snd_seq_client_info_get_client(cinfo));
snd_seq_port_info_set_port(pinfo, -1);
count = 0;
while (snd_seq_query_next_port(seq, pinfo) >= 0) {
if (check_permission(pinfo, perm)) {
do_action(seq, cinfo, pinfo, count);
count++;
}
}
}
}
See:
http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=seq/aconnect/aconnec…
I guess you already know the reference documentation site:
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
Just for comparison, a similar enumeration using Drumstick looks like this:
QListIterator<PortInfo> it(m_Client->getAvailableOutputs());
while(it.hasNext()) {
PortInfo p = it.next();
cout << p.getClientName() << ":" << p.getPort();
}
See Drumstick's example "drumgrid":
http://drumstick.sourceforge.net/docs/drumgrid.cpp-example.html
Regards,
Pedro
Hi!
I was recently helping a small Dutch radio station run by volunteers to
set up their new studio.
It's a modular system with a 16 I/O firewire card:
http://www.d-r.nl/AXUM/AXUM.htm
We managed to support it in FFADO. The playback software runs on a
virtualised Windows machine that's talking to jackd via netjack (no idea
which one, the one with multicast and netmanager), so we can address
four individual stereo pairs.
This whole netjack thing isn't very stable, so the playback software
should be replaced by some native Linux client. Here's a screenshot of
the current Windows solution:
http://adi.loris.tv/radio.png
It is basically a set of four remotely controlled winamps (with ASIO
output plugin to talk to jackd) and a directory browser per player.
So "Jingles", "Muziek" and "Bladeren" are just shortcuts to directories
with media files, the drop-down menu on the left contains a list of even
more directories.
The filter is used for pattern matching.
Questions: Are you aware of any Linux solution that comes close to this?
If not, any recommendations if one would want to create such a four-deck
player? Leveraging VLC, mplayer, gstreamer?
This is surely going to be open source, so whoever is interested, feel
free to participate.
Cheers
Hi
With some threads running on different CPU,
accessing a shared pointer (in RAM) atomically (with gcc atomic methods)
my current understanding is:
- each cpu has its own cache line
- which is updated on every atomic read/write operation
1. is that applicable ?
2. is there a faster or more convenient method, such as
storing the pointer in fast register shared among different cpu ?
--
E.R.
Hello all,
I want to write an application that monitors in realtime changes in an Alsa dummy mixer control (though not sure which language yet). I think its best to try to track those changes through the filesystem. For non-dummy mixer controls I can access them through: /proc/asound/cardx/codecxxx/xxxx+regs. However, it seems that this does not work for this dummy mixer control. Can someone point me a bit in a direction where I should for a solution (language/library)?
Whichever language I use I still have quite a bit to learn. However, I do would like to find out whether it is even possible in a certain language before I invest a lot of effort in it (without result). I've tried Python, but getting it working in realtime is likely going to be very hard (if possible at all).
Kind regards, Maarten
ps. I've defined the dummy mixer control in /var/lib/alsa/asound.state
as shown below:
state.DAC {
control.12345 {
iface MIXER
name 'Fake Playback Volume'
value 100
comment {
access 'read write user'
type INTEGER
count 1
range '0 - 100'
}
}
}
Hello all,
Version 1.3.0 of libzita-resampler is now available on
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>.
This release fixes a bug in the VResampler class that showed up on
64-bit systems only. This also made zita-a2j and zita-j2a fail.
Many thanks to Jannis Achstetter for reporting the problem and
testing the fix.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi
As of 2011-01-16 I have skipped the development of jcgui, and still I
wouldn't maintain/develop it any longer.
But it get downloaded and used by some users and I receive requests and
bug-reports for it.
So I decide to fix the most related bugs and upload a new version, to
get rid of that.
* fix file not load when white space in path
* fix resampling (use zita-resampler now)
* fix build with gcc 4.7
* various small fixes
Still, I wouldn't recommend to use jcgui, please use IR_LV2 instead,
but, if you really would use jcgui, please update it.
http://sourceforge.net/projects/jcgui/files/jcgui/jcgui-0.8.tar.bz2/download
regards
hermann
I have explicitly asked about block length restrictions on l-a-d several
times, but of course that doesn't work. Setting up an idea to be flamed
works wonderfully though (mining that most plentiful resource of
assholes on mailing lists). The convoLV2 announcement served this
purpose nicely. In summary:
Convolution is the only reason anyone has come up with for a power of 2
block length restriction. Apparently that is wrong.
Only one argument has ever been posed for a fixed restriction, and that
was wrong too (outside LADSPA anyway, where we are not forced to use
control ports).
So, unless anyone has new compelling examples, we have some new
implementation recommendations for the block length restrictions defined
in LV2 1.2.0:
* Fixed and power of two can be difficult or impossible to implement,
and are not useful, so hosts should not bother trying to implement
either (except where it is trivial), and plugins should not expect
them to.
* The remaining restrictions, minimum and maximum, are needed to do
some things without latency, and are useful for performance reasons,
so hosts should try to implement this if possible. Plugins should
only require these if absolutely necessary, since some hosts may not
be able to implement minimum in particular. convoLV2 is an example
of a plugin with minimum and maximum restrictions.
As before, all hosts should implement passing the maximum length to the
plugin, which is often required and easy to do.
There is one issue related to minimum, buffer alignment, which is useful
for SIMD (e.g. using SSE). This has not yet been addressed in the
specifications.
-dr
>
>
> Message: 13
> Date: Sun, 21 Oct 2012 19:57:31 +0000
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> To: David Robillard <d(a)drobilla.net>
> Cc: linux-audio-dev(a)lists.linuxaudio.org
> Subject: Re: [LAD] ANN: convoLV2 0.2
> Message-ID: <20121021195731.GC6724(a)linuxaudio.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Oct 21, 2012 at 03:49:30PM -0400, David Robillard wrote:
>
>> The appropriate thing to use on OSX is mach semaphores. This code is
>> terrible.
>
> I'd be most happy to replace the current code with
> some using Mach semas. Patches will be much appreciated.
>
>>> (A "blocking in a real-time thread is acceptable" argument)
>
> Yes, in some cases that is acceptable.
>
>>> (Hilarious appeal to irrelevant authority)
>
> Much more relevant than you are.
>
> Ciao,
>
> --
> FA
>
You can use semas on OSX, you'll need to use sem_open API instead of sem_init. Using here: sem_open, sem_post/sem_wait, sem_unlink/sem_close with success (In Faust Work Stealing Scheduler code). And semas are actually a slight wrapper over Mach semas. You can check that in XNU source (here for instance http://opensource.apple.com/release/mac-os-x-1068/)
Stéphane
