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
41
42
43
44
45
46
47
48
|
[[!meta copyright="Copyright © 2008, 2009, 2018 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"]]
[[!template id=highlight text="""/!\ Obsolete /!\
---
This is no longer valid as a Google Summer of Code project."""]]
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. -->
Exercise: This project requires kernel (driver framework) hacking as well as
some Hurd server hacking; so the exercise should involve either of these, or
even both. You could for example port some newer driver to run in the existing
framework (see the [[device_driver|driver_glue_code]] project description), or
try to make some fix(es) to the [unfinished random device
implementation](http://savannah.gnu.org/patch/?6088) created by Michael
Casadevall.
|
