http://www.osdn.com/conferences/kernel/
Thanks to all responsible for getting these captures
of the Kernel 2.5 Workshop prosentations put together.
There is one major shortcoming of the recordings.
Usually, only the comments of the presenter(s)
can be heard. This reduces the value of these
recording substantially, since the comments, insights
and give-and-take of the other kernel developers would
help us get a much more complete understanding of the
areas being presented -- try listening to Andy Grover's
Power Management presentation and you'll see what I
mean.
Miles Lane writes:
> There is one major shortcoming of the recordings.
> Usually, only the comments of the presenter(s)
> can be heard.
The problem is that nobody wants to wait for one of the microphones to
go across the entire room before they can begin speaking, this is what
was happening. Sometimes there was a dialogue going on between three
people sitting at tables, there were 2 microphones to go around...
One solution I've seen sort of work is to have 2 standing fixed
microphones in the isles, but this only really functions correctly
for a Q&A type session after a presentation.
It does not work in a relaxed "people sit at tables and comment
at arbitrary points in time during a talk" setting such as the
kernel summit. Besides putting a microphone at every table (which
isn't all that practical honestly) I can't come up with a solution.
Later,
David S. Miller
[email protected]
"David S. Miller" wrote:
>
> Miles Lane writes:
> > There is one major shortcoming of the recordings.
> > Usually, only the comments of the presenter(s)
> > can be heard.
>
> The problem is that nobody wants to wait for one of the microphones to
> go across the entire room before they can begin speaking, this is what
> was happening. Sometimes there was a dialogue going on between three
> people sitting at tables, there were 2 microphones to go around...
>
> One solution I've seen sort of work is to have 2 standing fixed
> microphones in the isles, but this only really functions correctly
> for a Q&A type session after a presentation.
>
> It does not work in a relaxed "people sit at tables and comment
> at arbitrary points in time during a talk" setting such as the
> kernel summit. Besides putting a microphone at every table (which
> isn't all that practical honestly) I can't come up with a solution.
I agree that this is another important issue. It's most
important in these events that the flow and exchange of ideas
proceed unhindered. I do believe there is a way to record the
dialog without introducing significant impediments, though.
What usually is done these days, when a few groups of people
need to hold a conference call, for example, is that a few
omni-directional microphones are used (these are the sort of
spaceship-looking things that get placed in the center of a
large table around which the groups sit). There are drawbacks
with this, in that, for a large group, there's signal loss if
current speaker does not face the microphone. However, these
microphones do a pretty good job of picking up voice audio in
a 360 degree radius.
There would need to be some post-event sound mixing. For example,
if you have ten tables, each with its own omni-directional table
microphone, plus unidirectional microphones for the presenter(s),
you'd need to mix the signals from the microphones or perhaps
switch between the various microphone recordings and adjust for
volume differences. You'd likely get the best recording from
the table microphone a particular participant was sitting at.
You'd also likely get much stronger signals from the presenter's
microphone.
What say you all?
Cheers,
Miles
On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
> There is one major shortcoming of the recordings.
> Usually, only the comments of the presenter(s)
> can be heard.
I've heard of conferences where a wireless audience
microphone was put inside a Nerf ball. It could
then be tossed to the audience member who wished
to speak.
--
Randolph Bentson
[email protected]
Randolph Bentson wrote:
>On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
>
>>There is one major shortcoming of the recordings.
>>Usually, only the comments of the presenter(s)
>>can be heard.
>>
>
>I've heard of conferences where a wireless audience
>microphone was put inside a Nerf ball. It could
>then be tossed to the audience member who wished
>to speak.
>
That sounds more Linux-like *lol*
--
Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!
Ben Ford wrote:
>
> Randolph Bentson wrote:
>
> >On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
> >
> >>There is one major shortcoming of the recordings.
> >>Usually, only the comments of the presenter(s)
> >>can be heard.
> >>
> >
> >I've heard of conferences where a wireless audience
> >microphone was put inside a Nerf ball. It could
> >then be tossed to the audience member who wished
> >to speak.
> >
> That sounds more Linux-like *lol*
I can see it now.... Linus, go long!
D'oh! He dropped it! :-)
The sound effects from having folks forget to
switch off the mic before throwing it could be
pretty entertaining.
Seriously though, this would probably still be an
impediment to the sort of stream-of-conciousness
dialog that we'd like to have. Sometimes, there
is a quick series of one or two sentence comments
from several participants. With a "mike-in-a-ball"
your discussion might turn into a sports event.
Plus, personally, I am a crappy ball thrower.
If many of you have my level of athletic prowess,
there'd be a lot of time spent scrambling under
tables and chairs.
Miles
Randolph Bentson wrote:
>
> On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
> > There is one major shortcoming of the recordings.
> > Usually, only the comments of the presenter(s)
> > can be heard.
>
> I've heard of conferences where a wireless audience
> microphone was put inside a Nerf ball. It could
> then be tossed to the audience member who wished
> to speak.
Alternatively, you could hold your discussion on a
classical music performance stage. They usually
have about ten or twenty suspended microphones over
the stage. Then, you'd just need to mix the audio.
Miles
On Mon, Apr 16, 2001 at 08:46:33PM -0700, Miles Lane wrote:
> Randolph Bentson wrote:
> >
> > On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
> > > There is one major shortcoming of the recordings.
> > > Usually, only the comments of the presenter(s)
> > > can be heard.
> >
> > I've heard of conferences where a wireless audience
> > microphone was put inside a Nerf ball. It could
> > then be tossed to the audience member who wished
> > to speak.
>
> Alternatively, you could hold your discussion on a
> classical music performance stage. They usually
> have about ten or twenty suspended microphones over
> the stage. Then, you'd just need to mix the audio.
As one of the guys who was passing the mike around, I am a fan of the
directional mike. If you have ever used one of those, they are quite
nice and I think would solve the problem.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
>
> On Mon, Apr 16, 2001 at 08:46:33PM -0700, Miles Lane wrote:
> > Randolph Bentson wrote:
> > >
> > > On Mon, Apr 16, 2001 at 05:45:31PM -0700, Miles Lane wrote:
> > > > There is one major shortcoming of the recordings.
> > > > Usually, only the comments of the presenter(s)
> > > > can be heard.
> > >
> > > I've heard of conferences where a wireless audience
> > > microphone was put inside a Nerf ball. It could
> > > then be tossed to the audience member who wished
> > > to speak.
> >
> > Alternatively, you could hold your discussion on a
> > classical music performance stage. They usually
> > have about ten or twenty suspended microphones over
> > the stage. Then, you'd just need to mix the audio.
>
> As one of the guys who was passing the mike around, I am a fan of the
> directional mike. If you have ever used one of those, they are quite
> nice and I think would solve the problem.
Are you talking about one of those "eavesdropper"
parabolic microphones? Are you thinking of having
someone on stage redirecting the microphone as
each speaker starts talking? It could work well,
but you'd either lose the first few words each
person in the audience said or need to go to a
"hand raising/acknowledgement" to create a pause
during which the microphone could be redirected.
Miles
> Are you talking about one of those "eavesdropper"
> parabolic microphones? Are you thinking of having
> someone on stage redirecting the microphone as
> each speaker starts talking? It could work well,
> but you'd either lose the first few words each
> person in the audience said or need to go to a
> "hand raising/acknowledgement" to create a pause
> during which the microphone could be redirected.
Yeah, but that is still way way way faster than walking across the room to
hand someone a mike.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
have a couple of these and you would be able to keep one trained on the
most common speakers in any given discussion (then you only have the
problem of more speakers then mikes, but short of putting enough mikes
around to get the entire room you will always have this problem)
David Lang
On Mon,
16 Apr 2001, Larry McVoy wrote:
> Date: Mon, 16 Apr 2001 20:56:26 -0700
> From: Larry McVoy <[email protected]>
> To: Miles Lane <[email protected]>
> Cc: Larry McVoy <[email protected]>,
> Randolph Bentson <[email protected]>,
> [email protected]
> Subject: Re: Kernel 2.5 Workshop RealVideo streams -- next time,
> please get better audio.
>
> > Are you talking about one of those "eavesdropper"
> > parabolic microphones? Are you thinking of having
> > someone on stage redirecting the microphone as
> > each speaker starts talking? It could work well,
> > but you'd either lose the first few words each
> > person in the audience said or need to go to a
> > "hand raising/acknowledgement" to create a pause
> > during which the microphone could be redirected.
>
> Yeah, but that is still way way way faster than walking across the room to
> hand someone a mike.
> --
> ---
> Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Larry McVoy wrote:
>
> > Are you talking about one of those "eavesdropper"
> > parabolic microphones? Are you thinking of having
> > someone on stage redirecting the microphone as
> > each speaker starts talking? It could work well,
> > but you'd either lose the first few words each
> > person in the audience said or need to go to a
> > "hand raising/acknowledgement" to create a pause
> > during which the microphone could be redirected.
>
> Yeah, but that is still way way way faster than walking across the room to
> hand someone a mike.
I like this idea quite a bit. It would probably not
be terribly expensive to rent/buy the required equipment,
it would be easy to use and would not be terribly disruptive
to the preceedings.
I'm curious, didn't you find that those mikes are too
directionally sensitive? I've noticed that the movement
of the speaker by just an inch or two can cause major
variations in signal reception (I've only tried that
little plastic parabolic eavesdropping "toy" that was
all the rage about two Christmasses ago -- there was one
floating around my office).
Miles
Miles Lane writes:
>> Randolph Bentson wrote:
>>> I've heard of conferences where a wireless audience
>>> microphone was put inside a Nerf ball. It could
>>> then be tossed to the audience member who wished
>>> to speak.
>
> Seriously though, this would probably still be an
> impediment to the sort of stream-of-conciousness
> dialog that we'd like to have. Sometimes, there
> is a quick series of one or two sentence comments
> from several participants. With a "mike-in-a-ball"
> your discussion might turn into a sports event.
No, you just need a half dozen microphones. They get
tossed back to assistants on a least-recently-used basis.
> Plus, personally, I am a crappy ball thrower.
> If many of you have my level of athletic prowess,
> there'd be a lot of time spent scrambling under
> tables and chairs.
This is a reason to have athletic assitants, and another
reason to have a half dozen microphones instead of just one.
Still, the post-conference mixing from dozens of overhead
microphones looks best. It adds cost, setup time, and
post-processing time, but is totally reliable and does not
interfere with the conference at all.
If you wanted to get fancy, multiple overhead microphones
ought to let you cancel any sort of background noise with
a bit of 3d audio processing. Sneezes, coughs, footsteps,
people falling out of their chairs... all processed out.
On Mon, 16 Apr 2001, Miles Lane wrote:
>> hand someone a mike.
>
>I like this idea quite a bit. It would probably not
>be terribly expensive to rent/buy the required equipment,
>it would be easy to use and would not be terribly disruptive
>to the preceedings.
>
>I'm curious, didn't you find that those mikes are too
>directionally sensitive? I've noticed that the movement
>of the speaker by just an inch or two can cause major
>variations in signal reception (I've only tried that
>little plastic parabolic eavesdropping "toy" that was
>all the rage about two Christmasses ago -- there was one
>floating around my office).
Just to keep this on topic... the real question is what would be
the best way to interface this sound system into the Linux
kernel?
;o)
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
>>I like this idea quite a bit. It would probably not
>>be terribly expensive to rent/buy the required equipment,
>>it would be easy to use and would not be terribly disruptive
>>to the preceedings.
>
>Just to keep this on topic... the real question is what would be
>the best way to interface this sound system into the Linux
>kernel?
>
>;o)
Not a problem. :) Simply fit a machine with several ALSA-compatible
soundcards with mic-level inputs and use it as the recording medium.
Actually, I forget - do OSS-type soundcard drivers handle multiple cards
sensibly too?
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [email protected] (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
> Not a problem. :) Simply fit a machine with several ALSA-compatible
> soundcards with mic-level inputs and use it as the recording medium.
> Actually, I forget - do OSS-type soundcard drivers handle multiple cards
> sensibly too?
Yes. Have done since 2.2.
"Mike A. Harris" wrote:
>
> On Mon, 16 Apr 2001, Miles Lane wrote:
>
> >> hand someone a mike.
> >
> >I like this idea quite a bit. It would probably not
> >be terribly expensive to rent/buy the required equipment,
> >it would be easy to use and would not be terribly disruptive
> >to the preceedings.
> >
> >I'm curious, didn't you find that those mikes are too
> >directionally sensitive? I've noticed that the movement
> >of the speaker by just an inch or two can cause major
> >variations in signal reception (I've only tried that
> >little plastic parabolic eavesdropping "toy" that was
> >all the rage about two Christmasses ago -- there was one
> >floating around my office).
>
> Just to keep this on topic... the real question is what would be
> the best way to interface this sound system into the Linux
> kernel?
This is not the topic (I don't really care how the audio
recordings get merged or how the final recording is delivered
as RealVideo/RealAudio streams). The topic is "how do we
get recordings of Linux-related discussions in the future
that capture all the comments of the participants."
It would be great if we could get a good approach nailed
down so that it could be used at Linux BOF discusssions
and development team presentations in the future.
OT: It would be great to have a central repository for Linux-
related audio/video streams. For example, it'd be great to
get some of the LinuxTag, LinuxWorld, Comdex, CBIT and other
presentations made available on the web. Perhaps even more
valuable, from a development information dissemination
standpoint, would be recordings of "birds of a feather"
discussions.
Miles
On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
>
> It does not work in a relaxed "people sit at tables and comment
> at arbitrary points in time during a talk" setting such as the
> kernel summit. Besides putting a microphone at every table (which
> isn't all that practical honestly) I can't come up with a solution.
I suspect that if we're going to do this again, having a microphone at
each table is what we'd have to do, assuming that we can keep the
numbers of people at the workshop down to 60-70 (which will be a *lot*
harder next time, since everyone and his brother will want to show up,
and will therefore pester, whine, and otherwise beg the workshop
organizers to be included onto the invite list).
If we have a lot more people, we'll probably have to go to the two
microphones in the aisle approach. But at that point a large part of
the workshop will be destroyed; so hopefully we'll just be able to
keep the numbers of people in the workshop to manageable number.
- Ted
Theodore Tso wrote:
>
> On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
> >
> > It does not work in a relaxed "people sit at tables and comment
> > at arbitrary points in time during a talk" setting such as the
> > kernel summit. Besides putting a microphone at every table (which
> > isn't all that practical honestly) I can't come up with a solution.
>
> I suspect that if we're going to do this again, having a microphone at
> each table is what we'd have to do, assuming that we can keep the
> numbers of people at the workshop down to 60-70 (which will be a *lot*
> harder next time, since everyone and his brother will want to show up,
> and will therefore pester, whine, and otherwise beg the workshop
> organizers to be included onto the invite list).
>
> If we have a lot more people, we'll probably have to go to the two
> microphones in the aisle approach. But at that point a large part of
> the workshop will be destroyed; so hopefully we'll just be able to
> keep the numbers of people in the workshop to manageable number.
Well, another option would be to have workshops on a more frequent
basis, target the workshops on fewer areas and restrict the invitees
to those doing work in fairly closely related areas. This would
allow us to foster the synergy of teamwork. The only obvious downside
to this IMHO would be the loss of the contribution of from those
working in dissimilar areas. This might be a significant loss, since
sometimes a great solution to a problem will come from someone who
is thinking "outside the box" of the current development team.
On the other hand, we could have the annual Kernel Workshop consist
of the folks who were at this year summit and simply add other
workshops that are more narrowly targetted.
Miles
There might be room in our educational mission for us the send someone
with equipment to support the meeting like we do with the ietf, and nanog.
joelja
On Tue, 17 Apr 2001, Theodore Tso wrote:
> On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
> >
> > It does not work in a relaxed "people sit at tables and comment
> > at arbitrary points in time during a talk" setting such as the
> > kernel summit. Besides putting a microphone at every table (which
> > isn't all that practical honestly) I can't come up with a solution.
>
> I suspect that if we're going to do this again, having a microphone at
> each table is what we'd have to do, assuming that we can keep the
> numbers of people at the workshop down to 60-70 (which will be a *lot*
> harder next time, since everyone and his brother will want to show up,
> and will therefore pester, whine, and otherwise beg the workshop
> organizers to be included onto the invite list).
>
> If we have a lot more people, we'll probably have to go to the two
> microphones in the aisle approach. But at that point a large part of
> the workshop will be destroyed; so hopefully we'll just be able to
> keep the numbers of people in the workshop to manageable number.
>
> - Ted
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli [email protected]
Academic User Services [email protected]
PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.
Theodore Tso writes:
> On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
>> It does not work in a relaxed "people sit at tables and comment
>> at arbitrary points in time during a talk" setting such as the
>> kernel summit. Besides putting a microphone at every table (which
>> isn't all that practical honestly) I can't come up with a solution.
>
> I suspect that if we're going to do this again, having a microphone at
> each table is what we'd have to do, assuming that we can keep the
> numbers of people at the workshop down to 60-70 (which will be a *lot*
> harder next time, since everyone and his brother will want to show up,
> and will therefore pester, whine, and otherwise beg the workshop
> organizers to be included onto the invite list).
Nah, my brother does Java.
Being an outsider, I'm still trying to find out WTF happened
on friday evening when NUMA was discussed. I can't find any
video, audio, or even technical notes. This sucks; I'm writing
support for NUMA hardware (it's not cache coherent) right now
and I don't have any idea where things will be going.
> If we have a lot more people, we'll probably have to go to the two
> microphones in the aisle approach. But at that point a large part of
> the workshop will be destroyed; so hopefully we'll just be able to
> keep the numbers of people in the workshop to manageable number.
You can have 90% of the people invited to one day only.
> Being an outsider, I'm still trying to find out WTF happened
> on friday evening when NUMA was discussed. I can't find any
> video, audio, or even technical notes. This sucks; I'm writing
> support for NUMA hardware (it's not cache coherent) right now
> and I don't have any idea where things will be going.
Something like
View 1: (The SGI view)
NUMA should be implemented as a single kernel on a numa system. Andrea
has done some work on this (see his kernel.org patches), as have SGI.
View 2: (The McVoy view)
NUMA is best viewed as another misguided attempt to do DSM and we
should run a kernel on each DSM node and do page cache borrows between nodes.
Alan
Miles Lane <[email protected]> writes:
> http://www.osdn.com/conferences/kernel/
>
> Thanks to all responsible for getting these captures
> of the Kernel 2.5 Workshop prosentations put together.
>
> There is one major shortcoming of the recordings.
> Usually, only the comments of the presenter(s)
> can be heard. This reduces the value of these
> recording substantially, since the comments, insights
> and give-and-take of the other kernel developers would
> help us get a much more complete understanding of the
> areas being presented -- try listening to Andy Grover's
> Power Management presentation and you'll see what I
> mean.
I actually managed to get almost all of it by simply pressing my ear
against my speaker, and then pulling back quickly when the main
speaker was talking.
So my question is, what would it take to get some automatic software
volume correction going. This looks like it would be the easiest fix
of all.
Eric
> So my question is, what would it take to get some automatic software
> volume correction going. This looks like it would be the easiest fix
> of all.
Unfortunately its encoded in a proprietary format otherwise it would have
been perhaps half an hours work to write an AGC filter for the data.
Alan
On Tue, Apr 17, 2001 at 10:46:20PM -0400, Albert D. Cahalan wrote:
> support for NUMA hardware (it's not cache coherent) right now
btw, there are three kind of NUMA systems:
1) cc-numa first citizens (wildfire alpha, future chips)
2) cc-numa second citizens (origin2k)
3) non cache coherent numa machines
On the first class numa citizens NUMA means "heuristics for higher performance".
On those systems you don't need any NUMA change for correct operation of the
kernel (besides the fact you may need to use discontigmem to boot the kernel
if there can be huge physical holes in the physical layout of the ram but
that is true also for any other non numa machine with big holes in the physical
ram address space).
On the second and thrid class of NUMA systems NUMA means "required changes
for correct operations of the system". difference between 1 and 2 is that
category 2) needs also to put specialized PIO memory barriers to serialize the
I/O across different nodes. So it "only" additionaly requires total auditing of
the device drivers.
I think linux will need to optimize class 1 of systems and I assume SGI has the
PIO memory barriers patches for the device drivers to support class 2 as well.
Nobody ever considered the non cache coherent numa support so far AFIK and
I guess it will hardly end into mainline (personally I wouldn't be that
excited to deal with that additional complexity ;). If you can tell, what
system is it?
Andrea
So grab and install dsproxy (http://freshmeat.net/projects/dsproxy/), and
capture the output. Than feed to e.g. XMMS which already has an AGC plugin.
t
On Wed, Apr 18, 2001 at 01:44:32PM +0100, Alan Cox wrote:
> > So my question is, what would it take to get some automatic software
> > volume correction going. This looks like it would be the easiest fix
> > of all.
>
> Unfortunately its encoded in a proprietary format otherwise it would have
> been perhaps half an hours work to write an AGC filter for the data.
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI