summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/sound.mdwn
blob: e22a7e191035c2f334b4b1c83c79f38876e787af (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[[meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]

[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled
[[GNU_Free_Documentation_License|/fdl]]."]]"""]]

[[meta title="Sound Support"]]

The Hurd presently has no sound support.  Fixing this, [[GNU_Savannah_task
5485]], requires two steps: the first is to port some other kernel's drivers to
[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound
hardware.  The second is to implement a userspace server ([[hurd/translator]]),
that implements an interface on top of the kernel device that can be used by
applications -- probably OSS or maybe ALSA.

Completing this task requires porting at least one driver (e.g. from Linux) for
a popular piece of sound hardware, and the basic userspace server. For the
driver part, previous experience with programming kernel drivers is strongly
advisable. The userspace part requires some knowledge about programming Hurd
translators, but shouldn't be too hard.

Once the basic support is working, it's up to the student to use the remaining
time for porting more drivers, or implementing a more sophisticated userspace
infrastructure. The latter requires good understanding of the Hurd philosophy,
to come up with an appropriate design.

Another option would be to evaluate whether a driver that is completely running
in user-space is feasible.  <!-- TODO.  Elaborate.  -->

Possible mentors: ?

Exercise: Take a newer driver for a device in one of the subsystems we already
implement (disk or network) from a newer Linux version, or some other operating
system, and try to port it so that it runs in the existing driver framework.
The port needn't be elegant or complete; but it would be nice if you could get
it to work at least partially...