Date: Tue, 23 May 2000 11:52:47 -0400 (EDT) From: Daniel Pouzzner <douzzer@mega.nu> To: ak@freenet.co.uk Cc: cg@freebsd.org, freebsd-hackers@freebsd.org, freebsd-multimedia@freebsd.org Subject: Re: new device drivers for RME soundcard and G400-TV Message-ID: <200005231552.LAA25710@mega.mega.nu>
next in thread | raw e-mail | index | archive | help
>I think you will get a lot more replies if you re-post >your message to freebsd-multimedia (cc'd). I've added myself to that list. >Secondly, the author and >maintainer of the new pcm driver in 4-stable and -current is Cameron >Grant (cg@freebsd.org) That's the subsystem I'm working with. -* uname -a FreeBSD mega 4.0-RELEASE FreeBSD 4.0-RELEASE #10: Mon Apr 24 19:27:08 EDT 2000 douzzer@mega:/usr/src/sys/compile/MEGA i386 >I believe that newpcm was specifically designed to support advanced >features of modern sound cards, and also to be easily extensible. I think the best strategy is to document the procedure whereby an ALSA driver is morphed into a newpcm driver, starting with the RME driver as a test case and example. >we >should try to stay clear of GPLd code No doubt. >if >porting the ALSA library would buy us support for a whole lot of new >soundcards, it might be well worth it. I'm going to try to have it both ways, by semi-automating the process of transplanting ALSA card drivers into newpcm. >If you discover that >newpcm is not powerful enough to accommodate some of the more advanced >features of your card, then we should find a way to improve it. Fair enough. -Daniel >Daniel Pouzzner wrote: >> >> I'm about to get cracking on a device driver for the RME Digi96/8 PAD. >> >> The card's full set of I/O channels is: S/PDIF I/O (2 channels in, 2 >> out, 16-24 bits@32-96kHz), AES/EBU I/O (2ch in, 2 out, 16-24 >> bits@32-96kHz), analog I/O (2ch in, 2 out, 16-24 bits@32-96kHz), and >> ADAT I/O (8 channels in, 8 out, 16-24 bits@44.1 or 48kHz). >> >> The hardware supports on-board routing between these channels, >> e.g. ADAT->S/PDIF or S/PDIF->ADAT. I will be supporting these >> features. For those who are simply curious about features, see >> http://www.rme-audio.com/english/digi96/digi96pa.htm >> >> My starting point (what I have in hand) is (1) a complete and >> functioning driver (supporting most key functionalities of the card) >> for Linux and the ALSA ("Advanced Linux Sound Architecture") >> subsystem, and (2) complete internal documentation on the card, from >> the manufacturer. >> >> Is FreeBSD's OSS-like audio subsystem powerful enough to provide >> access to all the card's features (particularly, all its ports, word >> sizes, and sample rates)? ac97.c goes only to 20 bits/sample, for >> example, but the card is 24 bits throughout. >> >> I have to decide what strategy to pursue: do I write a new driver >> based on an existing FreeBSD driver, using the Linux driver for hints, >> or do I use a FreeBSD driver for hints, basing the new driver on the >> Linux one (and thereby winding up with a GPL'd driver)? Or indeed do >> I write a driver truly from the ground up? The only FreeBSD soundcard >> driver I know of that includes analog and digital I/O support is the >> SB Live! driver, which in my experience doesn't work particularly well >> (in particular, capture didn't work at all when I tried it in April), >> so my sense is that there exists no smoothly working FreeBSD driver >> for a soundcard with anything remotely approaching the capabilities of >> the RME products. >> >> Finally, I have to decide whether I will port the ALSA library (in >> whole or in part - appealing because it would facilitate support for >> the dozens of other soundcards ALSA supports and FreeBSD doesn't), >> write a glue layer so that a driver that supplies an ALSA-type >> interface will work with the FreeBSD audio subsystem, simply create a >> driver that supplies a FreeBSD-style audio interface, or finally, >> create a driver that allows direct and specialized ioctl access to >> unusual card features not accommodated by the FreeBSD audio subsystem, >> but otherwise providing access via /dev/dsp et al. >> >> This will be the first device driver I write. Any advice, assistance, >> caveats, etc., will certainly be much appreciated. In particular, if >> anyone has a guide to device driver implementation, draft or polished >> form, complete or incomplete, it would surely be helpful to me. I >> understand some basic porting issues, e.g. bus_space_read_4 instead of >> readl(), copyin() instead of copy_from_user(), etc. The details will >> come into focus with determination and repeated exposure. >> >> I already have the card on the PCI bus, and am quite committed to BSD, >> so I will see this project to its successful conclusion (unless >> someone beats me to it (by all means, go ahead!:-)). >> >> -Daniel Pouzzner >> >> P.S. Also, if no one beats me to it, I will port G400-TV support for >> the realtime MJPEG codec, the TV/radio tuner, and video I/O and audio >> routing. The Linux development effort >> (http://marvel.sourceforge.net/) is just coming together and I won't >> be embarking on the project until they've got things basically working >> smoothly and I've got the RME card basically working smoothly. I do >> already have a G400-TV on my machine, currently not using the -TV part >> of course. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005231552.LAA25710>