Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 May 2000 16:50:39 +0200
From:      A G F Keahan <ak@freenet.co.uk>
To:        Daniel Pouzzner <douzzer@mega.nu>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG
Subject:   Re: new device drivers for RME soundcard and G400-TV
Message-ID:  <392A9ABF.9839713C@freenet.co.uk>
References:  <200005230409.AAA24720@mega.mega.nu>

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel,

First of all, I think you will get a lot more replies if you re-post
your message to freebsd-multimedia (cc'd).  Secondly, the author and
maintainer of the new pcm driver in 4-stable and -current is Cameron
Grant (cg@freebsd.org), and you should talk to him before starting
anything serious.  The sound driver in FreeBSD 3.4 (and earlier) is
unmaintained and basically dead -- if your system is 3-stable or older,
go -current, then backport your changes to 4-stable.

I believe that newpcm was specifically designed to support advanced
features of modern sound cards, and also to be easily extensible.   The
only functionality currently missing is MIDI, and you should talk to
Seigo Tanimura about it (he has some patches to fix it).   I also
believe (and I'm sure that many people will agree with me) that we
should try to stay clear of GPLd code unless absolutely unavoidable.  
FreeBSD's driver framework is sufficiently different from that of Linux
that in practice it's not much of a problem.   On the other hand, if
porting the ALSA library would buy us support for a whole lot of new
soundcards, it might be well worth it.

Personally, I think that your time would be better spent improving the
existing system rather than designing a new one.   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.

Good luck

Alex Keahan



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?392A9ABF.9839713C>