I'm just doing some research as I noticed an infrared audio
transmitter/receiver the other day in the comet store.
What are the options for doing wireless audio output (e.g. hooking up a laptop
with a stereo a couple of meters away), if any, and if then under linux?
In theory I could think of:
- bluetooth (apparently quite slow, so maybe not good for ~cd quality)
- wlan: using an existing wlan card and somehow receiving audio data, then
transforming to analog - are there devices that do this, how would this work
with wlan at the same time?
- infrared: no idea, guess the builtin infrared on laptops is to weak to get
any further than half a meter
Any ideas or advice appreciated
mimo
Hi,
I just hope that this is not a stupid question, anyway: Does anyone know
whether there's a patch to make OpenAL work with Jack? Anyone working on
this?
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
nicholas asked me to forward this message for him, i'm certain you will
appreciate it.
-------- Original Message --------
Subject: Job opportunity, Glasgow, Scotland.
Date: Tue, 19 Jul 2005 11:21:17 +0100
From: Nicholas Bailey <n.j.bailey(a)elec.gla.ac.uk>
To: linux-audio-dev-owner(a)music.columbia.edu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I hope readers of LAD might find the following useful, and I wonder if
you'd mind posting it for me. Linux audio developers have been
interested in these posts in the past.
Please note that my understanding of employment legislation is that we
are unable to employ personnel from outwith the European Union unless
it can be demonstrated that the required skill set does not exist
within the EU (which in this case it certainly does)
Here's the post...
Job opportunity:
RESOURCE DEVELOPMENT OFFICER (MUSIC), UNIVERSITY OF GLASGOW
Closing date: 5th August 2005
Based in the Department of Music and shared with the Humanities Advanced
Technology and Information Institute, this is a key post aimed at
developing and
supporting the use of information and communication technology in music
teaching
and research. Job responsibilities come under three main headings:
research
support; lab management, administration and development; and teaching
support.
The postholder will provide technical support specific to music.
For further details, please see:
http://www.gla.ac.uk/services/humanresources/recruit/5aug_11387.htm
JOB PURPOSE
The aim of this post is to develop and support the use of information
and
communication technology in music teaching and research. The postholder
will
provide technical support specific to the discipline of music.
KEY TASKS
Job responsibilities come under three main headings: (a) research
support, (b)
laboratory management, administration and development, and (c) teaching
support.
a. Research Support
a) Advise and assist staff and postgraduates in the selection and
use of appropriate new technology resources to enhance research.
b) Collaborate with staff and postgraduates on the technical aspects
of research funding applications.
b. Laboratory Management, Administration and Development
a) Liaise with the HATII team in providing technology resources,
and with the Technician in the Music Department, on studio and
audio infrastructure.
b) Maintain and supervise the computing facilities in the
Department of Music, delegating to the HATII team, as appropriate.
c) Liaise with other RDOs in the Arts Faculty, Department of
Electronics and Electrical Engineering and Department of
Computing Science, to identify and develop common resources.
c. Teaching Support
a) Enhance the deployment of teaching materials.
b) Identify new technologies for use in teaching.
c) Provide technical advice to students, including demonstrations
and classes, as appropriate.
d) Contribute to the Faculty's undergraduate and postgraduate
teaching programme managed by HATII.
OBJECTIVES
To ensure that the provision of ICT in the Department of Music is
appropriate to
teaching, learning and research needs of staff and students.
These key tasks are not intended to be exhaustive, but simply highlight
a number
of major tasks which the post holder may be reasonably expected to
undertake.
Every job description will be subject to review on an annual basis, or:
· as a result of a change in strategic management
· as a result of team/ operational requirements
· as a result of agreed performance and development review
including any review of objectives
· within six months of appointment.
THE DEPARTMENT OF MUSIC
The Department has extensive high-quality audio and computing
facilities. These
comprise: professionally equipped recording studios with tielines to
concert
halls and soundbooth, Mac-based Electroacoustic Studios with Digidesign
audio
hardware and soundbooth; two Mac-based audio workstation labs; an
undergraduate
PC cluster; a PC cluster for postgraduates and researchers; and a
number of web
and ftp servers running Linux. Applications include ProTools, Logic,
Cubase,
Finale and Sibelius, Max/MSP, PD/GEM, Csound and more.
The Department is a thriving environment for research and teaching
across a wide
range of areas including electroacoustic and acoustic composition, music
technology, historical and cultural musicology, and Scottish music.
For further details, please see:
http://www.gla.ac.uk/services/humanresources/recruit/5aug_11387.htm
Department of Music:
http://www.gla.ac.uk/music
HATII:
http://www.hatii.arts.gla.ac.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFC3NQdFo+kGmUnzkQRAlkLAJ4vurB38motOmUAmC3Fn+tvttxsLgCcCRbS
de8noFAP7q3y80XrZEchoAo=
=8WiE
-----END PGP SIGNATURE-----
Hi!
Anybody interested in working on a synthesizer slightly more
clock-expensive than my previous mx44?
This time around I would like to assume that the user(s) own(s) one or
two of the Behringer "Dhrehbanks"
Not to say that the thing should be impossible to use otherwise, only
that there could be (or might be) a preffered (fast) way ...
Plugin Implementors welcome before this thing goes astray!
Uhmm .. and yes. I Have a new (much more clean) efficient oscillator
working :) How to get it? There is no website. At the moment, just ask!
...
...
...
...
...
...
...
The project name is: "C2"!
--
mvh // Jens M Andreasen
Greetings:
I've added a Musings section, corrected some URLs, and added one or
two new items. You know the drill:
http://linux-sound.org (USA)
http://linuxsound.jp (Japan)
http://linuxsound.atnet.at (Europe)
Alas, the European site is giving me fits again and is not yet
updated. The Japanese site will auto-update this evening.
Btw, my thanks to the many people who sent kindly messages regarding
these pages. I'm glad that the sites are a useful resource, despite
their ancient format and lack of amenities, and since no-one else has
arrived with a replacement I'll keep aperiodically updating them. I hope
you all continue to find them useful and enjoyable.
Best regards,
Dave Phillips
by Kjetil Svalastog Matheussen <k.s.matheussenï¼ notam02.no>
Martin Habets:
>
> Plus not all machines have a physical RTC chip.
> If you want periodic interrupt emulation on those you need a patch [1],
> but that just generates a software interrupt. That would suffer from a
> change in HZ value AFAIK.
>
When having a server, you don't have to use /dev/rtc if its not there.
For me, having a timer-daemon, and a shared library communicating
with it, seems like the obvious (and very simple) solution for the
timer problem.
A daemon is easy to set up, and should provide the best possible timing
for the given kernel and hardware. So I really wonder, is there something
obvious I don't see? Why isn't there such a daemon? In case
its just that noone haven't bothered implementing it, I will when
I find a free day.
by Kjetil Svalastog Matheussen <k.s.matheussenï¼ notam02.no>
Lee Revell <rlrevell(a)joe-job.com>
> On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog Matheussen wrote:
>> E-radium has been tested with both the 2.4 kernel and the 2.6 kernel
>> and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a
>> 100hz resolution timer will proably not work very nice though.)
>
> Can you please explain why 100HZ would be a problem for your app? Right
> now the kernel people are trying to change the default HZ for 2.6 to
> 250. I have told them that this is insane but they seem inclined to do
> it anyway.
>
The program use poll to sleep. If the resolution of the kernel is 100Hz,
there
would sometimes be a too long delay of up to 10ms (and probably beyond)
before the program is woken up, and before a midi message is sent,
which can cause music to stutter.
Simple as that. :-)
> If you can provide more examples of apps that would be broken by this
> change maybe we can convince them not to change it.
>
Hmm, mplayer I guess...
Don't know how muse, rosegarden, seq24 etc. handles timing...
But all midi-sequencers that doesn't use /dev/rtc could suffer. (?)
Paul Davis:
>On Fri, 2005-07-15 at 17:18 -0400, Lee Revell wrote:
>> On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
>> > I wonder why /dev/rtc isn't used more than it is now.
>>
>> Because sleep/wakeup, poll, etc are much nicer interfaces than /dev/rtc.
>
>
>any sane programmer will use slee/wakeup, poll etc. with /dev/rtc :)
>
>
>the hairy part is just setting up the interrupt freq on the RTC.
>
>
>the big problem with the RTC is the restriction to power-of-2 HZ
>settings. not very useful for a lot of things.
This is easely solved by setting up a server-system. The clients
can request an individually frequency to be woken up by, and
the server will set the interrupt freq high enough to satisfy
all current connected clients.
--
Lee Revell:
>On Fri, 2005-07-15 at 23:10 +0200, Kjetil Svalastog Matheussen wrote:
>> I wonder why /dev/rtc isn't used more than it is now.
>
> Because sleep/wakeup, poll, etc are much nicer interfaces than /dev/rtc.
If you had read the part of my mail that you cut away
when quoting me, you would have seen that I was proposing
a server/client system.
Once more, why isn't such a system in use? Hasn't anyone
bothered to make it?
--
>Good to see someone other than Grame' guys try to "push" MidiShare.... ((:
well, i'm only pushing because i'm using it, and i can't use ALSA. :)
>But Jay, MidiShare cannot help in terms of synchronizing MIDI with
>audio at the sample level..... MidiShare events are 1 millisecond
>time stamped.
yes, i understand that now .. i initially mis-understood pd's idea on
this, since under OSX, MidiShare is 'sync'ed' using an Audio timer..
but, it would in fact be interesting if MidiShare had a new 'Audio
Event' type added to it, from the standpoint of timestamp'ed events
.. thats feasible, i think .. of course, this would only be relevant
if one was already using MidiShare, but it would be a nice addition
to what I consider a very clean and productive API .. /me goes off to
prepare an "AudioShare" patch, heh heh ..
>But well the Linux official API is now ALSA, and the OSX official
>API is CoreMidi..... and we have to live with that.
what makes an API 'official' under Linux, anyway? in my opinion, the
old maxim, "use what works" applies .. and ALSA has proven to be a
very difficult and annoying thing to get set up and working (witness
jwz' recent terror) .. while MidiShare has (for the most part) been
smooth and dreamy.
but .. ymmv, yo.
--
;
Jay Vaughan