Re: [LAD] [ANN] lash-0.6.0 release candidate 2
Ok, things have settled down, and i've tweaked a little here and there. Seems to be running nicely now, and fairly stable. A screenshot. of a generic setup. http://shup.com/Shup/81262/patchage3.png Alex. lpatchage jackdbus rosegarden linuxsampler ardour2 jconv On Tue, Nov 11, 2008 at 10:35 PM, alex stone [EMAIL PROTECTED] wrote: Nedko, This is what i get when i try, in the messages window of lpatchage, when i try to connect linuxsampler audio out: [JACKDBUS] ConnectPortsByName() failed. jackdbus log is attached. (I've renamed a copy for your perusal) Alex. On Tue, Nov 11, 2008 at 8:55 PM, Nedko Arnaudov [EMAIL PROTECTED]wrote: alex stone [EMAIL PROTECTED] writes: But i'm still at a loss as to why i can't connect LS audio out, to Ardour audio in, in lpatchage, visibly. It works in Qjackctl, but stubbornly refuses to connect in lpatchage, even though the actual connections are made in Ardour, and most importantly, work. Do you get any errors in jackdbus log file when you are trying to connect using lpatchage? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA doumentation
Fons Adriaensen wrote:
I now want to write some hopefully not too convolved
C or C++ code to read and write these parameters.
Is there, after X years of ALSA, any documentation that
explains the basic concepts and tells me how to do this ?
No.
how I can e.g. set the sample clock source on a RME MADI card
in less than ten lines of C code
system(amixer cset name='Sample Clock Source' 3);
or like this:
#include stdio.h
#include stdlib.h
#include alsa/asoundlib.h
static void check(int err, const char *f)
{
if (err 0) {
fprintf(stderr, %s failed: %s\n, f, snd_strerror(err));
exit(EXIT_FAILURE);
}
}
#define CHECK(f) check(f, #f)
int main()
{
snd_ctl_t *ctl;
snd_ctl_elem_value_t *value;
CHECK(snd_ctl_open(ctl, default, 0));
snd_ctl_elem_value_alloca(value);
snd_ctl_elem_value_set_interface(value, SND_CTL_ELEM_IFACE_MIXER);
snd_ctl_elem_value_set_name(value, Sample Clock Source);
snd_ctl_elem_value_set_enumerated(value, 0, 3); /* 3: 48 kHz */
CHECK(snd_ctl_elem_write(ctl, value));
snd_ctl_close(ctl);
return 0;
}
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] MIDI and audio patchbays
Julien Claassen [EMAIL PROTECTED] writes: Hello folks! One question, I hope it's not too dumb. :-( If you have your average patchbay, how does it know, when new MIDI/audio ports/clients come to live or die? And how does it know, that some connection was killed by some other application. Does it simply query it all the time? I wouldn't think so... But perhaps I'm wrong... Both full refersh and notifications are possible. Notification mechanism is still lacking port renamed functionality. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp48QEZuRppO.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA doumentation
Paul Davis wrote: On Fri, 2008-11-14 at 01:08 +0100, Fons Adriaensen wrote: Now if someone can point me to some existing docs that explain how I can e.g. set the sample clock source on a RME MADI card in less than ten lines of C code (knowing the parameter names, ranges, etc - no need to find them out dynamically, I can read them asound.state) then I'll eat my hat. It shouldn't be difficult. On some competing systems all it takes is one ioctl(). i don't want to defend the lamentable state of the ALSA docs, but this last shot was a bit cheap Fons. the idea behind the ALSA control API was that equivalent controls on different cards would be controlled in the same way. sure, OSS provides ioctl (fd, OSS_THIS_ONE_DOES_MADI_CLOCK_SOURCE, int) but move that code to any other device and it breaks entirely. Old OSS/Free may have this kind of ioctl calls. However OSS 4.x has similar control API than ALSA. MADI clock source is one of the big red button controls in OSS. They are supposed to be touched only when the whole studio wiring changes. This is to be done in the control panel by the system administrator. There is no point in letting any application to change such settings so it has intentionally been made pretty much impossible. Best regards, Hannu ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] ALSA doumentation
On Fri, Nov 14, 2008 at 03:47:17PM +0200, Hannu Savolainen wrote: There is no point in letting any application to change such settings so it has intentionally been made pretty much impossible. If you think this applies to my situation you are wrong on all accounts. 1. It not made pretty much impossible in ALSA, all it takes (on the command line) is an 'amixer sset'. 2. I am the system administrator. I may want to use an application to do part of my work. 3. The studio wiring can change at any time. There are four PCs, four ADI648s and MADI connections between them are made via an RME MADI switch. This is controlled by software as well. MADI wiring is in function of the current project or session. 4. If ALSA would allow me to set Sample Clock Source to AutoSync, Preferred Sync Reference to MADI and System Clock Mode to Slave AND ENSURE THEY STAY SET LIKE THAT then I wouldn't have to touch them. But it will switch to Internal 44.1 kHz and Master whenever there is no MADI signal on the input and it will *not* go back to the original settings when a signal is present again. Since the MADI links are switched, this can happen and it should not leave the system in an inconsistent state. Hence I do have to monitor these settings permanently and take action when they are wrong. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] MIDI and audio patchbays
Hello folks! One question, I hope it's not too dumb. :-( If you have your average patchbay, how does it know, when new MIDI/audio ports/clients come to live or die? And how does it know, that some connection was killed by some other application. Does it simply query it all the time? I wouldn't think so... But perhaps I'm wrong... For ALSA MIDI sequencer, the patchbay program can create an input sequencer port, and subscribe it to System:announce (0:1) to receive ALSA notifications about these events: client start/exit, port start/exit, port subscribed/unsubscribed. You can try this with aseqdump, like the following sample session: $ aseqdump -p 0:1 Waiting for data. Press Ctrl+C to end. Source Event Ch Data 0:1 Port subscribed0:1 - 128:0 0:1 Client start client 129 0:1 Client start client 130 0:1 Port start 129:0 0:1 Port start 130:0 0:1 Client start client 131 0:1 Port start 131:0 0:1 Port subscribed129:0 - 131:0 ... 0:1 Port unsubscribed 129:0 - 131:0 0:1 Port exit 129:0 0:1 Client exitclient 129 0:1 Port exit 130:0 0:1 Client exitclient 130 0:1 Port exit 131:0 0:1 Client exitclient 131 ... Regards, Pedro ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] Montréal Sound Map
La version française suit la version anglaise Call for participation in documenting Montreal's Soundscape http://cessa.music.concordia.ca/soundmap The Montreal Sound Map is ready for submissions. We are accepting all (unprocessed) audio recordings (past and present) of Montreal's sound environments. Our goal is to gather and display as many recordings as possible from all over the island. As we gather submissions, we will be placing them into a browseable tagging system based on criteria including: Sound Source (specific, characteristics) Location (borough, neighbourhood, municipality) Date (time of day, month, day of week, year, season) Environment Type (park, metro, indoors, outdoors, etc...) Equipment (recording device, microphone, etc...) Files can be uploaded through the form on the website. For more information, please visit the about page. ~ Participez à la complétion de la carte sonographique de Montréal. http://cessa.music.concordia.ca/soundmap/fr Il vous est maintenant possible d'envoyer des fichiers audio (enregistrements récents ou non, non-édités) pour participer à la complétion de la carte sonographique de Montréal. L'objectif est de rassembler le plus grand nombre d'enregistrements provenant de partout sur l'Ile. Les documents reçus sont incorporés dans une base de données accessible à tous. Les critères de recherches sont : Source sonores (caractéristiques) Lieu de l'enregistrement (banlieue, quartier, municipalité) Date de l'enregistrement (heure du jour, mois, jour de la semaine, année, saison) Caractéristiques du lieu d'enregistrement (parc, metro, intérieur, extérieur, etc.) Équipement utilisé (outil pour l'enregistrement, micros, etc.) Les fichiers peuvent être envoyés en remplissant le formulaire en ligne. Pour plus de renseignements, cliquer sur le lien à propos. Best, Max -- CESSA www.cessa.ca The Concordia Electroacoustic Studies Student Association (CESSA) was established Fall of 2007. Our focus is primarily in spreading awareness of electroacoustic matters throughout Concordia and Montréal via projects and events, expressing particular interests in health, environmental, and social issues pertaining to sound. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
