OpenBSD Journal

Call for testers - jakemsr@ requests dmesgs and mixerctl output

Contributed by weerd on from the mix-a-lot dept.

Jacob Meuser (jakemsr@) wrote to misc@ with a request for dmesgs with azalia(4) audio devices. Undeadly asked him why this is so important. Please read on to find Jacob's answers:

azalia(4), the driver for Intel HD audio, is the "problem child" of OpenBSD's audio(4). Intel's specification allows the codecs to be highly configurable. Even BIOSes can configure the codecs. The specification defines numerous widgets (converters, mixers, selectors, etc) which have numerous capabilities (direction, connection, etc).

To create a usable driver, the programmer has to get all the widgets configured correctly, and make it possible for the user to configure the device to his preference.

For OpenBSD, this means the mixer item names have to be meaningful.

For some codecs, we have static mixer definitions. Those completely ignore configuration information the BIOS may have set, and often leave out many controls. So while these may give a useful control like 'outputs.master', they are usually wrong in the big picture. Not to mention, creating and maintaining static mixer definitions for all BIOS/codec combinations would be entirely ridiculous. So these static definitiotns are to be removed in favor of using the generic mixer definition code.

Currently, the generic mixer item names generally refer to the type of widget they control (mix == mixer, sel == selector, etc). While these names tell us what kind of widget we can control, they tell us nothing about what they actually affect. Using my ALC883 codec as an example, 'outputs.mix2' controls the volume on the first two playback channels, 'outputs.mix3' the next two, then 'outputs.mix4', then 'outputs.mix5', then, uh, 'outputs.mix8'. This is not at all intuitive.

Now if instead those mixer items were named for the channels they affect, such as 'outputs.ch01', 'outputs.ch23', 'outputs.ch45', etc, then it is much more clear what these control do. Granted, this does seem a little odd at first glance, but this is straight-forward to document. 'ch01' is channels 0 and 1, or the first stereo output. 'ch23' is channels 2 and 3, or the second stereo output, 'ch45' is channels 4 and 5, or the third stereo output, etc. This naming cascades down to other controls as well. Using my ALC883 again as a example, the options for 'outputs.hp_source' change from '[ mix2 mix3 mix4 mix5 mix8 ]' to '[ ch01 ch23 ch45 ch67 ch89 ]'.

But there is a problem with these names. They are unknown to current audio(4) software. So for that, we can expand on our knowledge of channel controls and create "virtual" (cloned, actually) controls like 'outputs.master' to control the output volume on the first two stereo channles and 'record.volume' to control the volume on the first two recording channels. This also helps to avoid alienating long time OpenBSD users who just happen to have gotten an azalia in their new laptop ;)

So, that is basically the plan for azalia. I have diffs to implement this on my machine, and I'm happy with the outcome. I think if the user reads azalia(4) where the chXY names and other common controls will be documented, the user will be able to configure the device as intended without having to go through any trial and error.

But because there are so many codecs with so many possible configurations, the changes will come in pieces, to make sure that possible issues with the implementation of the plan can be fixed at their core, and not pasted over.

So I ask that anyone who would like to see improvements in their azalia's usefulness to please subscribe to tech@ and test patches as they are made available. I will try to make the process as streamlined and easy as possible.

