> How does that effect me for instance as a Gentoo user? Please consider
> whether LAU would still be a place of value to those of us that aren't
> Debian/Ubuntu based.
>
> I don't mind the occasional distro specific conversation. I wouldn't
> want to see that ever become more than 1% of what's discussed on a
> list like this.
>
> - Mark
Ideally, we would also want to have Gentoo involved in linuxaudio.org.
However please note that I cannot (nor do I want to) coerce anyone to join
linuxaudio.org. Yet, here we are with a potential opportunity to have Debian
join us and my thoughts are we should not pass this up. I can only hope that
Gentoo will join us as well--but that is not my call...
Best wishes,
Ico
Michael, Paul has answered you on jack-devel. See below.
Note: I'm cross-posting this mail to linux-audio-dev, since Michael has recently
subscribed to it. At least, we should be able to discuss together in there.
Paul Davis wrote :
> I have no idea how any of you have kept this conversation going when one
> of the main protagonists is not even subscribed to one of the two
> mailing lists, and i suspect that one of the others isn't subscribed to
> the other. perhaps the FFmpeg-devel list doesn't require membership.
>
> anyway, i've finally had enough of reading Michael's stuff about
> buffers, timing and so forth and felt obligated to comment.
>
> michael - i would politely request that you stop shooting off at the
> mouth about stuff that the JACK community has been dealing with for more
> than 9 years.
>
> you do not need to write your own ring buffer code - JACK's is LGPL'ed
> and you are free (and probably even recommended) to copy it.
> furthermore, you would be very foolish to imagine (especially based on
> your incredibly naive comments about uint8_t) that you understand the
> subtleties of these buffers. the JACK community (and a couple of other
> exclusively audio-focused development groups) have been working with
> this buffer design for many, many years, and we are absolutely confident
> that our buffers are (a) SMP/multi-core safe (b) as efficient as they
> can be without using assembler. you should also be aware that there are
> very good arguments for the current structure of the ringbuffer code,
> which explicitly does NOT use any memory barriers. if you don't
> understand why it works without them, then you should probably refrain
> from commenting on the design of these buffers at all.
>
>
¿Podrian ustedes instalarme su ssistema de audio a travez de internet?
He tratado en muchas ocasiones de comunicarme con Ubuntu es, Pero
ellos no reconocen este e-mail ni mi password.
Les agradrzco.
--
Agustin Ruiz Gamez
Hi,
I am trying to do gain control while RECORDING for my Audio Mic device.
My application opens /dev/mixer device and calls ioctl(fdmixer,
MIXER_WRITE(SOUND_MIXER_MIC), ...)
But, the call fails. It traces to sound/core/oss/mixer_oss.c file and
snd_mixer_oss_put_volume1() function.
It never falls in "if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME)"
as condition "if (slot->present & SNDRV_MIXER_OSS_PRESENT_PVOLUME) "
comes as false.
I think there is a bug in kernel and I think it should be like as below,
--- sound/core/oss/mixer_oss.c 2008-12-03 13:24:02.000000000 +0530
+++ sound/core/oss/mixer_oss.c 2009-03-09 16:22:06.548766896 +0530
@@ -688,7 +688,7 @@ static int snd_mixer_oss_put_volume1(str
if (slot->present & SNDRV_MIXER_OSS_PRESENT_PVOLUME) {
snd_mixer_oss_put_volume1_vol(fmixer, pslot,
slot->numid[SNDRV_MIXER_OSS_ITEM_PVOLUME], left, right);
- if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME)
+ } else if (slot->present & SNDRV_MIXER_OSS_PRESENT_CVOLUME) {
snd_mixer_oss_put_volume1_vol(fmixer, pslot,
slot->numid[SNDRV_MIXER_OSS_ITEM_CVOLUME], left, right);
} else if (slot->present & SNDRV_MIXER_OSS_PRESENT_GVOLUME) {
snd_mixer_oss_put_volume1_vol(fmixer, pslot,
slot->numid[SNDRV_MIXER_OSS_ITEM_GVOLUME], left, right);
Thanks,
Viral
--
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby
notified that any dissemination, distribution, copying, or other use of
this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
replying to this message and please delete it from your computer. Any
views expressed in this message are those of the individual sender
unless otherwise stated.Company has taken enough precautions to prevent
the spread of viruses. However the company accepts no liability for any
damage caused by any virus transmitted by this email.
__________________________________________________________________________
Just a quick note here for those who may want to 'RT' their Debian Lenny,
and the sheer enjoyment that will no doubt bring.
Using the Kernel for Dummies debian build system (thanks fellas), Alsa
1.0.19, no OSS, vanilla 2.6.26, and Ingo's patches, all went reasonably
well. (32bit)
*****PLEASE NOTE, no women, children, animals, hungarian polka enthusiasts,
or those poor wretched souls using Vista, were harmed during this
build....*****
Booted up ok, but got a kernel failure whilst cranking up my multi app
script.
Narrowed it down to Linuxsampler.
When i removed LS, and Libgig, then reinstalled, the failure went away.
All other apps played ok, with no probs.
I can only guess that my compile options needed renewing, from generic to
RT, but no real hardship, and it didn't take long.
I'm passing this on, in case anyone else builds an debian RT kernel, and
gets a kernel failure notice, once the OS is up and running, and
linuxsampler is started.
Alex.
p.s. Have to say here, that debian 5 is excellent. Even with my clumsy
machinations with the RT build, it just keeps going, and doesn't do silly
stuff when assailed with multiple 'user errors.'
Built like a tank.
:)
--
Parchment Studios (It started as a joke...)
Estoy muy agradado por su preocupacion por mi problema de audio, El
problema mio es que sus implementaciones son en idioma ingles y yo
vivo en Venezuela donde hablamos español y no puedo traducior
completamente los terminos alli explicados. Les agradeceria si ustedes
tienen alguna version en español, me lo hicieran llegar.
--
Agustin Ruiz Gamez
hiho,
my name is michael wolkstein and i wrote the first time to this list.
sorry about my english. but i am no english native-speaker.
after booting kernel 2.6.29 rc6 i get a problem with my rme multiface 1 connected true pcmcia cardbusinterface.
i get this message after insert my card.
RME Hammerfall DSP 0000:16:00.0: enabling device (0000 -> 0002)
RME Hammerfall DSP 0000:16:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Hammerfall-DSP: no Digiface or Multiface connected!
RME Hammerfall DSP 0000:16:00.0: PCI INT A disabled
RME Hammerfall DSP: probe of 0000:16:00.0 failed with error -5
i have compile the kernel included alsa module.
also i have installed the newest alsa-firmware 1.0.19 and newest alsa-tools 1.0.19.
my old kernel 2.6.24 load both firmwares correct.
the old one 1.0.16 (debian unstable)
and the new 1.0.19 download from the alsa-project page
the new kernel produce errors. kernel module snd_hdsp is already loaded with the new kernel.
any ideas.
greetings wolke
lwn.net has a very interesting interview with thomas gleixner and ingo
molnar about the future of the realtime preeemption tree.
this is a free link to content that is normally subscribers only:
http://lwn.net/SubscriberLink/319544/7cdf603c88f8dbd0/
i hope it's ok to post such a link in a public place.
the whole lwn issue will become freely available in a week or so. lwn is
a great resource and interesting reading, and if you've got a few
dollars to spare, consider subscribing to keep them going.
best,
jörn
---------- Forwarded message ----------
From: drucpa dracous <olvealien(a)yahoo.fr>
Date: Wed, Feb 25, 2009 at 5:32 AM
Subject: [nfo] Liwoli 2009 - Call for projects - Art University Linz
To: acousmail(a)yahoogroupes.fr, scrime-info(a)labri.fr, cec-conference(a)concordia.ca
purrr sayz the kitty
wooof sayz the puppy
sorry sayz the cross-poster
--
Liwoli 2009 hacklab for art and open source
23 - 26 April 2009
Art University Linz
http://linz.linuxwochen.at
--
Liwoli 2009 is a three day long Hacklab and an open invitation to
everyone who would like to participate in an active process of learning,
producing and sharing ideas around the areas of Free/Libre Open Source
Software (FLOSS) and DIY practices in digital art and culture.
FLOSS developers, software artists such as the collective GOTO10,
activists from HAIP (Hack Act Interact Progress) and many others form
the basis for the event and will share their knowledge in the form of workshops,
presentations, installations and performances.
--
Open Call
For the event we are calling for contributions (presentations, workshops
and performances) around the FLOSS themes. This invitation is not only
for those who are interested in “Do It Yourself” and how it interrelates
with the current creative production practices, the invitation is also
directed to those who are interested in the cultural importance of
FLOSS.
Submissions Please send submissions before the 25.03.2009 to
call09-liwoli(at)servus(dot)at, with the following information :
# Title
# Format: lecture, workshop, installation, performance, presentation...
# Description of content:
# Links to relevant material (mandatory):
# Required things: projector, sounds system, running water, compressed
# air, cheeseburgers
--
Organizers & contributers: servus.at, GOTO10, Radio Fro/Haip, Time's Up,
lugl.at.
Host and Support by: Kunstuniversität Linz Department for Time
Based Media and the ZID der Kunstuniversität Linz
Funds: servus.at funded by BM:UK, Stadt Linz (LinzImpuls 2008), Radio
FRO/HAIP EU - CULTURE 2007
Not supported by: Linz 09 - European Capital of Culture Linuxwochen
Austria
--
:*
--
GOTO10 ONE WAY NFO L!ST - HTTP://GOTO10.ORGIRC.GOTO10.ORG #GOTO10
A quick update on LAC2009
The paper review has ended, and 24 papers have
been accepted - this will require some squeezing
to fit into a schedule. There are three major
workshops planned as well, LASH, Netjack and
CLAM, and possibly others.
The music for the concerts has been selected.
There will be two, on thursday 16 and saturday 18,
at the orchestra rehearsal room of the auditorium
Paganini.
The only part that remains hanging in the air is
the Linux Sound Night (planned friday 17) and that
is why people who have proposed to play there have
not had a definitive response up to now.
The problem is finding the right space. In the
center of Parma you need something that's soundproof
or you will get the 'vigili' at your door within a
few minutes. The originally planned place (which was
near perfect) turned out to be too expensive. The two
next ones we tried are already booked. There are still
some places outside the center, but this will require
organising transport as well, or a very long walk to
your bed.
Anyway the plan *is to have a LSN*. Expect more news
in a week or so.
Meanwhile we've started making the detailed program.
Several people are involved in more than one activity
(papers, workshops, concerts, rehearsals) and taking
all this into account creates a rather complex puzzle.
For now I'll assume that all paper presenters will be
in Parma from thursday 16 april,11:00 to sunday 19
april,13:00. Sunday afternoon we'll have the workshop
reports, the traditional panel discussion and of
course the group picture.
If you present a paper and can't make it in time or
have to leave before the end of this period please
let me know ASAP.
For the early arrivals, on wednesday evening we'll
have the pre-conference pizza, and sunday evening
the very unofficial conference dinner.
The registration site should be up in a few days.
Looking forward to see you all in Parma,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !