Difference between revisions of "Perex-InterviewWithDanielJames"
m (add migratedfromdev category)
Revision as of 15:49, 10 August 2007
Interview with Daniel James
I think Jaroslav and Takashi's contributions are well known, but which other developers have contributed to ALSA?
Abramo Bagnara was important team member for more than one year. He designed the initial version of PCM API for ALSA 0.9 and maintained several drivers. Frank van de Pol designed the sequencer API. The last team member is Clemens Ladisch who maintain the USB driver code, bt87x driver and does common code cleanups and hacking.
The other important contributors:
Paul Barton-Davis originated development of several drivers (wavefront, rme9652, hdsp) and actively discussed the ALSA APIs (mostly PCM). James Courtier-Dutton does work on new reduced Sound Blaster cards (EMU10KX, SB Audigy LS, Value etc.).
Grepping for MODULE_AUTHOR in the sources yields the following 57 names:
Abramo Bagnara, Alan Cox, Anders Torger, Andreas Mohr, Andrew Veliath, audio'at'tridentmicro.com, Bart Hartgers, Brent Baccala, Chris Rankin, Christian Fischbach, Christopher Butler, Clemens Ladisch, Creative Labs, Inc., David S. Miller, Derrick J. Brashear, Digigram, Eliot Blennerhassett, Francisco Moraes, Frank van de Pol, George Talusan, Giuliano Pochini, Hannu Savolainen, Haroldo Gamal, Henrik Theiling, James Courtier-Dutton, Jaromir Koutek, Jaroslav Kysela, Karsten Wiese, Laurent Canet, Levent Gündogdu, Marcus Andersson, Markus Bollinger, Martin Habets, Martin Langer, Massimo Piccioni, Matt Wu, Michael T. Mayers, Nicolas Pitre, Osamu Tomita, Paul Barton-Davis, Pilo Chambert, Rob Hooft, Rudolf Koenig, Scott Mc Nab, Stas Sergeev, Steve Ratcliffe, Takashi Iwai, Thomas Charbonnel, Thomas K. Dyas, Thomas Sailer, Tobias Gehrig, Tomas Kasparek, Tugrul Galatali, Ulf Carlsson, Uros Bizjak, Winfried Ritsch, Zach Brown
... but there are, of course, many other people who have contributed patches or privided hardware for development.
What's your background, and how did you get started hacking on Linux? At what stage did you become interested in audio?
Jaroslav Kysela I studied Computer Science at University of South Bohemia in Czech Republic. At university, in 1994, I discovered the Linux world and started working on http://www.perex.cz/~perex/ultra/∞ - The Linux Ultra Sound Project. From this time, I systematically evaluated and tried to push the Linux sound APIs and drivers forward. In 1999 I founded the ALSA project. Playing with soundcards was fun in first years and now, it is fun and full time job for me.
Takashi Iwai I studied Material Engineering at University of Tokyo in Japan, and used Linux during the research work of computer simulation. I started coding of the audio-related stuff when I casually received a SB AWE board that didn't work with Linux. As you know, having a non-working hardware is the great temptation to turn a good man into the dark side of programming :)
I don't remember exactly when I joined to ALSA. Was it 1999? I contributed the code for MIDI WaveTable support and hacked sequencer. Since then, I got involved more and more deeply with ALSA. It became my job now.
Clemens Ladisch I'm studying Computer Science at the Martin Luther University in Halle, Germany. I had been using Linux for many years but became interested in ALSA when my new SC-8820 USB MIDI device didn't work with Linux. Now my contributions to ALSA are mostly MIDI related, but the amount depends on how much free time I can spare.
Why do you think the OSS model failed to retain the interest of developers? Was it for technical reasons, or was it the split between free and proprietary versions?
We think that both reasons are correct. Technically seen, OSS is (was) a good system: It is small and simple. It was built in the initial phase using only information about the cheap consumer cards. However, it lacks the extensibility completely. This is a critical problem for the modern systems, and OSS could not be improved in this regard due to the proprietary version. Also, the split was not very helpful, because there are not many active sound kernel developers and they are working much rather on the fully open source project by nature.
It is a good question whether the commercial version was good or evil. It is true that Linux did have the "least" support for many devices thanks to commercial OSS. On the other hand, the existence of binary-only drivers surely demotivated the hardware manufacturers to open their specs and cooperate with the open-source projects like ALSA. Hopefully, the situation gets better nowadays.
At what stage did you realise that it was necessary to create a new sound architecture?
It was very early moment. We faced soon the limitation of OSS and needed the new infrastructure to achieve the better support of sound cards. That is the starting point of the development of ALSA.
We tried to define better APIs suitable for both consumer and professional audio / midi. We also had false ways in the beginning and the current (third or fourth) version of APIs is sufficient for most developers. Also, OSS API highly depends on the abstraction level defined with the simple API. We did many extensions, invented new ways which are now reused with OSS developers to enhance the original OSS APIs. Also, OSS APIs are strictly APIs between user space and kernel. Our "public" APIs are defined with new layer - alsa-lib which sits in the user space and this library will provide backwards compatibility and hide all changes in case when drivers will define new fresh interface for the user space. Also, we can do user space drivers (for example for Bluetooth, Firewire) etc.
Which vendors have been the most helpful with chipset specifications? Do other ALSA drivers rely on reverse engineering?
Receiving the chipset spec was a hard job in the early stage of ALSA development. We had to do reverse engineering more or less. IIRC, Trident was the first company as the cooperative hardware manufacturer. They contributed the driver code and gave the open datasheet. After that, some companies producing high-end audio cards like RME, M-Audio and TerraTec showed interest and provided us the datasheet and test boards for the support of many (but not all) of their products.
Nowadays we have good relationship with many hardware companies in the wide range from the motherboard chip manufacturers like Intel, VIA, ATI to the high-end audio manufacturers. The reverse-engineering is still sometimes necessary, but we're trying to avoid it as much as possible. It would be much better to contact with the manufacturer than shooting in the dark.
What are the barriers for free software driver development, now or in the future? Are FireWire interfaces a particular difficulty, or is it just that the manufacturers of these devices don't follow standards?
The most annoying barrier is presence of closed or restricted specifications. For example, you need to become a member when you need to legally obtain all information for FireWire. In our opinion, this policy should cover only hardware vendors and these associations should give all necessary information to write drivers for free.
Does the ALSA project include scope for audio-over-network devices, such as mLAN hardware? Or is this beyond the limits of what the project does?
Yes, we would like to cover all hardware and audio-over-network seems to be very interesting area. Unfortunately, mLAN is closed specification. Also, the question is, if the network layer in Linux is capable doing the lowlatency realtime operations in current kernels for realtime audio. Fortunately, we might try to improve situation, because we can work with the network linux code thanks to open source.
Has the purchase of SUSE by Novell made any difference to the work of ALSA developers? Is there any input into Novell's desktop Linux initiatives?
Our work has not been changed. At least for time being. Note that only Jaroslav Kysela and Takashi Iwai are SUSE employees. Other ALSA developers are working without SUSE sponsorship. Actually, there is no direct communication between the SUSE ALSA team and other projects in Novell. The most other people in SUSE take our code and we directly communicate mostly with the YaST team to provide good sound configuration for SUSE distributions. Also, Takashi maintains several audio related packages for SUSE distributions.