might be of interest to some LAD patrons:
-------- Original Message --------
Subject: [Sursound] Call for Participation: Int. Symposium on
Ambisonics and Spherical Acoustics, 2010
Date: Wed, 4 Nov 2009 12:57:25 +0100
From: Markus Noisternig <Markus.Noisternig(a)ircam.fr>
Reply-To: Surround Sound discussion group <sursound(a)music.vt.edu>
To: Surround Sound discussion group <sursound(a)music.vt.edu>
[Apologies for possible multiple copies]
-----------------------------------------------------------
2nd Int. Symposium on Ambisonics and Spherical Acoustics
May 6-7, Paris, France, 2010
ambi10 - First Call for Participation
http://ambisonics10.ircam.fr
Dear Colleagues,
We would like to announce the 2nd International Symposium on
Ambisonics and Spherical Acoustics, which will be organized by IRCAM,
together with LIMSI-CNRS and France Telecom/Orange Labs. The Symposium
will be held to provide an intensive exchange between industrial and
academic researchers working in various research areas on spherical
acoustics.
The field of spatial sound reproduction is interdisciplinary by nature
and closely related to a number of computer science and engineering
areas such as acoustics, mathematics, signal processing, and
perception. The symposium focuses on discussing the various problems
and solutions concerning the capture, analysis, and re-synthesis of
sound fields applying spherical acoustics; for example higher-order
Ambisonics (HOA), and spherical microphone arrays.
The symposium is going to be divided into oral presentations (keynotes
and submissions), poster sessions, and two demonstration sessions
(artistic and technical). This symposium will benefit from a hemi-
spherical loudspeaker array that will be installed for the duration of
the symposium, which will be held in the Espace de projection, the
variable acoustics performance hall of Ircam.
Original contributions are encouraged in, but not limited to, the
following topics:
* General considerations on spherical acoustics theory
* Ambisonic for sound scene reproduction and virtual acoustic
environments
* Spherical microphone array systems and signal processing
* Capture and analysis of radiation patterns
* Spherical acoustic holography
* Synthesis of directional and focused sound sources
* Spherical loudspeaker array systems and signal processing
* Theoretical considerations on comparative subjective and
objective studies
* Standardization, exchange, implementation and hardware issues
Submission
==========
Submissions will be judged based on extended abstracts (1000 words).
Procedures to submit papers, posters, and demo sessions are detailed
at the symposium website http://ambisonics10.ircam.fr. Final papers
must be camera-ready conforming to the format specified on the
submission website.
Several excellent papers will be selected for collective submission to
Acta Acustica united with Acustica. These papers will be expanded
versions of the presented works, and will go through the standard peer
review process.
The official language of the symposium is English.
Important dates
===============
* Extended abstract (1000 words) submission due: January 8th, 2010
* Papers, Notification of acceptance due: February 19th, 2010
* Camera-ready copy (full paper): March 12, 2010
* Registration opens: March 22, 2010
* Late Registration: April 12, 2010
* Submission of Audio Material for Testing: April 19, 2010
* Symposium Dates: May 6-7, 2010
Symposium Chairs
================
General Co-Chairs
Markus Noisternig (IRCAM - UMR CNRS)
Brian FG Katz (LIMSI - CNRS)
Rozenn Nicol (France Telecom - Orange Labs)
Technical Program Co-Chairs
Nicolas Misdariis (IRCAM - UMR CNRS)
Olivier Warusfel (IRCAM)
Administration Chair
Sylvie Benoit (IRCAM)
_______________________________________________
Sursound mailing list
Sursound(a)music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound
hi *!
thanks to contributions from a number of ffado folks) (notably stefan
richter, kernel firewire developer, the irq priorities howto in the
ffado wiki at
http://subversion.ffado.org/wiki/IrqPriorities
should be in a usable shape.
it's split in two parts: the first one shows how to tweak IRQ priorities
manually (because it's useful to know, if a bit tedious), and the second
shows how to offload the grunt work to rui's rtirq script.
however, the general hairiness of messing with kernel thread priorities
on an rt kernel demands some more eyeballs on this.
i'd welcome user reports and suggestions/corrections from people with
in-depth kernel knowledge.
no need to cross-post your contributions (unless you want to discuss
them widely), i will collate all suggestions and integrate them into the
wiki. of course, if you are willing to take the trouble to sign up on
the ffado homepage (http://ffado.org/?q=user/register), you are welcome
to work on the wiki directly.
this information currently resides on ffado.org, because irq tuning is a
hot topic for users of firewire audio devices. however, the plan is to
move the relevant information upstream into the kernel rt wiki once it'
has seen some more review.
i'm not currently on the rt users list - if anyone is, feel free to
forward this message. i'd appreciate cc:s to my private address in that
case.
best,
jörn
Here's the next instalment. First, the background.
The problem was that a Creative Audigy2 card that had worked perfectly
in Ubuntu 8.04 suddenly went silent after an upgrade to Ubuntu Studio
9.04. It still worked perfectly in Windows on the same dual boot machine.
David Morrell wrote:
> frank pirrone wrote:
>
>> Here's my /var/lib/alsa/asound.state file. You can try moving yours
>> aside by renaming it, and dropping this in to see if it makes any
>> difference. I have the Audigy2 card in this ArtistX/Ubuntu 9.10 Dell
>> Workstation, and it is fully functional.
>>
>
> Amazing! Eureka etc. Thanks very much indeed, Frank. I've put about 15
> hours into this problem and you've solved it. Now the question is, how
> did a bad asound.state file get created as a default during
> installation? Does anyone know where I should go to alert someone who
> can look at this?
I've done a bit more testing and reported it on the Ubuntu bug reporting
system as follows. The bug is at;
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/406356
To reproduce the bug then repair the damage, do the following.
Delete /var/lib/asound.state (to mimic a fresh install, when it has not
yet been created)
Run
alsactl init
The sound card is probed. Alsactl reports;
Unknown hardware: "Audigy2" "SigmaTel STAC9750,51" "AC97a:83847650"
"" ""
Hardware is initialized using a guess method
A version of asound.state is created that lacks (at least) a master
volume mute switch. There is no sound output.
Restore the previously good asound.state, run 'alsactl restore' and the
card works again.
Does this mean that something (I don't know what) needs to be improved
so it can recognise this card (Audigy 2 Value [SB0400)?
--
David Morrell
Web site: www.davidmorrell.ozeweb.net (when I get it on air again :)
<http://www.davidmorrell.ozeweb.net>
Email: dsmorrell56(a)dodo.com.au <mailto:dsmorrell56@dodo.com.au>
Ph: 0408 842 955 / 03 6343 5131
Hi,
I'm about to work on a LV2 wrapper for the FxEngine Framework and I would like to know if it exits compliant tests to validate LV2 plugin according to the port type, scope, ect ..... ? With the exeption of a few unitary tests, I didn't find anything on the web.
Thanks in advance, regards,
Sylvain
Hi,
I'm about to work on a LV2 wrapper for the FxEngine Framework and I would like to know if it exits compliant tests to validate LV2 plugin according to the port type, scope, ect ..... ? With the exeption of a few unitary tests, I didn't find anything on the web.
Thanks in advance, regards,
Sylvain
2009/11/2 <fons(a)kokkinizita.net>:
> On Mon, Nov 02, 2009 at 10:31:26PM +0100, Emanuel Rumpf wrote:
>> Some fixes for alsaplayer 0.99.80
>>
>> - compiles with gcc 4.4 now
>> - works with new JACK version (1.9.3) (jackd audio server)
>
> If you did add a call to jack_get_sample_rate(), that
> was not necessary (but it won't harm).
>
I did. There was a strange message about
the sample rate being zero.
Too low quality for my taste :-))
> When you enable
> the sample_rate callback, jack should call it immediately
> with the current sample rate. Jack1 does so, Jack2 aka
> jackdmp aka 1.9.* doesn't. So the bug is in 1.9.*, not
> in alsaplayer. It has been corrected in SVN.
>
Thanks for mentioning.
--
E.R.
Some fixes for alsaplayer 0.99.80
- compiles with gcc 4.4 now
- works with new JACK version (1.9.3) (jackd audio server)
Replace the old files with those provided in this package.
Recompile.
--
E.R.
Hi guys,
I'm looking to delve into the world of plugins (for both synth and fx),
and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a
little confusing.
It appears that LV2 is "current," that DSSI is deprecated, and that LADSPA
would be deprecated if it weren't so widely adopted. However, LV2 is slow
in being adopted. Is this developer resistance... or is it just too new?
Also, I can't find any applications that will host all 3, nor even
LV2+DSSI. Is there a technical reason for this?
Thanks in advance,
Gabriel
hi everyone!
i'm playing with my shiny new BCF2K, and i'm going to use it some
distance from my machine, so i'm going to try a midi link instead of USB.
what is the maximum length of midi chain that you have used without
problems? i read somewhere that no more than 15 meters are recommended,
which strikes me as pretty short even if it's unbalanced.
my idea is to abuse a cat5 cable as a triple midi loom - do you think
that could work? pinout would be as follows:
1 midi 1 signal
2 midi 1 ground
3 midi 2 signal
4 midi 2 ground
5 midi 3 signal
6 midi 6 ground
7 common +5V
8 common +5V
best,
jörn
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
> I don't see much point of storing a local copy of a ssh tunneled config
> file. If you are tunnelling the config file should be accessed from the
> remote machine. It's different if you are using multiple qjackctls on
> the same desktop and connecting to local jackd instance/s as well as
> netjack'd instances on remote machines. That seems like a heavy deal and
> as Nedko has mentioned previously it can actually be managed by the LADI
> tools now although that requires running dbus too which is not to
> everyones liking.
Yesterday, I've booted my wife`s windows machine from an Ubuntu LiveCD
and made some remote dbus tests. There are two options to initiate this
through ssh.
The first one is to start socat[1] at both sides and use tcp for
connecting them:
dbus app <-> unix socket <-> socat <-> tcp over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
The other one is to use gabriel [2] at client side. Gabriel uses libssh
[3] to setup socat remotely and tunnels the dbus traffic over ssh
tunnel:
dbus app <-> unix socket <-> gabriel <-> ssh over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
Gabriel`s approach is of course better in long term, because dbus
traffic is encrypted and because it sets remote part automatically. Bad
news about gabriel is that last commit is from February 2007, it needs a
patch to work with latest libssh (0.3.4) and it allows only one client
to use the local unix socket.
Both approaches have restriction because of the EXTENRAL dbus
authentication mechanism. That mechanism sends unix user id and it is
matched remotely. So in order remote dbus to work, uids should be
same. Of course this is lame and I already have plan for this: the
client side (gabriel/ladish), can get the remote uid through ssh and
change the uid "token".
Plan for the remote capable ladish is to take the gabriel`s
approach. Requirements for the remote (aux) hosts will be - ssh server,
dbus, jackdbus and socat. Requirements for the local (central) host will
be ssh client, libssh, dbus, jackdbus, ladish. ladish will provide dbus
service that will act as manager for remote dbus connections. Such
service could be reused for other remote dbus purposes and as such could
be a separate project (or could be made as part of gabriel).
Multihost ladish is planned for the 2.0 release and wont happen anytime
soon unless someone with high motivation steps to work on this.
I'd like to ask users of multiple-jack-servers-on-same-host (Fons?) to
explain what it is used for and how it works. As I personally dont use
such setup I can't make ladish suitable for such setups without
feedback. Same applies for remote jack management and netjack but I've
gathered some knowledge because of the obvious netjack popularity.
[1] http://www.dest-unreach.org/socat/
[2] http://gabriel.sourceforge.net/
[3] http://www.libssh.org/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>