OpenBSD Journal

Multi-channel multi stream improvements to aucat

Contributed by ray on from the multi-multi-multi dept.

Alexandre Ratchov and Jacob Meuser had an interesting e-mail exchange recently:
From: Jacob Meuser
Date: Sun, Nov 16, 2008 at 6:17 PM
Subject: Re: CVS: cvs.openbsd.org: src
To: source-changes@

On Sun, Nov 16, 2008 at 01:44:03PM -0700, Alexandre Ratchov wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: ratchov@ 2008/11/16 13:44:03
>
> Modified files:
> usr.bin/aucat : aucat.1 aucat.c listen.c sock.c
>
> Log message:
> allow aucat to listen on multiple sockets. Each socket carries its
> channel and volume settings allowing multiple configuration to
> coexist. Mostly useful for envy(4)-like devices, but can be used
> to force different apps to use different settings.

OMG! that's the coolest thing ever! thank you thank you thank you!!!

now *all* multi-channel devices can has multi-stream capabilities. e.g. I can do VoIP on DAC and ADC channels 0 and 1, and play music on DAC channels 2 and 3, and the person I'm calling doesn't hear the music I'm playing on 2 and 3. so cool!

is this even possible on NetBSD/FreeBSD/linux???
Very cool stuff is happening in the audio department, great job guys!

(Comments are closed)


