Skip site navigation (1)Skip section navigation (2)
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-hackers" 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>