Date: Mon, 17 Jan 2005 14:18:14 +0900 From: Pyun YongHyeon <yongari@kt-is.co.kr> To: Mathew Kanner <mat@cnd.mcgill.ca> Cc: Yuriy.Tsibizov@gfk.ru Subject: Re: audio code maintainers, A call to arms Message-ID: <20050117051814.GB875@kt-is.co.kr> In-Reply-To: <20050115180942.GA12541@cnd.mcgill.ca> References: <41E583BD.5080900@elischer.org> <20050115180942.GA12541@cnd.mcgill.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 15, 2005 at 01:09:42PM -0500, Mathew Kanner wrote: [...] > Hi Julian, > First, I guess I owe an apology to the list and to freebsd in > general for dragging my feet on MIDI. The stunning silence is > incredibly demotivating to me. Over the many months think I've had one > positive response to my work (it works!) and one negative (does not > compile for non-i386, printf qualifiers). I never expected to be in a > vacuum. Then again, I'm one of those sensitive types. > I guess you can commit your work to HEAD and let people give it spin. Since we don't have MIDI support now committing new one wouldn't break anything. It couldn't be fixed until new code shows up in tree. For non-i386 compile issues I can help you for sparc64. Other developers would help other issue(i.e. locking) too. > To move forward we need to: > > - Get a new sound team. I don't know how to go about this, maybe a > general call to arms, or an appointment from core or maybe a > guillotine backed revolution. > I can see at least there are three developers(Kazuhito HONDA, Conrad J. Sabatier and Yuriy Tsibizov : CCed) are interested in maintaining our sound subsystem. Since we do have lack of maintainers of our sound subsystem it would be really great to see new developers that have commit privilege in this area. Personally I guess both Julian Elischer(for USB sound) and Mathew Kanner(for MIDI and sound infrastructure) can mentor these developers. > - Set a list of priorities and start working on them. I see the major > TODO items: > > - Review this list > - Figure out which PR are still applicable, close the rest. > - Move forward with features, other projects have far surpassed us. > To me the most glaring difference is that we are stuck with a > simplistic view of "Mixers" and cannot export the sophisticated > controls that present days devices contain. NetBSD, ALSA, that > commercial project have all taken this on. We could embellish or > just plain drop our mixer support while keeping what was good from > newpcm2 > - Or, just port the NetBSD sound infrastructure. Sometimes, when I'm > depressed, I look into the feasibility of this. > I don't fully understand internal details of sound subsystem. But I know current position of FreeBSD in sound capabilities between Linux and BSDs. Though FreeBSD has a limitation in mixer settings, it has superior capability not seen on other systems.(e.g. automatic endian/sampling rate conversion, virtual channel support, etc) Due to lack of MIDI experiences under FreeBSD I can't say internal details of mixers but I see other limitations of sound subsystem in FreeBSD. It seems that we need new DMA memory allocation/use strategy now. At present, the DMA memory is allocated during module load time and driver releases it during detaching from bus. Since it's not unusual that recent audio hardwares have multiple channels, allocating DMA memory of all channels at loading time would be waste of memory. In addition, since most cheap audio hardwares have DMA-capable address limitations(e.g. 16MB, 256MB, 1GB etc), allocating large DMA memory would guarantee unnecessary use of bounce buffers. Some audio hardwares have its own MMU to avoid the requirement of physically continuous DMA-capable memory block. I guess supporting effective use of MMU of audio hardware is essential for MIDI playback which needs possibly more DMA memory than that of plain pcm. -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050117051814.GB875>