OpenBSD Journal

Azalia - Not an Exotic Plant

Contributed by mbalmer on from the humppan-itsekseni dept.

It's Jason Wright reporting on his ongoing efforts to support azalia:

ICH6 and ICH7 (Intel Controller Hub version 6 and 7) contain a new audio device: azalia(4). About 8 months ago I got a new workstation with one and then started porting the driver from NetBSD. The audio layer in NetBSD has changed substantially recently to include support for resampling and more/different encoding formats, so the port wasn't as easy as it used to be.

Jason did not give up that quickly, read on...

Azalia is a new interface for audio devices. It is similiar to ac97(4), but contains more support for codecs and associated peripherals in addition to being 64bit DMA capable. Azalia is the driver for the Intel High Definition Architecture.

The driver can be broken into pieces: codec support, peripheral support, and DMA/Interrupt support. Codec support provides the ability to manipulate the codec (encoding, translation, etc). Peripheral support allows for manipulating the mixer. Finally, the DMA/Interrupt part escorts sample data from the audio(4) layer to and from the DMA engines on the chip.

While azalia provides many knobs to tweak, only a small fraction will be supported by OpenBSD. At the moment the driver works well enough to work with xmms(1) and other MP3 players. The mixer is not supported, and encodings other than signed-linear 16 bit don't work.

At this point, the driver is enabled in GENERIC in -current, and I'd love to hear feedback.

(Comments are closed)

Comments

  1. By tedu (69.12.168.114) on

    it also only supports stereo (for me), so a mono mp3 needs extra switches to make it go.

    Comments

    1. By Jason Wright (24.254.95.239) jason@openbsd.org on http://www.thought.net/jason

      > it also only supports stereo (for me), so a mono mp3 needs extra switches to make it go.

      Yes, fully describing what it supports: 16 bit signed linear stereo (I got it this far so I could listen to xmms while I was hacking on it). I'll get other formats supported soon (via our emulation layer).

  2. By jtorin (81.227.120.214) on

    A question somewhat related to the topic: what is the state concerning digital audio (in and out) over SP/DIF in OpenBSD (and Unix in general)? I can't recall I have ever read anything about it...

    Comments

    1. By andrew fresh (66.185.224.6) andrew@mad-techies.org on http://openbsd.somedomain.net

      > A question somewhat related to the topic: what is the state concerning digital audio (in and out) over SP/DIF in OpenBSD (and Unix in general)? I can't recall I have ever read anything about it...

      Well, I asked about it on the list not too long ago.

      http://marc.theaimsgroup.com/?t=114808476800001&r=1&w=2

      l8rZ,

      Comments

      1. By jtorin (81.227.120.214) on

        > Well, I asked about it on the list not too long ago.
        >
        > http://marc.theaimsgroup.com/?t=114808476800001&r=1&w=2

        Sweet. Thanks!

        (My long-standing subscription to misc@ timed out some time in may - didn't notice it first, until I realised how comfortable list reading had become. :-)

  3. By Anonymous Coward (192.18.43.249) on

    btw, maybe it worth to bring changes from NetBSD to OpenBSD in audio
    subsystem. for example Analog Devices chip AD19xx has distortion
    problems in OpenBSD, and doesn't have them in NetBSD..
    resampling is the another example.
    what do you think?

    Comments

    1. By Jason Wright (24.254.95.239) jason@openbsd.org on http://www.thought.net/jason

      > btw, maybe it worth to bring changes from NetBSD to OpenBSD in audio
      > subsystem. for example Analog Devices chip AD19xx has distortion
      > problems in OpenBSD, and doesn't have them in NetBSD..
      > resampling is the another example.
      > what do you think?

      I think it'd be somewhat cool. I'm not sure their design is right, however. Having it in the kernel means low latency from the resampling layer to the driver, it also means spinning in the kernel.

      It's something that needs more thought... kernel threads in OpenBSD aren't preemptable by userland processes, so they are not a viable alternative.

      Comments

      1. By Marc Espie (163.5.254.20) espie@openbsd.org on

        > > btw, maybe it worth to bring changes from NetBSD to OpenBSD in audio
        > > subsystem. for example Analog Devices chip AD19xx has distortion
        > > problems in OpenBSD, and doesn't have them in NetBSD..
        > > resampling is the another example.
        > > what do you think?
        >
        > I think it'd be somewhat cool. I'm not sure their design is right, however. Having it in the kernel means low latency from the resampling layer to the driver, it also means spinning in the kernel.
        >
        > It's something that needs more thought... kernel threads in OpenBSD aren't preemptable by userland processes, so they are not a viable alternative.

        I'm not sure resampling is that expensive compared to pure copying of data around. No idea whether having it done in-kernel will have an impact on other `real-time' userland applications.

        That said, I haven't looked at what actually happens in NetBSD right now.
        Is it just simple conversion, or do they do complex stuff like mp3 decoding
        directly in the kernel ?

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]