Comments
  1. By Anonymous Coward (67.212.184.146) on

    aucat can has multi-stream.

    Comments
  2. By Anonymous Coward (85.19.213.88) on

    I've been following the development for some time now, and I really like the way things are going. aucat can now be used as a small audio server and applications can use libsndio to access the audio device. This keeps complicated conversion code out of the kernel and provides a simple interface to access audio devices, which makes porting audio applications easy.

    There's still a long way to go, though. In particular, the mixer is pretty horrible for many audio devices but the guys are doing a good job trying to bring order to a rather chaotic system. They'll get there, eventually, and you can help them by subscribing to misc@ and tech@ and trying out diffs.

  3. By Anonymous Coward (212.27.60.48) on

    OMG! an audio daemon! very high latency to be expected!

    Comments
    1. By tedu (udet) on

      > OMG! an audio daemon! very high latency to be expected!

      I already talked with them about this, somewhat more constructively, and the latency shouldn't be that bad. And if it is, the old interface isn't going away. The benefit of the library is that the same API can be used to talk to the direct device interface, so you can switch easily.

    2. By Jacob Meuser (24.22.108.209) jakemsr@sdf.lonestar.org on

      > OMG! an audio daemon! very high latency to be expected!

      esd and artsd usually have high latencies, but at least artsd can be configured to have about the same latency that many applications that use the hardware directly have. jackd by default has the same or lower latency.

      so I don't know where you get this idea that a sound daemon has high latency. I guess you only have experience with esd which started as an experiment and never really matured. or maybe artsd had problems because it was not only serving audio but also decoding MP3s and generally being much more than an audio daemon should be.

      anyway, on OpenBSD, until the past year is was hit-or-miss if a program could succeed in configuring low latencies, even if it was using the hardware directly. so if we can do all sorts of nifty things, like making hardware more accessible, with an audio daemon that isn't going to have any worse latency than people are used to, then it's a huge win, imo at least.

  4. By Anonymous Coward (91.113.168.110) on

    OMGGETAROOM!!!! :p

    Comments
    1. By Anonymous Coward (91.113.168.110) on

      > OMGGETAROOM!!!! :p

      To whatever douchebag modded me down:

      It'a joke. Deal with it.

      Douchebag.

      Comments
      1. By Jacob Meuser (24.22.108.209) jakemsr@sdf.lonestar.org on

        > > OMGGETAROOM!!!! :p
        >
        > To whatever douchebag modded me down:
        >
        > It'a joke. Deal with it.

        as was the original OMG ...

        >
        > Douchebag.

        no need for name calling.

      2. By Anonymous Coward (142.179.226.243) on

        > > OMGGETAROOM!!!! :p
        >
        > To whatever douchebag modded me down:
        >
        > It'a joke. Deal with it.
        >
        > Douchebag.

        They modded you down again.

        Ha ha!

      3. By Anonymous Coward (77.244.194.50) on

        > > OMGGETAROOM!!!! :p
        >
        > To whatever douchebag modded me down:
        >
        > It'a joke. Deal with it.

        You're modded down!!! deal with it
        >
        > Douchebag.

  5. By Anthony (2001:470:e828:100:207:e9ff:fe39:24e8) on

    I know OpenBSD doesn't always like big, ambitious daemons from the Linux world, but is there any reason pulseaudio isn't suitable? I know in the case of things like CVS and NTP the 3rd party software had very real drawbacks that made a simpler implementation a good idea, but I am curious what factors from pulseaudio made this the case here. Is it because it was preferred that an audio daemon was desired in the base system, and pulseaudio wasn't suitable because it was GPL'd?

    Comments
    1. By Drailex_Mauder (207.47.231.221) on

      GPL is never suitable for OpenBSD base. Period.

      Comments
      1. By Anthony (2001:470:e828:100:207:e9ff:fe39:24e8) on

        > GPL is never suitable for OpenBSD base. Period.


        I realize that. My question was whether there needed to be an audio daemon in base.

        Comments
        1. By tedu (udet) on

          > > GPL is never suitable for OpenBSD base. Period.
          >
          >
          > I realize that. My question was whether there needed to be an audio daemon in base.

          yes.

        2. By Jacob Meuser (24.22.108.209) jakemsr@sdf.lonestar.org on

          > > GPL is never suitable for OpenBSD base. Period.
          >
          >
          > I realize that. My question was whether there needed to be an audio daemon in base.

          I didn't get that from your post.

          anyway, why not? it lets us provide solutions in userland that would be much more complicated and come at a much higher cost if they were implemented in the kernel.

    2. By Jacob Meuser (24.22.108.209) jakemsr@sdf.lonestar.org on

      > I know OpenBSD doesn't always like big, ambitious daemons from the Linux world,

      more like doesn't ever.

      > but is there any reason pulseaudio isn't suitable?

      suitable for what? it doesn't even build on OpenBSD. developer time has been spent (wasted) on it.

      > I know in the case of things like CVS and NTP the 3rd party software had > very real drawbacks that made a simpler implementation a good idea

      not even building is a pretty major drawback.

      >, but I am curious what factors from pulseaudio made this the case here.

      see above

      > Is it because it was preferred that an audio daemon was desired in the base system, and pulseaudio wasn't suitable because it was GPL'd?

      are you joking?

    3. By Damien Miller (djm) on http://www.mindrot.org/~djm/

      > I know OpenBSD doesn't always like big, ambitious daemons from the
      > Linux world, but is there any reason pulseaudio isn't suitable?

      It's barely suitable for Linux; it is the first thing most people turn off on Ubuntu because it causes so many problems. I'm sure that by the time the Linux crowd has finally shaken the bugs out of PulseAudio they will be busy replacing it with something that "holds more future promise".

      Comments
      1. By Anonymous Coward (129.132.27.178) on

        > > I know OpenBSD doesn't always like big, ambitious daemons from the
        > > Linux world, but is there any reason pulseaudio isn't suitable?
        >
        > It's barely suitable for Linux; it is the first thing most people turn off on Ubuntu because it causes so many problems. I'm sure that by the time the Linux crowd has finally shaken the bugs out of PulseAudio they will be busy replacing it with something that "holds more future promise".

        The trouble with developing a proper audio solution for Linux has been going on for many years: esd, alsa, arts, jack, gstreamer, pulseaudio ... In the end, people always complained about the quality of the implementation and the complexity of the design.

        "aucat" might become _the_ solution for many Unix platforms because it follows Unix philosophy, it is simple and it works. As it happened with OpenSSH (and is happening with netcat, inetd, ntpd, isakmpd, ...).

        Comments
        1. By Fábio Olivé (189.31.105.60) fabio.olive at gmail on

          > The trouble with developing a proper audio solution for Linux has been
          > going on for many years: esd, alsa, arts, jack, gstreamer, pulseaudio
          > ... In the end, people always complained about the quality of the
          > implementation and the complexity of the design.

          I've been working with/on Linux for a long time and I can't help but admire the simplicity of OpenBSD. Sometimes it looks like many "Linux" projects have no concept of a limited, well-defined purpose and develop from a promising but imature code base to a feature creature that has plugins, modules and supports every odd extension (or file format) under the sun, even before the code base really matures into fulfilling its initial purpose.

          With that the complexity goes up, the amount of glue code, compatibility code and layers of plugins get larger and larger, it starts to break and people move on to the Next Best Thing.

          Another distinctive difference is the obsession with having "choices" for the user, as if most users would actually care which sound daemon or driver they are using. On OpenBSD, at least as it seems to me, a developer looks at a need (such as "having a sound daemon to multiplex access to the sound card"), studies the existing solutions and what is really the ultimate necessity and its limitations, and implements a simple solution to exactly that and no more than that. That solution becomes "the OpenBSD solution" for that need, and everyone uses that, enhances that, and makes things work with that.

          What I see happen with many "for Linux" projects is that there are many incomplete solutions for the same need, and there is no standard solution that everyone agrees to because there is no "one Linux". In my opinion the Linux distributions should be making that decision and sticking to it (such as "we use pulseaudio and _everything_ we ship talks to it"), but they are not. So I can have the sorry state of my Fedora box where KDE applications talk to arts, which talks to pulseaudio, which talks to alsa; some other applications talk directly to pulseaudio, and some others only talk to alsa.

          So the real problem is not even having a good standard solution, but having _a_ _standard_ solution, even if it sucks. If it sucks but everyone uses it, then it makes sense to fix and enhance it because everyone will benefit. But it seems that with Linux distributions people will continue to add more incomplete solutions to the needs and nothing will emerge as the one solution everyone uses and fixes.

          > "aucat" might become _the_ solution for many Unix platforms because it
          > follows Unix philosophy, it is simple and it works.

          Exactly. KISS works.

      2. By Anthony (2001:470:e828:1::2:2) on

        > It's barely suitable for Linux; it is the first thing most people turn
        > off on Ubuntu because it causes so many problems. I'm sure that by the
        > time the Linux crowd has finally shaken the bugs out of PulseAudio they
        > will be busy replacing it with something that "holds more future
        > promise".

        I think often people conflate Ubuntu's inability to ship a well-tested release with brokenness of the technology. It's possible for ALSA and PulseAudio apps to coexist far better than they do on 8.04, and the reason they don't is because they shipped with known bugs that had known fixes rather than pick a realistic release date.

        Either way, I now understand what I set out to understand. Tedu was able to explain the situation very concisely.

    4. By Chris Wareham (80.176.91.102) on

      > I know OpenBSD doesn't always like big, ambitious daemons from the Linux world, but is there any reason pulseaudio isn't suitable? I know in the case of things like CVS and NTP the 3rd party software had very real drawbacks that made a simpler implementation a good idea, but I am curious what factors from pulseaudio made this the case here. Is it because it was preferred that an audio daemon was desired in the base system, and pulseaudio wasn't suitable because it was GPL'd?

      http://lwn.net/Articles/299093/

      http://linuxhaters.blogspot.com/2008/10/pulse-my-audio.html

      Basically, Pulseaudio is classic Linux related coding. Rather than improve what's already there, replace it wholesale with something that's only theoretically more adequate, but has way more bugs because it's immature. See ALSA versus OSS for example.

      As Jacob Meuser points out in another reply, attempts have been made to port Pulseaudio to the BSDs, but it's hard as each release is immediately deprecated. On NetBSD at least, the port is based on a Subversion snapshot, but has ground to a halt as the Pulseaudio author has no notion of API stability.

      This is why the otherwise excellent swfdec Flash player and browser plugin is stuck at an old version on NetBSD and OpenBSD - because it depends on Pulseausio, now that swfdec has dropped its OSS support. My offer to resurrect the OSS support was turned down, and eventually ended with one of the swfdec developers making a snide remark about BSDs not liking anything with Linux in the name (ALSA in this case). That showed a certain amount of ignorance and hypocrisy - adopting good APIs from Linux happens in the BSD world, but ALSA is frankly shite, which is something the swfdec developer had already acknowledged.

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.]