For the request for dmesgs, Jacob has built a set of kernels to test on i386 and amd64, both UP and MP (i386 UP, i386 MP, amd64 UP, amd64 MP) to make helping him even easier. Please download these kernels, boot them once and send the dmesg plus the output of mixerctl -v to jakemsr@ (please don't send your mail to misc@).

Update (Wed Nov 26 00:32:16 CET 2008): Jacob has put up a website where you can find patches for more of the work on azalia he describes above. If you want to help out even further, please visit his site to find out what else needs testing.

(Comments are closed)


Comments
  1. By Anonymous Coward (67.69.227.99) on

    I think the kernels are a great idea!

    A few questions:

    - Will these work on -RELEASE versions too?

    - Will a dmesg from -RELEASE suffice?

    - With my BIOS, I have two options to change the audio; HD Audio and something else, I can't recall the name off hand - does it matter which mode it's set to?

    - Is it only required to provide a dmesg for the same system on either i386-UP, i386-MP, AMD64-UP or AMD64-MP? or all configurations of the same system in those different modes?

    - Are dmesg's ok from gmail?

    The MoBo is an ASUS M2N-E (AMD64)

    I would dmesg | mail -s "blah blah" but my ISP blocks SMTP, unless there's a way to configure the use of external SMTP for this, then I could send a lot more dmesg's etc more easily.

    Comments
    1. By phessler (phessler) on http://theapt.org

      > I think the kernels are a great idea!
      >
      > A few questions:
      >
      > - Will these work on -RELEASE versions too?

      Things break if the kernel is out of sync with Userland. It might work, but then again, it might not. Update to a snapshot, that will give you the best experience.

      > - Will a dmesg from -RELEASE suffice?

      No.

      > - With my BIOS, I have two options to change the audio; HD Audio and something else, I can't recall the name off hand - does it matter which mode it's set to?

      It might be interesting, if they provide different behavior.


      > - Is it only required to provide a dmesg for the same system on either i386-UP, i386-MP, AMD64-UP or AMD64-MP? or all configurations of the same system in those different modes?

      Only one of them. But the full dmesg please.

      >
      > - Are dmesg's ok from gmail?

      Yes. If you attach the dmesg output as a text file, the normal webmail mangling shouldn't happen.

      >
      > The MoBo is an ASUS M2N-E (AMD64)
      >
      > I would dmesg | mail -s "blah blah" but my ISP blocks SMTP, unless there's a way to configure the use of external SMTP for this, then I could send a lot more dmesg's etc more easily.

      Look for SMART_HOST.

    2. By tedu (udet) on


      > - Will these work on -RELEASE versions too?

      To the extent required to get a dmesg, most likely.

    3. By Paul 'WEiRD' de Weerd (weerd) on http://www.weirdnet.nl/openbsd/

      phessler already answered this quite well, just adding some more
      details.

      > I think the kernels are a great idea!
      >
      > A few questions:
      >
      > - Will these work on -RELEASE versions too?

      The important thing is the dmesg output with AZALIA_DEBUG. You can
      give this kernel a boot with -s (on the bootprompt, type 'boot
      bsd.azalia-debug -s'), save the dmesg, and boot back to your
      -RELEASE kernel. If you prefer running -RELEASE, that ought to work.

      > - Will a dmesg from -RELEASE suffice?

      In general, yes, but in this case, no. These kernels are specially
      prepared to have some extra DEBUG output for azalia devices, the
      goal of this exercise is to collect this DEBUG output.

      > - With my BIOS, I have two options to change the audio; HD Audio and something else, I can't recall the name off hand - does it matter which mode it's set to?

      Like phessler said, just give 'em both a try. If both have azalia
      devices but give different dmesgs, send 'em both in. Obviously, if
      the dmesg is the same or if that other mode doesn't give you an
      azalia device, there's little use for the dmesg.

      > - Is it only required to provide a dmesg for the same system on either i386-UP, i386-MP, AMD64-UP or AMD64-MP? or all configurations of the same system in those different modes?

      Just what you normally run. This is why there's 4 separate kernels.

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

      > I think the kernels are a great idea!
      >
      > A few questions:
      >
      > - Will these work on -RELEASE versions too?

      might, might not. I haven't tested.

      > - Will a dmesg from -RELEASE suffice?

      no, the -RELEASE kernels do not have AZALIA_DEBUG defined.

      however, if you patch a -stable kernel so that AZALIA_DEBUG is defined, that is useful.

      and if you've ever done this before (deanna@ had put out similar requests in the past) and still have a copy of the dmesg, that works too.

      > - With my BIOS, I have two options to change the audio; HD Audio and something else, I can't recall the name off hand - does it matter which mode it's set to?

      yes. I only care about HD Audio.

      > - Is it only required to provide a dmesg for the same system on either i386-UP, i386-MP, AMD64-UP or AMD64-MP? or all configurations of the same system in those different modes?

      just pick one.

      > - Are dmesg's ok from gmail?

      as long as they get to me without too much mangling (e.g. I don't want to get dmesgs with all newlines removed), I really don't care.

      > The MoBo is an ASUS M2N-E (AMD64)
      >
      > I would dmesg | mail -s "blah blah" but my ISP blocks SMTP, unless there's a way to configure the use of external SMTP for this, then I could send a lot more dmesg's etc more easily.

      I haven't set up my local machines for outgoing or incoming mail in ages. just copy and paste or scp/ssh to a qualified server. I think I paid USD 65 for my lifetime unix shell account. well worth it.

    5. By Anonymous Coward (67.69.227.99) on

      > I think the kernels are a great idea!
      >
      > A few questions:
      >
      > - Will these work on -RELEASE versions too?
      >
      > - Will a dmesg from -RELEASE suffice?
      >
      > - With my BIOS, I have two options to change the audio; HD Audio and something else, I can't recall the name off hand - does it matter which mode it's set to?
      >
      > - Is it only required to provide a dmesg for the same system on either i386-UP, i386-MP, AMD64-UP or AMD64-MP? or all configurations of the same system in those different modes?
      >
      > - Are dmesg's ok from gmail?
      >
      > The MoBo is an ASUS M2N-E (AMD64)
      >
      > I would dmesg | mail -s "blah blah" but my ISP blocks SMTP, unless there's a way to configure the use of external SMTP for this, then I could send a lot more dmesg's etc more easily.

      Thanks guys for the responses, I'll install a 'separate' OpenBSD -SNAPSHOT on a spare drive, connected over USB, boot those kernels off of that and obtain the dmesg tonight, or worst case, this weekend.

      As mentioned by Paul, I can do this on my -RELEASE (or -STABLE) but at the same time I think this spare drive is a good idea in that I can also provide other dmesg's down the line too, without interfering with my existing install and very little downtime for just a helpful 'reboot'.

      Is it safe to assume that all -current diff's that need testing also get thrown into -snapshot releases or not? If so, I'll start this on a more regular basis.

      Thanks!

      Comments
      1. By sthen (2a01:348:108:155:216:41ff:fe53:6a45) on

        > Is it safe to assume that all -current diff's that need testing also get thrown into -snapshot releases or not? If so, I'll start this on a more regular basis.

        It varies. Some do, others do not. If you see a diff for something important to you, please test it outside of snapshots anyway.

  2. By Anonymous Coward (203.166.124.3) on

    is any one else annoyed by the naming of the controls? it's really irking me :)

    what happens if in the future you get a volume control for just the 23rd channel (yes, hypothetical :)? it would clash with ch23. wouldn't ch2-3 or maybe ch2+3, or anything else be better?

    and to me outputs.master suggests it is the master of *all* channels, so either it changes all channels to be the same, or it is a second level control above the individual controls that effects the channels after each individual control has. perhaps in this case an outputs.main would be more logical (but then that breaks the whole "keep the the naming structure we have" rule, which is one of the point of this, right?)

    anyway, i'll go back to quietly being annoyed now

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

      > is any one else annoyed by the naming of the controls? it's really irking me :)
      >
      > what happens if in the future you get a volume control for just the 23rd channel (yes, hypothetical :)? it would clash with ch23. wouldn't ch2-3 or maybe ch2+3, or anything else be better?

      future proof is good. X:Y like with aucat(1) would be better. after all, aucat is where the original inspiration for this naming came from ;)

      > and to me outputs.master suggests it is the master of *all* channels, so either it changes all channels to be the same, or it is a second level control above the individual controls that effects the channels after each individual control has. perhaps in this case an outputs.main would be more logical (but then that breaks the whole "keep the the naming structure we have" rule, which is one of the point of this, right?)

      yes, outputs.master as always been most closely associated with the first stereo output. that's how it works with ac97(4) and cmpci(4).

      anyway, most devices don't have a hardware "master volume control" as you describe it. the ones that exist in azalia are called outputs.volume. but there is some discussion about the usefulness/desirability of these controls. they change and/or act as limiters on other volume controls. these are a totally new type of control to OpenBSD audio. they aren't exactly necessary and add some complication and confusion, as they are left by the HD spec to be largely vendor defined.

      > anyway, i'll go back to quietly being annoyed now

      well, now is the time to make suggestions.

      Comments
      1. By Anonymous Coward (212.20.215.132) on

        > > anyway, i'll go back to quietly being annoyed now
        >
        > well, now is the time to make suggestions.
        >

        I'm basically satisfied as long as audio works by default without having to configure anything ;-) If there is also one knob to adjust playback and recording volume (output.master={N,M} and input.master={N,M}) and perhaps a mute toggle, then that's basically all I will ever need. If this works the same for all audio devices, perfect!

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

          > > > anyway, i'll go back to quietly being annoyed now
          > >
          > > well, now is the time to make suggestions.
          > >
          >
          > I'm basically satisfied as long as audio works by default without having to configure anything ;-) If there is also one knob to adjust playback and recording volume (output.master={N,M} and input.master={N,M}) and perhaps a mute toggle, then that's basically all I will ever need. If this works the same for all audio devices, perfect!

          "works by default" needs to be qualified a little. right now the focus is on getting stereo playback and recording, using the expected inputs/outputs, to work by default.

          getting multi-channel to work by default is tough. it would be great if when you play a 5.1 stream with mplayer, it would "just work". but don't hold your breath. however, we are also focusing on making it much easier to configure such setups manually. then you could just script mixerctl commands for your setup.

          we could add controls like "outputs.ch0:5.configure=on" that would attempt to set all the connections, directions and mutes for 5.1 ouput, but imo that's getting into the needless feature category, and would be quite ridiculous to get right everywhere.

          Comments
          1. By Anonymous Coward (24.22.108.209) on

            > getting multi-channel to work by default is tough. it would be great if when you play a 5.1 stream with mplayer, it would "just work". but don't hold your breath. however, we are also focusing on making it much easier to configure such setups manually. then you could just script mixerctl commands for your setup.

            or teach mixerctl(1) to read mixerctl.conf(5) directly

            $ mixerctl -i /etc/mixerctl.conf
            $ mixerctl -i /etc/mixerctl-5.1
            $ mixerctl -i /etc/mixerctl-0:3.0:3 # 4 play and 4 record channels
            $ echo outputs.master=200 | mixerctl -i -

          2. By Anonymous Coward (212.20.215.132) on

            > "works by default" needs to be qualified a little. right now
            > the focus is on getting stereo playback and recording, using
            > the expected inputs/outputs, to work by default.

            If aucat can play and record without the user having to touch
            mixerctl(1), edit /etc/mixerctl.conf, or fiddle with audioctl(1),
            and this works for every supported device, then this is what I
            would consider "works by default".

            As for the mixer, I only need the following (and it should be
            called the same and work the same for all supported hardware):

            input.volume={N,M}
            input.mute={on,off}
            output.volume={N,M}
            output.mute={on,off}

            > we could add controls like "outputs.ch0:5.configure=on" that
            > would attempt to set all the connections, directions and mutes
            > for 5.1 ouput, but imo that's getting into the needless feature
            > category, and would be quite ridiculous to get right everywhere.

            I can imagine. It seems hard enough to get just stereo playback
            and basic mixer functionality to work the same everywhere.

            Thanks for your efforts, and keep up the good work!

            Comments
            1. By Anonymous Coward (24.22.108.209) on

              > > "works by default" needs to be qualified a little. right now
              > > the focus is on getting stereo playback and recording, using
              > > the expected inputs/outputs, to work by default.
              >
              > If aucat can play and record without the user having to touch
              > mixerctl(1), edit /etc/mixerctl.conf, or fiddle with audioctl(1),
              > and this works for every supported device, then this is what I
              > would consider "works by default".

              record from what source? we generally default to mic, but I don't really like that. I guess what really needs to happen is to define a policy ...

              but yes, that is generally what we want. user just does 'aucat -i file' and viola, sound.

              > As for the mixer, I only need the following (and it should be
              > called the same and work the same for all supported hardware):
              >
              > input.volume={N,M}
              > input.mute={on,off}
              > output.volume={N,M}
              > output.mute={on,off}

              well, I can create

              record.volume={N,M}
              record.volume.mute={on,off}
              outputs.master={N,M}
              outputs.master.mute={on,off}

              on most azalia, but they would only affect the first two recording and playback channels, respectively. some are hard to get a mute. there are also some azalia that have no volume controls at all. I think it's unlikely that we'd add software volume control to the kernel.

              > > we could add controls like "outputs.ch0:5.configure=on" that
              > > would attempt to set all the connections, directions and mutes
              > > for 5.1 ouput, but imo that's getting into the needless feature
              > > category, and would be quite ridiculous to get right everywhere.
              >
              > I can imagine. It seems hard enough to get just stereo playback
              > and basic mixer functionality to work the same everywhere.
              >
              > Thanks for your efforts, and keep up the good work!
              >

      2. By Anonymous Coward (203.166.124.3) on

        > future proof is good. X:Y like with aucat(1) would be better. after all, aucat is where the original inspiration for this naming came from ;)

        yeah, good idea :) satisfies me (and i'm very important so you should be happy with that)

        > yes, outputs.master as always been most closely associated with the first stereo output. that's how it works with ac97(4) and cmpci(4).
        >
        > anyway, most devices don't have a hardware "master volume control" as you describe it.
        > the ones that exist in azalia are called outputs.volume. but there is some discussion about the usefulness/desirability of these controls.
        > they change and/or act as limiters on other volume controls. these are a totally new type of control to OpenBSD audio.
        > they aren't exactly necessary and add some complication and confusion, as they are left by the HD spec to be largely vendor defined.

        it doesn't necessarily have to be a hardware control. it could be software that just sets each hardware control to the same level. but if azalias have a second-level hardware control called outputs.volume, you don't really need a third one (it'd be four now actually, wouldn't it: application, channel, master, and master?). but then you also don't want different sound cards working differently... this is justing getting too fucking confusing. i'll just test and leave the rest to you, shall i? ;)



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

          > > future proof is good. X:Y like with aucat(1) would be better. after all, aucat is where the original inspiration for this naming came from ;)
          >
          > yeah, good idea :) satisfies me (and i'm very important so you should be happy with that)

          I'm happy ;)

          > > yes, outputs.master as always been most closely associated with the first stereo output. that's how it works with ac97(4) and cmpci(4).
          > >
          > > anyway, most devices don't have a hardware "master volume control" as you describe it.
          > > the ones that exist in azalia are called outputs.volume. but there is some discussion about the usefulness/desirability of these controls.
          > > they change and/or act as limiters on other volume controls. these are a totally new type of control to OpenBSD audio.
          > > they aren't exactly necessary and add some complication and confusion, as they are left by the HD spec to be largely vendor defined.
          >
          > it doesn't necessarily have to be a hardware control. it could be software that just sets each hardware control to the same level. but if azalias have a second-level hardware control called outputs.volume, you don't really need a third one (it'd be four now actually, wouldn't it: application, channel, master, and master?). but then you also don't want different sound cards working differently... this is justing getting too fucking confusing. i'll just test and leave the rest to you, shall i? ;)

          well, outputs.volume is software that controls hardware (Volume Knob Widget) that controls other hardware (the amps on DACs). and yes, currently the first DAC does get two controls (inputs.dac and outputs.master) that are copies of each other. and I guess if the application in use has a volume control, that would be four.

          getting rid of outputs.volume would take care of one of those.

          to get rid of the copies, we'd have to change all drivers to "ch naming". not a bad idea, imo. yeah, yeah, flag day and all, but no pain no gain, right? it's not so bad actually, as I can't think of anything besides libossaudio, the kernel and mixerctl(1) that actually uses our mixer. I'm 99% sure everything in ports that has mixer control capabilities uses libossaudio ... well, maybe xine-lib still twiddles the h/w mixer but that is to get the same libsndio backend as mplayer.

          Comments
          1. By Anonymous Coward (24.22.108.209) on

            > to get rid of the copies, we'd have to change all drivers to "ch naming". not a bad idea, imo. yeah, yeah, flag day and all, but no pain no gain, right? it's not so bad actually, as I can't think of anything besides libossaudio, the kernel and mixerctl(1) that actually uses our mixer. I'm 99% sure everything in ports that has mixer control capabilities uses libossaudio ... well, maybe xine-lib still twiddles the h/w mixer but that is to get the same libsndio backend as mplayer.
            >

            mplayer/xine-lib sun backends use play.gain/output_muted in the audio(4) API. and the kernel already can recognize names other than outputs.master to correlate to play.gain/output_muted. would just need to add outputs.ch0:1 to the list. similar change would take care of libossaudio.

            mixer names have already changed a little this release cycle ...

          2. By Anonymous Coward (203.166.124.3) on

            > well, outputs.volume is software that controls hardware (Volume Knob Widget) that controls other hardware (the amps on DACs). and yes, currently the first DAC does get two controls (inputs.dac and outputs.master) that are copies of each other. and I guess if the application in use has a volume control, that would be four.
            >
            > getting rid of outputs.volume would take care of one of those.
            >
            > to get rid of the copies, we'd have to change all drivers to "ch naming". not a bad idea, imo. yeah, yeah, flag day and all, but no pain no gain, right? it's not so bad actually, as I can't think of anything besides libossaudio, the kernel and mixerctl(1) that actually uses our mixer. I'm 99% sure everything in ports that has mixer control capabilities uses libossaudio ... well, maybe xine-lib still twiddles the h/w mixer but that is to get the same libsndio backend as mplayer.
            >

            well, if we are possibly going down that path, maybe this would work:

            outputs.volume - sets every single volume to the same level
            outputs.volume.main - changes just main channel volume, whatever the main channel may be
            outputs.volume.ch0:1, ch2:7, etc. - changes individual volumes

            or

            outputs.volume = outputs.volume.main above
            outputs.volume.all = outputs.volume above?

            or outputs.ch0:1.volume? i think i actually like this way, combined with the first part, better. it's more logical (class.property or class.object.property). so:

            outputs.volume
            outputs.main.volume
            outputs.ch0:1.volume

            thoughts?

            Comments
            1. By Anonymous Coward (24.22.108.209) on

              > > well, outputs.volume is software that controls hardware (Volume Knob Widget) that controls other hardware (the amps on DACs). and yes, currently the first DAC does get two controls (inputs.dac and outputs.master) that are copies of each other. and I guess if the application in use has a volume control, that would be four.
              > >
              > > getting rid of outputs.volume would take care of one of those.
              > >
              > > to get rid of the copies, we'd have to change all drivers to "ch naming". not a bad idea, imo. yeah, yeah, flag day and all, but no pain no gain, right? it's not so bad actually, as I can't think of anything besides libossaudio, the kernel and mixerctl(1) that actually uses our mixer. I'm 99% sure everything in ports that has mixer control capabilities uses libossaudio ... well, maybe xine-lib still twiddles the h/w mixer but that is to get the same libsndio backend as mplayer.
              > >
              >
              > well, if we are possibly going down that path, maybe this would work:
              >
              > outputs.volume - sets every single volume to the same level
              > outputs.volume.main - changes just main channel volume, whatever the main channel may be

              eh. I don't like "whatever the main channel may be". how is that defined?

              > outputs.volume.ch0:1, ch2:7, etc. - changes individual volumes
              >
              > or
              >
              > outputs.volume = outputs.volume.main above
              > outputs.volume.all = outputs.volume above?
              >
              > or outputs.ch0:1.volume? i think i actually like this way, combined with the first part, better. it's more logical (class.property or class.object.property). so:
              >
              > outputs.volume
              > outputs.main.volume
              > outputs.ch0:1.volume
              >
              > thoughts?

              with the current mixer, we can't have 3 levels of naming without the first two. you can't have outputs.main.volume without outputs.main. that's why we have '_' in azalia names.

              as far as a control for all volumes, that's starting to get tricky. is it relative or absolute? what if I really need quieter output on one of the channels? does changing one of the channels change the reported "master" volume? imo, adding a control that affects 3 or 4 different values is just a waste. too complicated for how little it "helps".

              Comments
              1. By Anonymous Coward (202.76.170.36) on

                > eh. I don't like "whatever the main channel may be". how is that defined?

                as you said before, master controls the main channel (say, ch0:1). main is just master in my mind (because master seems like an 'all' control to me)

                > with the current mixer, we can't have 3 levels of naming without the first two. you can't have outputs.main.volume without outputs.main. that's why we have '_' in azalia names.
                >
                > as far as a control for all volumes, that's starting to get tricky. is it relative or absolute? what if I really need quieter output on one of the channels? does changing one of the channels change the reported "master" volume? imo, adding a control that affects 3 or 4 different values is just a waste. too complicated for how little it "helps".

                haha. and this is why i said i'd leave it to you before. maybe i should start listening to myself :)

                just a note on the levels of naming: if the openbsd's audio is being completely redone (as it seems to be heading toward), adding an extra level to the mixer's naming scheme is really nothing. i can't see it being too hard to hack up (pure guessing on my part though). i just think it would much nicer to be able to say "outputs.ch0:1.mute=on; outputs.ch0:1.volume=0" rather than, for example, "outputs.ch0:1_mute=on; outputs.ch0:1=0"

            2. By Anonymous Coward (24.22.108.209) on

              > outputs.volume - sets every single volume to the same level
              > outputs.volume.main - changes just main channel volume, whatever the main channel may be
              > outputs.volume.ch0:1, ch2:7, etc. - changes individual volumes
              >
              > or
              >
              > outputs.volume = outputs.volume.main above
              > outputs.volume.all = outputs.volume above?
              >
              > or outputs.ch0:1.volume? i think i actually like this way, combined with the first part, better. it's more logical (class.property or class.object.property). so:
              >
              > outputs.volume
              > outputs.main.volume
              > outputs.ch0:1.volume
              >
              > thoughts?

              I think part of the problem, and what gets forgotten, is that mixerctl is not exactly user friendly. it just reports and sets kernel variables.

              as disgusting as it sounds, maybe mixerctl.conf should be more of a configuration file for mixerctl itself. I mean, mixerctl.conf would be like pf.conf or such. you could define "aliases" for groups, slave controls, master controls that are either absolute or relative, or whatever. name the controls as you like. then running mixerctl would just give you whatever you told it to. default would be to show everything with no aliases. of course, that means completely redesigning mixerctl. the benefit though, is we'd move all the "fancy stuff" like a true "master" that controls everything, out of the kernel, and we could focus on making the mixer interface simple and consistent across devices.

              actually, that's not so disguting after all. and really, making the mixer interface simple and consistent across all devices is far, far more important than deciding on what "outputs.master" should do.

              Comments
              1. By Anonymous Coward (202.76.170.36) on

                > I think part of the problem, and what gets forgotten, is that mixerctl is not exactly user friendly. it just reports and sets kernel variables.
                >
                > as disgusting as it sounds, maybe mixerctl.conf should be more of a configuration file for mixerctl itself. I mean, mixerctl.conf would be like pf.conf or such. you could define "aliases" for groups, slave controls, master controls that are either absolute or relative, or whatever. name the controls as you like. then running mixerctl would just give you whatever you told it to. default would be to show everything with no aliases. of course, that means completely redesigning mixerctl. the benefit though, is we'd move all the "fancy stuff" like a true "master" that controls everything, out of the kernel, and we could focus on making the mixer interface simple and consistent across devices.
                >
                > actually, that's not so disguting after all. and really, making the mixer interface simple and consistent across all devices is far, far more important than deciding on what "outputs.master" should do.

                exactly. my thoughts have never been that we should be implementing in the kernel fake, completely software 'objects' like master. if it doesn't directly correlate to hardware, or it's not absolutely required in the kernel, then it shouldn't be there, shouldn't it. in my mind master (and main, etc.) have been entirely defined within mixerctl

                it would absolutely great to just say "audioctl volume=255" and not have to worry about what the hardware does or doesn't provide. but if this can't be done with sanity, should it be done? is reworking mixerctl to provide umpteen knobs really necessary in what should be a classically simple openbsd audio control interface?

                anyway, this is digressing too much. i should (should!) just let you get back to doing the good work you are doing :)

                Comments
                1. By Anonymous Coward (24.22.108.209) on

                  > > I think part of the problem, and what gets forgotten, is that mixerctl is not exactly user friendly. it just reports and sets kernel variables.
                  > >
                  > > as disgusting as it sounds, maybe mixerctl.conf should be more of a configuration file for mixerctl itself. I mean, mixerctl.conf would be like pf.conf or such. you could define "aliases" for groups, slave controls, master controls that are either absolute or relative, or whatever. name the controls as you like. then running mixerctl would just give you whatever you told it to. default would be to show everything with no aliases. of course, that means completely redesigning mixerctl. the benefit though, is we'd move all the "fancy stuff" like a true "master" that controls everything, out of the kernel, and we could focus on making the mixer interface simple and consistent across devices.
                  > >
                  > > actually, that's not so disguting after all. and really, making the mixer interface simple and consistent across all devices is far, far more important than deciding on what "outputs.master" should do.
                  >
                  > exactly. my thoughts have never been that we should be implementing in the kernel fake, completely software 'objects' like master. if it doesn't directly correlate to hardware, or it's not absolutely required in the kernel, then it shouldn't be there, shouldn't it.

                  quite so.

                  > in my mind master (and main, etc.) have been entirely defined within mixerctl

                  ah, but currently it isn't. it's hardcoded in (all?) the drivers.

                  > it would absolutely great to just say "audioctl volume=255" and not have to worry about what the hardware does or doesn't provide. but if this can't be done with sanity, should it be done? is reworking mixerctl to provide umpteen knobs really necessary in what should be a classically simple openbsd audio control interface?

                  if we rework mixerctl, it should end up providing _less_ knobs, unless the user really wants more knobs. at least, that's what I'm thinking right now.

                  > anyway, this is digressing too much. i should (should!) just let you get back to doing the good work you are doing :)

                  well, this discussion has helped me conclude that simple is better when it comes to the kernel interface, and the "fancy" stuff should be elsewhere. actually, I knew that, but sometimes it's easy to get distracted by user requests ...

                  Comments
                  1. By Anonymous Coward (202.76.170.36) on

                    > well, this discussion has helped me conclude that simple is better when it comes to the kernel interface, and the "fancy" stuff should be elsewhere. actually, I knew that, but sometimes it's easy to get distracted by user requests ...

                    haha. hint taken

    2. By Alexandre Ratchov (193.136.214.254) alex@caoua.org on

      > what happens if in the future you get a volume control for just the
      > 23rd channel (yes, hypothetical :)? it would clash with ch23.
      > wouldn't ch2-3 or maybe ch2+3, or anything else be better?
      >

      Well, if we manage to get a channel <-> knob correspondance,
      then it will be able to switch to a multichannel mixer framework
      that ``understands'' channels. The first step (the hardest) is
      to get the correct channel numbers.

      > and to me outputs.master suggests it is the master of *all* channels
      > so either it changes all channels to be the same, or it is a second
      > level control above the individual controls that effects the channels
      > after each individual control has. perhaps in this case an
      > outputs.main would be more logical (but then that breaks the whole
      > "keep the the naming structure we have" rule, which is one of
      > the point of this, right?)

      not really; we first have to fix, tweak, adapt the low level drivers
      before we can change the naming structure. Otherwise the job is to
      hard.

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